OgreAnimation library!

[dark_sylinc]

Surprise!

I started writing a modular animation library implementation some time ago to replace the current one (mostly because of performance reasons).

It ONLY supports skeletal animation (no pose animations, no per vertex animation; I'm not planning to include them either).
For the time being, it's in a very WIP state. It compiles, but I haven't tested it.

Furthermore it doesn't yet perform software blending or send the world matrices to the shader either. It just animates the bone matrices in a very efficient way; hopefully much better than the current one. It's SIMD ready and multithreading ready.
In the future, the idea is that Animation sections would be cut out from Entity (or at least ifdef'ed) for better modularity. Perhaps the biggest pain in the neck will be SW skinning because vertex buffer formats can be very flexible.

I have yet to write a PDF or slides documenting how the SoA layout works because it can be very disorienting if you don't know what's going on. There is no "perfect layout", but the library implements an algorithm that tries to keep keyframes in memory as closest as possible so they keep in cache. The keyframe data in Ogre 1.x's layout is extremely far apart between each node track.

The repository can be tracked and browsed here: https://bitbucket.org/dark_sylinc/ogreanimation

I'll be working on it on weekends only.

[Mako_energy]

Oh god. It's like christmas!

First and most important question I have is: Is this meant to be your own solution that you throw out there and what happens...happens, or is this an attempt to address #2 from this post and you have the intention of integrating this in OgreMain (with the ogre teams approval of course)?

Beyond substantially improving the performance of skeletal animations, what is the long term plan for this animation library? Any plans to extend the existing feature set of the current implementation? More to the point...IK?

[dark_sylinc]

First and most important question I have is: Is this meant to be your own solution that you throw out there and what happens...happens, or is this an attempt to address #2 from this post and you have the intention of integrating this in OgreMain (with the ogre teams approval of course)?

A mix of both.
I want it to be modular. Many iOS/Android games don't need the animation stuff. It just bloats the executable.
I also want it to be replaceable, just in case someone decides to drop their own implementation which empathizes quality over speed (my implementation prioritizes speed) or needs custom tweaks.

But at the same time, it can't be fully detached from OgreMain for two reasons:

1. Performance: Even silly stuff like '+' operator from Vector3 stops being inlined when you go DLL (I looked at the assembly). Since animation is computationally expensive, it's critical that we stick to either static libs or as part of OgreMain. (plus Win32 ABI sucks for passing xmm data to and from calls, which makes the operators even more expensive. I've seen MSVC having to do ridiculous stuff in Math::lerp when not inlined to avoid SSE2+OS limitations)
2. Integration with SceneManager. The SceneManager is responsible for updating animations and maintenance, as it has vital information about which order everything should be updated, and the high level culler knows best which animations shouldn't be updated.

Beyond substantially improving the performance of skeletal animations, what is the long term plan for this animation library? Any plans to extend the existing feature set of the current implementation? More to the point...IK?

Short answer, no.
A replacement for the current one. I'm not thinking of extending it. A bunch of entities in the scene and the framerate is already crawling. Current architectures should be able to update thousands of entities in real time at decent framerates. That's my goal. (and if we're lucky, another goal is to have the fastest animation library for mobile platforms; which is kind of a big deal)
Also if you look at the current code, it's kind of a mess (particular the double path: one for HW & one for SW)

IK solutions come in two flavours: Very advanced (general purpose), and very simple (specific cases).
For general purpose there are a lot of commercial options, and probably free ones as well. They also need very good tools for debugging, visualizing, setting parameters, etc. I have no plans to compete with them.
As for very simple solutions, they often only work for specific cases, which breaks the point of making a library for it.

Note however, this new animation system already supports efficient per bone weights for each animation, so you can put your simple IK code on top of the animation library while partially or fully masking the bones affected by IK.
The current animation system also supports per bone weights but it follows a different, less efficient code path. And it's slightly clunky to work with, IMHO.

[Mako_energy]

Short answer, no.
A replacement for the current one. I'm not thinking of extending it. A bunch of entities in the scene and the framerate is already crawling. Current architectures should be able to update thousands of entities in real time at decent framerates. That's my goal. (and if we're lucky, another goal is to have the fastest animation library for mobile platforms; which is kind of a big deal)
Also if you look at the current code, it's kind of a mess (particular the double path: one for HW & one for SW)

Based on how you said some of that, I think I may have not been as clear as I could be. I was speaking more about just the features, rather than the code itself. The existing code for animations I don't really know very well, but every time I have source dived into that system I came to the same conclusion that you have. It seems slow, more difficult to read than I care for, caching way too much data to get the job done, etc.. My first impression on reading this was that the new implementation wouldn't have any feature regression (aside from the morph and pose animation capability you've already mentioned), so I was asking if the new implementation would have new capabilities other than speed.

IK solutions come in two flavours: Very advanced (general purpose), and very simple (specific cases).
For general purpose there are a lot of commercial options, and probably free ones as well. They also need very good tools for debugging, visualizing, setting parameters, etc. I have no plans to compete with them.
As for very simple solutions, they often only work for specific cases, which breaks the point of making a library for it.

My interest would be in a general purpose solution as I'm working on an engine. I have looked into free and open source libraries that handle animation. I've only found 2: AnimKit and Cal3D. With AnimKit I don't really know what is going on, it seems very stripped down and worked on very sporadically. IK in particular has been on their roadmap for well over a year with no signs it'll get that functionality. In fact if it weren't for GameKit/OgreKit I would think that AnimKit was vaporware. Cal3D on the other hand seems a bit heavier (even going so far as having it's own file format) and it supposedly does have IK but it isn't maintained and it's getting aged. I could go into more detail, but I'll leave it at that for now. If you know of another library please let me know.

[lunkhound]

Wow, this sounds great!

I like the approach of keeping it simple but fast. I agree that IK is beyond the scope of something like this. However it would be really nice to have a way of hooking in procedural animations in a way that doesn't compromise performance too much. Maybe a listener that gets called after all the skeletal animations have been applied to an Entity, but before the bone transforms are sent to the GPU. This would allow the listener to modify bones for head-tracking or simple leg-IK.

[Kojack]

Will this system support flat skeletons?
Ragdoll style animation usually uses a flat skeleton where bones might be defined in a hierarchy but act individually in world space. Using Ogre's skeleton system usually requires converting every world space bone from a physics library into a parent space bone in the ogre skeleton, which then internally converts them back to world space bones for rendering anyway.

My interest would be in a general purpose solution as I'm working on an engine. I have looked into free and open source libraries that handle animation. I've only found 2: AnimKit and Cal3D. With AnimKit I don't really know what is going on, it seems very stripped down and worked on very sporadically. IK in particular has been on their roadmap for well over a year with no signs it'll get that functionality. In fact if it weren't for GameKit/OgreKit I would think that AnimKit was vaporware. Cal3D on the other hand seems a bit heavier (even going so far as having it's own file format) and it supposedly does have IK but it isn't maintained and it's getting aged. I could go into more detail, but I'll leave it at that for now. If you know of another library please let me know.

Havok Animation looks pretty good. Free for commercial use (you need a license to use it commercially, but the license is free, you just need to ask them), has ik (including things like attached objects with dual hand holding ik), runtime skeleton retargetting, physics integration, motion extraction, animation compression, motion blending, etc.
[youtube]9WU4CSB_rDk[/youtube]

[dark_sylinc]

Will this system support flat skeletons?
Ragdoll style animation usually uses a flat skeleton where bones might be defined in a hierarchy but act individually in world space. Using Ogre's skeleton system usually requires converting every world space bone from a physics library into a parent space bone in the ogre skeleton, which then internally converts them back to world space bones for rendering anyway.

Thanks for the tip, good to know.

I see a way to convert to world space directly. However, the main reason we work in parent space is animation quality. When bones are animated in world space, you need much more keyframe samples to get a similar quality.

Imagine two bones, parent and child. The parent bone rotates 360° using 4 keyframes (one every 90°). Whether you use Nlerp or Slerp, the rotation will be smooth for both bones; the only difference between nlerp & slerp will be the rotation speed.
The child will also follow perfectly in a circle.

Now imagine the same example working in world space. The parent bone will rotate fine. However the child bone will move linearly from one keyframe to the next. It will move in a diamond shape. You need a lot more keyframes to make its movement appear circular again, but you will probably see the parent and child disconnect unless the sampling frequency is very, very high.

However, if the IK is applied after the animations have been processed; I see no reason to convert to parent space when changing the world space transform (as long as you promise not to read the transform in parent space in the next frame, of course).

[Kojack]

Actually, I should read these posts a bit closer before posting.
I was thinking this was like ogre's entire skeleton/animation system, but it now sounds more like something that sits above a skeleton system:

It just animates the bone matrices in a very efficient way; hopefully much better than the current one.

in which case ragdoll systems would bypass it and go for the underlying non animation skeleton system (which may or may not support easy flat bone hierarchy). Is that close to how it works?

I should probably just read the source code first.

[Mako_energy]

Havok Animation looks pretty good. Free for commercial use (you need a license to use it commercially, but the license is free, you just need to ask them), has ik (including things like attached objects with dual hand holding ik), runtime skeleton retargetting, physics integration, motion extraction, animation compression, motion blending, etc.

Thanks for the suggestion, but I am one of those purists that needs licensing that is a bit more liberal. Aside from the licensing, Havok Animation looks like a great library.

[dark_sylinc]

Actually, I should read these posts a bit closer before posting.
I was thinking this was like ogre's entire skeleton/animation system, but it now sounds more like something that sits above a skeleton system:

It just animates the bone matrices in a very efficient way; hopefully much better than the current one.

in which case ragdoll systems would bypass it and go for the underlying non animation skeleton system (which may or may not support easy flat bone hierarchy). Is that close to how it works?

If you are going to look at the code, take in mind that it uses the old Skeleton, Bone, and Node track interfaces to convert the skeleton data from the old format into the new one, but there is no other relation with them (at least yet, but I don't plan to).

[lunkhound]

Any plans to add support for "additive animations" as described in this GDC talk (starting at the 15 minute mark):

http://www.gdcvault.com/play/1012300/An ... Control-in

???

It would mean slightly different blending math when applying an additive animation.

[dark_sylinc]

Additive animations are supported since Ogre 1.x; just set to ANIMBLEND_CUMULATIVE.

I, in fact, based Distant Souls' animation system inspired on those slides from Uncharted and watching Assassin's Creed layered animations. (and yes, the new system will also support additive blending)

Perhaps the biggest issue is that there is no sample showcasing the powerful capabilities of additive blending (Sinbad character demo does this to certain extent but it's not the main point of that demo)

[lunkhound]

Additive animations are supported since Ogre 1.x; just set to ANIMBLEND_CUMULATIVE.

I, in fact, based Distant Souls' animation system inspired on those slides from Uncharted and watching Assassin's Creed layered animations. (and yes, the new system will also support additive blending)

Perhaps the biggest issue is that there is no sample showcasing the powerful capabilities of additive blending (Sinbad character demo does this to certain extent but it's not the main point of that demo)

Wow! Great to know!
I had noticed the ANIMBLEND_CUMULATIVE thing previously but didn't quite get it until now. I think the part I was missing was the use of Animation::setUseBaseKeyFrame(...).

[TheSHEEEP]

Yes, maybe "CUMULATIVE" was not the best wording choice. It of course means the same, but "additive" blending is known to most.

[Zonder]

Yes, maybe "CUMULATIVE" was not the best wording choice. It of course means the same, but "additive" blending is known to most.

Probably should be renamed.

[dark_sylinc]

Yup! Poor name indeed.

It may be worth noting that the new system is additive in nature. 'Average' is nothing more than additive blending with the blending weights normalized so that their sum is one.
I believe Ogre handles average blend mode in the same way, but I can't remember now.

So if you have two animations "move arm" and "move leg", both set to weight 1.0; with additive blending both the arm and leg move 100%; while with average, they'll only move 50% of their original animation. If there is a third animation, they'll only contribute 33% each; but when using additive they'll contribute 100% each.

[lunkhound]

Yup! Poor name indeed.

It may be worth noting that the new system is additive in nature. 'Average' is nothing more than additive blending with the blending weights normalized so that their sum is one.
I believe Ogre handles average blend mode in the same way, but I can't remember now.

So if you have two animations "move arm" and "move leg", both set to weight 1.0; with additive blending both the arm and leg move 100%; while with average, they'll only move 50% of their original animation. If there is a third animation, they'll only contribute 33% each; but when using additive they'll contribute 100% each.

The name may not be the best possible name, but that's not what confused me. I had tried the cumulative mode, attempting to get an additive effect, but it didn't work the way I expected. I now realize that the reason it wasn't working is because I never set the correct base keyframe for my additive animations. If you don't do that, you'll get garbage results.
And yes, Ogre 1.x "average" mode works as you describe, normalizing the blending weights to add up to 1.0.

[dark_sylinc]

The name may not be the best possible name, but that's not what confused me. I had tried the cumulative mode, attempting to get an additive effect, but it didn't work the way I expected. I now realize that the reason it wasn't working is because I never set the correct base keyframe for my additive animations. If you don't do that, you'll get garbage results.
And yes, Ogre 1.x "average" mode works as you describe, normalizing the blending weights to add up to 1.0.

Existing tools don't help either. There is no option in the blender exporter that allows the user to select a different base pose (even though this is supported by the xml format) and I don't recall seeing this feature in OgreMax either.

[scrawl]

This is really exciting. Great work so far.

Anyway, I skipped through the code a bit and I have a couple of remarks:

- I don't understand why you made a findIterator function. What's wrong with std::find?
- Why is it a separate repo? It should be a new branch in your Ogre 2.0 repo, shouldn't it?
- When it's just for your own testing, I guess its ok to have windows bat scripts for building, but once you expect other people to actually try it out there really should be cmake scripts (another reason to make it a branch in the Ogre repo and make it a proper Component, even if its not ready yet) .
- Just FYI, identifiers beginning with __ are reserved by the compiler. I noticed that all of Ogre's include guards currently have this problem, but since you're adding new files, you might as well not do the same mistake there (prepending OGRE_ to the include guard would help to avoid clashes as well) [reported to JIRA now]

And could you explain the reasoning for removing morph & pose animation? I know it may be relatively easy to apply them manually, but what about combining vertex & skeletal animation (which was possible in the old animation system)?

[dark_sylinc]

This is really exciting. Great work so far.

Anyway, I skipped through the code a bit and I have a couple of remarks:

- I don't understand why you made a findIterator function. What's wrong with std::find?

Remnant code from older test projects. Ignore it. It's never used.

- Why is it a separate repo? It should be a new branch in your Ogre 2.0 repo, shouldn't it?

I needed fast iteration times for highly experimental code. Rebuilding Ogre was not an option. It also easies the modularity.

- When it's just for your own testing, I guess its ok to have windows bat scripts for building, but once you expect other people to actually try it out there really should be cmake scripts (another reason to make it a branch in the Ogre repo and make it a proper Component, even if its not ready yet) .

Until it's integrated into the main repo, I don't expect anything. It's just for the curious ones. Those settings are for me to make it easier (the bat script quickly updates the DLLs in the bin folders when I need to make a change in Ogre; and I use Visual Studio solutions)

- Just FYI, identifiers beginning with __ are reserved by the compiler. I noticed that all of Ogre's include guards currently have this problem, but since you're adding new files, you might as well not do the same mistake there (prepending OGRE_ to the include guard would help to avoid clashes as well) [reported to JIRA now]

Oh sh**

And could you explain the reasoning for removing morph & pose animation? I know it may be relatively easy to apply them manually, but what about combining vertex & skeletal animation (which was possible in the old animation system)?

I'm not removing morph & pose, not even skeleton. I'm working on an alternative. And if this alternative is as simple as possible, the better, because focusing on just skeleton animation is already quite difficult.
I'll deal what and how to do with the integration once we get there. I haven't decided yet which parts should be gone and which ones should be kept.
This animation library puts a lot of restrictions for the sake of SIMD and cache locality that a minority of people won't be happy with (particularly the big fishes, i.e. AAA middleware animation developers). Once the animation has been set, it's nearly impossible to modify it (unless all you want to do is to move the position/rotation/scale of the existing keyframes)
It's not a perfect replacement that will fit everybody.

[scrawl]

- Why is it a separate repo? It should be a new branch in your Ogre 2.0 repo, shouldn't it?

I needed fast iteration times for highly experimental code. Rebuilding Ogre was not an option. It also easies the modularity.

Being in the Ogre repo doesn't mean it has to be part of Ogre's build system.
A good reason to put it there is that VCS history will be kept from the beginning on, rather than just "importing" it to the repo once it's in a ready enough state and then losing all revision history before that. It's always good to have full history when you're bisecting or researching a particular issue.

[dark_sylinc]

Will this system support flat skeletons?
Ragdoll style animation usually uses a flat skeleton where bones might be defined in a hierarchy but act individually in world space. Using Ogre's skeleton system usually requires converting every world space bone from a physics library into a parent space bone in the ogre skeleton, which then internally converts them back to world space bones for rendering anyway.

(...)
However, if the IK is applied after the animations have been processed; I see no reason to convert to parent space when changing the world space transform (as long as you promise not to read the transform in parent space in the next frame, of course).

After a bit of thinking, now I see what you mean. The old Ogre skeleton system is completely detached from world space and works always in parent space. Then at some point the matrices are multiplied by the Entity's world transform (this happens in OptimisedUtils) to convert them to world space.

Don't worry. The new system doesn't work like that. It's world-space aware, and you can directly modify the world space transform (aka. derived position, rotation & scale) without modifying the local space parameters (but of course, your settings will be undone in the next update or in the next _getDerivedPositionUpdated call, and calls to getPosition vs _getDerivedPosition will be inconsistent)

[dark_sylinc]

Oh god. It's like christmas!

And coincidentally, I wrote an article on christmas! http://yosoygames.com.ar/wp/2013/12/ogr ... rformance/. Enjoy the demo!

[lunkhound]

And coincidentally, I wrote an article on christmas! http://yosoygames.com.ar/wp/2013/12/ogr ... rformance/. Enjoy the demo!

In your article you mention something about

easier third party IK integration are planned

Does this mean that the new animation system is less flexible than the old one for doing procedural animations and such things?
What I would like to be able to do is something like the following (pseudocode):

Code: Select all

for each frame:
   for each object
      update animation states (i.e. update time position, weights, etc)
      update scene node transforms

   evaluateAllAnimationsAndUpdateAllTransforms() (i.e. update all bones of all objects with results of animation blending, and transform all bones into world space)

   for each object:
      apply procedural animation to bones (modify bone transforms)
      apply bone transforms to physics rigid bodies/constraints

   physicsEngineTick()

   for each object:
       if object is in ragdoll state:
          copy from rigid bodies back to bone transforms

   renderScene()

Really all that is needed is:
1. The ability to update animations and update bone transforms separately from rendering the scene
2. the ability to read and write the bone transforms after the animations are updated but before the rendering

This should be possible with the new system, shouldn't it?

Thank you for the great christmas present!

[dark_sylinc]

I give a bit more explanation in the Jira task: https://ogre3d.atlassian.net/browse/OGRE-363
However how things are looking, I won't do that until 2.1 (I'll devote myself now to bug hunting & testing)

Does this mean that the new animation system is less flexible than the old one for doing procedural animations and such things?

No, in it's current state it is more or less as friendly as the legacy system. (Naturally, I expect legacy to be a bit easier since it's been tested in the real world, more polished and there are snippets on the web; but that's something that gets fixed over time)

2. the ability to read and write the bone transforms after the animations are updated but before the rendering

That's what I describe in the OGRE-363 ticket and what I meant with "easier IK integration".
Basically the skeletal animation has the following stages:
Local-bone space -> Derived-Object space -> World-bone space (this gets sent to GPU)

Right now, both in Legacy and the New system you would have to alter the bones in local-bone space (which is a huuuge PITA). With my "easier IK integration", you would be able to modify the matrices in the "Derived-Object space" stage (that's very simple, take your IK matrices, and convert them from world space to objects space using the inverse of the Entity's scene node transform)

1. The ability to update animations and update bone transforms separately from rendering the scene

I'm not sure 100% what you mean by that.