Irrlicht Engine

Saturn:

3MB in memory data per skeleton

Wow that is a lot,

My 1814 ploy mesh with 32 bones and 100 keyframes per bone is only 150kb including the mesh data.

Are you sure that’s in binary form you talking about, that’s like 300,000 keyframes at least, I cannot believe you get any framerate, the animators right now that not very good at handling large numbers of keyframe like that (one of the things I’m fixing), but I guess if you had a lot of bones sharing these keyframes, it's not that many.

Mainly because of the many animations, especially transitions

Well transition can be calculated realtime with this method, (as fast as normal animations too)

allow to share multiple meshes to attach to a single joint state set

sorry I’m not sure what you mean


Anyone:

Thinking about the animation system,

As I’ve said before I’ve made the b3d animator faster (not in the SVN yet, will be soon) then x and ms3d, one of the main bottlenecks was keyframe finding.

Now if the last used keyframe indexes was maybe stored in IjointSceneNode (some meshes can have different keyframe data each bone), and gave this value to the mesh as a hint. The animator could check this keyframe index then the next keyframe index, before doing a full search and in most cases would cut out this full search. It would be a huge speed boost.

This would leave keyframe interpolation and the skinning as the main use of cpu

This new animation system should be faster then what anyone is using now (especially with that keyframe thing), doesn’t break the interface, and has extra features.

But could I get some opinions from Niko (Hybrid and Bitplane too) about using this in Irrlicht.

I’ve got no benefit in going ahead and doing this just for my self, like I said I’ve made a system just like this, which is fine for me.

@Luke
do u have this animation system ready for download? I would love to use it! And i seams it would save me a huge amount of time making my own. Right now i'm using cal3D and making some nasty hacks to the engine to get it work with setting bone positions from outside and besides that cal3d isn't the fastest....
thanks even if u don't want to share it

Sudi:

Yeah, I'm happy to,

but I've only set it up for b3d (as that's all I'm using, pretty easy to get it working with other formats but)

First do you use the SVN? or 1.2?

Since I don't know too much about animation systems my opinion is not worth too much, but I like the new design. I'll have to draw some more classes around your image to get an impression of the placement for other, static nodes etc., but compared to the current all-or-nothing design it's really good
So keep on improving this important part of Irrlicht!

Luke wrote:As I’ve said before I’ve made the b3d animator faster (not in the SVN yet, will be soon)

Eh, it could happen.

Now if the last used keyframe indexes was maybe stored in IjointSceneNode (some meshes can have different keyframe data each bone), and gave this value to the mesh as a hint.

I agree; I noticed that en passant, but was too bone lazy (ho ho) to address it.

Purely as a personal preference, I'd also prefer the skeleton system to be sharable, but anything would be better than the current file-format-specific kludges.

Speaking of which, as animation is the primary reason for retaining file-format-specific classes and interfaces, if it's made generic, is there any argument to be made for retaining the file-format-specific interfaces? Other than backwards compatibility, I mean, but it's a really horrid way of doing it, and I can't see too many people being upset by having to change some ISomeWeirdModelFormat pointers over to a generic version that provides the same functionality.

rogerborg, as I understood it, the format specific interfaces are removed, once the transition is completed. For then there is no need for those.

Luke, I don't have the exact numbers at hand right now. Bone states are stored as 3x4 matrices. 3MB fit exactly 65536 such matrices. Our main skeleton has ~46 bones, don't remember the exact figure. But it was quite a negotiation with the artists to get this number down.
We're using a 2.0 vertex shader for skinning, so 46 bones with 3 weights is handable, the performance difference between 2 and 3 weights was non-existent in a normal scene, so we went for three.

I don't have the animation count at hand right now, but it is 50+ at least, probably higher. With the big amount of animations (different fighting anims for all kinds of actions and all kinds of weapons, multiple talk anims, walk anims with transitions, I believe 3MB is not excessive. We could cut down the sampling rate, but so far we don't see the need.

We tried to do transisitions automatically. But looking at the result physically hurts. The shortest path one believes right often is not the shortest path that can be achieved, if you don't constrain the joints in their degree of freedom. And we don't store any IK data, indeed I'm not smart enough to handle these anyway. ^^

allow to share multiple meshes to attach to a single joint state set

sorry I’m not sure what you mean

With that I mean, that you can plug multiple meshes onto a single skeleton, where each mesh is skinned onto the skeleton.
For instance think about an RPG, were you can mix different armor styles. You maybe have plate legs and leather bracers and a chain armor. Here you could simply have a chain leg mesh and a leather arm mesh and attach them to a skeleton node and they'd follow its animation, because each is rigged to a part of the skeleton.

This is over the top for irrlicht, clearly and would mudden the interface. This is only meant as an example that there are reasons in favor of separating the skeleton in general.

Saturn wrote:r
Luke, I don't have the exact numbers at hand right now. Bone states are stored as 3x4 matrices.

12 floats. I wonder if you could halve that by having position as 3 floats and rotations as unit quaternions (3 floats). Six floats in all.

As I've mentioned before, I'm holding off any further work on my Doom3 model loader as my hacky implementation will be obsolete with Luke's system.

I'm not sure about the skeleton idea. In Doom3 they do a lot of "sharing". Animations are separate from model meshes so that animations can be shared, but you still can't take, say, an imp mesh and use a marine animation.

@Luke: I'd like to try your current code if poss. In my reflective water demo there's 10 animated .X models, with reflections that's 20 model draws per frame and it's not as fast as I'd want (each Tiny has a Meat Cleaver in each hand so that's more models to draw). I wouldn't mind trying your b3d code and see if it speeds things up.

[Hmmm. 5 "Tiny" models, each with two Cleaver models; 5 Dwarfs, each with an Axe; total 25 models. With reflections that 50 models. Plus Castle model, which I've already converted to B3D. ]

@luke
right now i'm using 1.2. but if i would have to use svn to get the system working i would do that as well...no problem

With that I mean, that you can plug multiple meshes onto a single skeleton

The meshes are doing to need there own skeletons, your basically just plugging them it to animation data. And it’s not as easy for as user as just pluging them it, the indexes (or something else) on the mesh's bones need to be exactly the same (or some way) to match up the bones.

12 floats. I wonder if you could halve that by having position as 3 floats and rotations as unit quaternions (3 floats). Six floats in all.

Yeah, you can store the position and rotation data separately (position keyframes rarely change, and unneeded keyframes can easily be cut when the mesh loaders, making it use less data and faster)

I wouldn't mind trying your b3d code and see if it speeds things up.

Yeah I’ll send it

right now i'm using 1.2. but if i would have to use svn to get the system working i would do that as well...no problem

hmm, I’ll see if I got a patch for 1.2, it would be older but.

sio2 wrote: 12 floats. I wonder if you could halve that by having position as 3 floats and rotations as unit quaternions (3 floats). Six floats in all.

Quaternions are 4 floats, they are a strange 4 dimensional implementation of rotation. How is this better than storing a normal 3 dimensional vector in 3 floats?

Take a look at this article :

http://www.gamedev.net/reference/articl ... le1199.asp

Woops It looks like the article has been marked as misinformative

Nevermind then! Carry on with your quaternion-ness!

BlindSide wrote:

sio2 wrote: 12 floats. I wonder if you could halve that by having position as 3 floats and rotations as unit quaternions (3 floats). Six floats in all.

Quaternions are 4 floats, they are a strange 4 dimensional implementation of rotation. How is this better than storing a normal 3 dimensional vector in 3 floats?

HA! Caught you out. I wondered who'd bite on this. With a normalised (unit) quaternion you don't have to store W, as "1 = x^2+y^2+z^2+w^2" so you can derive W from X, Y and Z. This is how Doom3 stores rotations.

Two comments on this:

1. Does the world really need yet another skeleton-based animation system? You do know its possible to run Cal3D meshes within Irrlicht, right? Under the current system, even, which just goes to show how flexible it is.

2. Are you aware that there are a fair number of artists who really dislike skeleton-based animation? Take a look at Lightwave if you haven't yet, esp. spend some time on the forums where there are plenty of posts from artists along the lines of "how come developers only ever think of solving this problem using skeletons?"

I realize I'm probably one of the few people who actually thinks that the Irrlicht 3D animation system is "mostly" good (mostly = the only bad part of the existing file-specific system is that it could use some refactoring), but, then, I wonder how many people that are in favor of skeletons, have actually tried using them (ex: Cal3D). Granted Cal3D made it a way too hard to do program-control of bones, but it is possible. And for the most part, not worth doing, at least, not for games (which, I suspect, is the majority of the Irrlicht user base right now). If you're writing a VR visualizer, then maybe.

Best of luck on this, but please don't destroy the existing system when you implement it (your "move them over" statements). And please if possible try to keep in mind that there are other ways to animate 3D figures besides joint-based skeletons.

Well, we're deciding how to go about this so your feedback is useful.

Cal3D is great. I've used it for many years. Downsides for me are skinning on the cpu instead of the gpu (my type of games are cpu limited) and LGPL. If neither of these two issues effect you then go for Cal3D. My preference is not to have every vertex going across the bus every frame.

What alternatives to skinning had you in mind? Morph targets a la Quake2? These are sometimes used for facial animation - artists have more control than bones, but bones fit with the rest of the body (if using skeletal animation, of course).

The current XFile system gives me 78fps with a single mesh, whereas my own code - see the demo on my website - gives me 100 of the same animated meshes at 95fps. Lukes' B3D animation system in SVN is excellent though - I'm ditching ".x" format for ".b3d" for animated meshes.

Does the world really need yet another skeleton-based animation system?

Irrlicht is using a skeleton based animation system now, just it’s file-specific and slow.

You can think of the ‘program control of bones’ as side feature. The main features are hardware skinning like sio2 is talking about (and faster software skinning), animation blending and transitions.

I wonder how many people that are in favor of skeletons, have actually tried using them

I’m not sure what you mean, anyone who is using .x, .m3d, .b3d are using skeletons.

And for the most part, not worth doing, at least, not for games

I really cannot see why not,

The .x animator most people are using is very slow, I can get like 3 times faster. And with hardware skinning, you can get unbelievable speeds.

Find me any game in the shops from the last 5 years, that doesn’t use and control skeletons for it’s animation.

Best of luck on this, but please don't destroy the existing system when you implement it (your "move them over" statements). And please if possible try to keep in mind that there are other ways to animate 3D figures besides joint-based skeletons.

Yeah, md2 type animation still fits in with the new design, but it really is obsolete.

The other ways to animate 3d figures, are basically vertex based animation, which is basic and easy to support.

And of course there is animating a mesh based on chucks (eg, a robot) but that’s will be supported to, (each chucks is controlled by a joint)

I'm stoked to see this is still ongoing. Pay no attention to the man behind the curtain; once skeletal animation is factored out of the file-specific formats, ssexton can add any alternative animation system he likes. Reckon he will?