Mesh Deformation, Skeletal Animation, Bypass of UpSpring

[KDR_11k]

Could even be linked into the existing COB system, just treat controller bones as pieces in the script.

[Master-Athmos]

Could even be linked into the existing COB system, just treat controller bones as pieces in the script.

Why does this idea sound familiar to me?


But ok sorry - I didn't know there was a confusion about what "bones system" I meant as I thought people would be familiar which how they work in game engines. They initially got introduced as they are way more nice than simple vertex animations. You can do all the fancy things with them like controlling a bone's orientation (like e.g. a head rotating when the character's head should track a moving object) or mix animations (like walking legs and aiming with a gun-wielding guy's arms), it's a time saver when compared to the creation time of vertex animations and maybe most important: It was way faster / more efficent and not only did allow e.g. Half-Life to use a cool and powerful animation system but also did allow for more keyframes for the animation at the same computing costs...

For Spring most of those advantages won't apply though as we're not using vertex animation anyway...

[Tobi]

@Master Athmos

The important difference is tho, that you suggested (at least I understood it like this) to slave all bones to their respective pieces, making any kind of skeletal animation format impossible to use, and hence taking away any kind of benefit it may have. (as the current system already is skeletal animation except for the

KDR_11k on the other hand, wants to only slave 1 or 2 pieces (the controller ones) to COB, while keeping all other bones animated through a more common format then COB. This way it would actually have advantages over current system

[Master-Athmos]

The important difference is tho, that you suggested (at least I understood it like this) to slave all bones to their respective pieces, making any kind of skeletal animation format impossible to use, and hence taking away any kind of benefit it may have. (as the current system already is skeletal animation except for the

Yeah. I suggested "slaving" all bones to a COB piece as I don't see the need of doing any of that fancy stuff in a RTS (like mixing animations or doing ragdolls). That way we'd be able to totally skip the work around the integration of an external format for such animations. With e.g. the Blender COB export thesleepless did we still would have a "GUI" to do the animation in instead of doing it simply by some trial & error coding and testing...

But as this is a general discussion about the topic: What possibilities that a standard, "non-totally-COB-enslaved" system can deliver would you actually want to have?

[Tobi]

Allowing to actually make and use e.g. a walking animation as skeletal animation, without requiring to go through blender or upspring to get it into Spring. (i.e. saved in some more common format)

Integration with unit scripts is only good though; something needs to decide on speed of animations, when to start/stop which one, etc. (It would be silly to hardcode this.)

[Master-Athmos]

Allowing to actually make and use e.g. a walking animation as skeletal animation, without requiring to go through blender or upspring to get it into Spring. (i.e. saved in some more common format)

How do you want to make an animation without touching any software for doing so? Or even if you'd find a premade animation (as rare as it gets to find one exactly suiting your model) you'd still have to apply the bones to your model & stuff so you still would need to touch some kind of software...

With e.g. Blender (or any other software someone wants to code exclusively for us) you also already can import lots of stuff (although I currently have no clue what animation formats Blender can import) so there pretty much already is everything you might want to have: Either do your own animations or import some premade stuff and just plug your model onto the skeleton and do the COB export...

I see no reason as to why reinvent the wheel just for Spring...

[Tobi]

I didn't say without touching any software, I said without blender or upspring. (In other words, less dependent on specific software.)

Why do you think adding existing code to load existing animation and/or model formats is reinventing the wheel?

To me it seems more like finally adding support for the round wheel that everyone else is using, instead of keeping to use the square wheel that is only supported by certain Spring specific roads (tools).

[Master-Athmos]

Well if you really don't want to use any software you have to do a new model format, new logics for the animations and whatever else is related to it. All of this for something that I've seen no pro arguments for yet...

I don't see anything bad in using special tools - every engine has its set of tools made for it so that's nothing Spring exclusive. Especially with the problem of actually making someone do the work I vote for the most "easy" way of actually getting a certain feature...

[MidKnight]

This is aside from the current discussion in the thread, but I'd like to make it known that as a modeler, I'd like any new model/animation system to have the following characteristics:

- It should be able to support a level of animation and mesh manipulation that'll allow us to create convincing organic units without boat-loads of trouble. The ability to use a graphical interface to make anims would be good, too. If this is done well enough, I suspect that awesome-ness will ensue.

- It shouldn't be obfuscated. We don't want noobs tripping all over how to use it.

- Related to the last point, it should be intuitive. Don't force teamcolor into the alpha channel of the main texture, don't screw normals when the model is resized, etc.

[Master-Athmos]

I guess we should do a nice & clean wishlist of actual features we want and think of the best way of integrating them. It probably is self-evident that a pimped & polished Upspring with any noteworthy animation capabilities would be great...

[Tobi]

Well if you really don't want to use any software you have to do a new model format, new logics for the animations and whatever else is related to it. All of this for something that I've seen no pro arguments for yet...

I didn't say without touching any software, I said without blender or upspring. (In other words, less dependent on specific software.)

[Master-Athmos]

Well my answer was based on this:

(In other words, less dependent on specific software.)

If Blender is a too "specific software" from your point of view then pretty much any 3D suite is (which usually also cost you money and even quite a bunch of it). So the conclusion is you don't really want to be "forced" to touch any of that and thus want to be able to just import a model bought e.g. on that website where you can buy all the rts stuff (forgot the name right now)...

Or maybe the other way round: What software is not "specific" in your point of view?

[hoijui]

what tobi wants:

Code: Select all

Blender -> Spring
ABC -> Spring
X -> Spring
.
.
.
(no specific software) -> Spring

you want something like:

Code: Select all

Blender -> Spring
ABC -> Blender -> Spring
X -> Blender -> Spring

or

Code: Select all

Blender -> Upspring -> Spring
ABC -> Upspring -> Spring
X -> Upspring -> Spring

[Master-Athmos]

Well I didn't want to say that there should be only one tool everyone should use. You should be able to write an animation export thing like thesleepless did for Blender for pretty much any 3D suite with decent scripting capabilities and I wouldn't say a word if there were things like that. I just don't see the sense behind the integration of a model & animation format (+ the respective gameplay relevant logic) which would be a lot of additional work in comparison to "just" a remote controlled skeleton but would deliver features you cannot really make good use of in a RTS plus you'd enter the holy realm of non explicit specs in some formats leading to people whine as their exported stuff doesn't work as intended...

So in the end I'm saying that instead of integrating "3rd party" stuff into Spring we might want to rather do exporters for existing software or even small tools just for Spring which just would require to catch the movement and orientation of a couple of objects...

[KDR_11k]

KDR_11k on the other hand, wants to only slave 1 or 2 pieces (the controller ones) to COB, while keeping all other bones animated through a more common format then COB. This way it would actually have advantages over current system

Note that the controller status doesn't override the keyframes, just add to them.

[thesleepless]

i'm happy to write a batch command line tool that'll convert .objs into .s3os
can use most of the code from the blender plugin.