Animations?

Jan 12, 2008 at 9:00 PM
Does the engine handles animations yet?
Jan 13, 2008 at 1:21 AM
Keyframes/skeletal animation? No, not yet.
Jan 13, 2008 at 2:22 AM
Won't this prevent us to make that game?
Jan 13, 2008 at 3:39 AM
If we never add animation, then yes. But it'll eventually be added. Perhaps 0.20, more realistically 0.21. But still well before the game is finished.
Jan 13, 2008 at 7:42 AM
What do people want first, keyframe or skeletal animations?
Jan 13, 2008 at 4:21 PM
They're mostly one in the same. You assign vertices to bones, and the bones are driven by key frames.
Jan 13, 2008 at 4:41 PM
Edited Jan 13, 2008 at 4:44 PM
shawmishrak, We can have keyframe animations without having bones.

I would prefer to have keyframe first because it is more easy to implement and to work with. Later skeletal with blend animations.
Jan 13, 2008 at 4:54 PM
Do you mean character animation, or general object translation/rotation animation?

Jan 13, 2008 at 5:03 PM
Edited Jan 13, 2008 at 5:04 PM


shawmishrak wrote:
Do you mean character animation, or general object translation/rotation animation?


I mean the all package. We need to have an animation system capable of animating everything that we put in there. And we can also have character animations without bones, only framebyframe.( I prefer bones, but someone may prefer only framebyframe )
Jan 13, 2008 at 5:20 PM
Specifying transformations per frame per vertex? I don't see the use.

For object transformations (non-character), I would just specify translation/rotation per-object and key those every few frames.

In reality, most animation will be driven by physics anyway. You can just specify an angular/linear velocity to maintain.
Jan 13, 2008 at 5:29 PM
"In reality, most animation will be driven by physics anyway. You can just specify an angular/linear velocity to maintain."

Most but not all. A windmill for example won't be driven by physics.
Jan 13, 2008 at 5:38 PM
Why not? Create it as two pieces, a static frame, and a rotating blade assembly. Give the rotating blad assembly a constant angular velocity, and you're all set.
Jan 13, 2008 at 6:06 PM
Two much work and also it would be a waste of physcis processing.
Jan 13, 2008 at 6:32 PM
It can't be too much work; rotating a Entity around its own axis, based on angular velocity, is one of the main features of the physics engine. And I'll rather waste a single cycle on optimized physics code than a bestimate game developer code which might take a lot more than a single cycle.
Jan 13, 2008 at 6:48 PM
Not to mention on the PhysX backend the rotation will occur in a highly optimized native code section, where as the equivalent C# code would need to do a matrix multiply (at least) in XNA (slower than optimized native math, by at least 2x by my measurements), update the local object orientation (64 byte copy, which again isn't optimized in .NET), then send the new orientation to the PhysX wrapper, which copies the matrix into a PhysX 3x3 matrix type (36 byte copy), and makes a virtual call to the PhysX NxActor interface to assign the new orientation (cache miss + internal PhysX copying). Unless you didnt' want the windmill to be collidable, in which case you can save a bit of work here but it'd still be faster in native code.

And what makes it more work? It's a single property on the entity: an angular velocity around some axis, defaulted to X, Y, or Z.
Jan 13, 2008 at 6:49 PM
Yeah, you are probably right.