Irrlicht Engine

Ok, I’ve started building this animation system, the last few SVN updates broke the animation system I’m using, again, and it’s getting annoying

I’ll check up with Hybrid and Bitplane as I go, send them files and annoy them.

I’d like to get Niko’s opinions, but anyway.

What do you guys think about me using bits of the b3d animator for SkinnedMesh? It should be faster then x and ms3d, and I've cleaned it up alot

sio2:

by the way I got the b3d animator about 20% faster again, I’ll send you a patch, and I'll have to find hybrid and give him a patch too for the SVN.

and you can double the speed of the animator when using more then one node, by removing the getMesh in the postrender of AnimatedMeshSceneNode (I annoyed hybrid till he put it on his todo list )

Niko likes the new system, so go for it. It will become the new Irrlicht animation system

Thanks again for doing this. Even though I'm not using animation at the moment, I think this is a very important development for Irrlicht, and it's great that you're pushing on with it.

Could you consider uploading patches to the tracker early and often so that we can peer-review them before the first version is committed?

hybrid wrote:It will become the new Irrlicht animation system

sweet!

I am new here and don't know Irrlicht well enough yet, apologies in advance. Just some opinions from an old pro engine coder:

- Please, please keep skeleton and mesh (envelope) separate, this is really needed for commercial titles. You can provide a simple method for loading and managing both together in one go for convenience.

- Use of Quaternions is a must (for blending). they also keep the use of constant registers low since they need less space and have the advantage that there isn't any matrix drift (i.e. renorthogonalization needed after incremental procedural animations).

- Forget (but keep) the old interface, just start with a fresh IAnimatedMesh2. All the IAnimatedMeshSceneNode::getXXXJointNode() look like really bad design IMHO. Shouldn't we use a factory here? And an own data format has already been suggested many times

- Have a good look at OGRE's anim system (features here: http://gpwiki.org/index.php/OGRE). Not saying they are top, but at least the features sound good.

- Is there a .plan or roadmap document for Irrlicht? I see 100% for the animation system, but surely that's 100% for of out of date.

Might be best for Luke to go ahead as he pleases, and then to modify/improve as needed.

Just my ...

Tnx, Battlestar

Hehe, cool,

Could you consider uploading patches to the tracker early and often so that we can peer-review them before the first version is committed?

Yeah, of course,

Heres some wip stuff now: http://www.fileden.com/files/2006/8/10/ ... nnedMesh.h

Battlestar:

-Please, please keep skeleton and mesh (envelope) separate, this is really needed for commercial titles. You can provide a simple method for loading and managing both together in one go for convenience.

But for speed it’s best if the skeleton weights are directly connected to the vertices, this software skinning is heavy on the cpu. I can’t see any advantage in splitting the skeleton and the mesh.

I can see the advantage in splitting the animation from the skeleton, which seems what Saturn meant, and that’s easy/fast to do.

Use of Quaternions is a must (for blending). they also keep the use of constant registers low since they need less space and have the advantage that there isn't any matrix drift (i.e. renorthogonalization needed after incremental procedural animations).

Yeah, I’m using quaternions for animation/blending.

Forget (but keep) the old interface, just start with a fresh IAnimatedMesh2. All the IAnimatedMeshSceneNode::getXXXJointNode() look like really bad design IMHO. Shouldn't we use a factory here? And an own data format has already been suggested many times

Well the old animation interface is pretty basic and is easy to expand on, and that getXXXJointNode() stuff is very easy to fix.

Luke wrote: I can see the advantage in splitting the animation from the skeleton, which seems what Saturn meant, and that’s easy/fast to do.

Actually, I meant that too. Sorry.

NB: Rather than exporting matices. one could think of exporting the animation controller values, e.g the 3dsmax rotational/translational/TCB controllers. So for instance for a rotational joint only the pivot, the normal axis and the angle keyframes. But that would make the system much more complicated and usually doesn't bring that much. It can be added later easily anyway.

Seems we all agree we are on the right track with the anims.

Tnx, Battlestar

as per the discussion here, it might be a good idea to store the actual animated mesh data in the SceneNode, so that things don't have to be re-skinned many times per frame if multiple render targets are used.
Would mean a small API change (target SMesh param on IAnimatedMesh::getMesh), but I think we can live with that

Bitplane:

Hmmmm,

It might be better if something like this is optional,

As well as the extra memory needed, it’s is slower as the weights can’t be directly linked to the vertices.

It’s just most people are not going to need this, at least for now

If the meshes were optionally unique to each mesh then the skinning would be cached, and all would be good.

And with hardware skinning this wouldn’t be a problem.

Luke wrote:

-Please, please keep skeleton and mesh (envelope) separate, this is really needed for commercial titles. You can provide a simple method for loading and managing both together in one go for convenience.

But for speed it’s best if the skeleton weights are directly connected to the vertices, this software skinning is heavy on the cpu.

Call me stupid, but I don't understand this. Why do you see bone weights as part of the skeleton? They are part of the vertex data. Whether you seperate skeleton and mesh or not. Bone weights are per vertex. If they were part of the skeleton, than a shared skeleton would require all meshes using it to have the same amount of vertices with the same weights, which kind of defeats the purpose.
And hardware skinning is perfectly possible with separated skeleton/mesh. Again: I am not taking the position that you should do the separation. It is only, that I don't understand this reasoning.

And from me too many thanks, that your doing this task. It is a great improvement.

Culling is something else to keep in mind. I've already mentioned this to Luke, but in my ReflectiveWater demo I don't get any increase in framerate when the animated .X meshes are offscreen (5 Tiny's + 5 Dwarves, reflected = 20 model renders). I suspect they're still being skinned.

I admit I don't use .x format any more - I use B3D format. Even Lukes current code in SVN beats the heck out of any other format. A single Tiny.x renders at 78fps on my machine - my MultiAnimation demo shows that I can do 100 tiny.x at 95fps (hardware skinned and blending two animations).

Well I like the skeleton linking to the vertices method better then the vertices linking to the skeleton, that way your not jumping back and forward with different skeleton’s matrices affecting the vertices.

Remember that there can be multiple weights affecting a single vertex.

The ms3d, x and b3d animators use this method, I’m not sure why weights in the vertex data would be better.

If they were part of the skeleton, than a shared skeleton would require all meshes using it to have the same amount of vertices with the same weights, which kind of defeats the purpose.

No thats not really true, the weight data would be with mesh if it was spilt that way, but the same skinning method still works.

But there are lots of ways to spilt the skeleton/animation from the mesh.

Culling is something else to keep in mind. I've already mentioned this to Luke, but in my ReflectiveWater demo I don't get any increase in framerate when the animated .X meshes are offscreen (5 Tiny's + 5 Dwarves, reflected = 20 model renders). I suspect they're still being skinned.

I admit I don't use .x format any more - I use B3D format. Even Lukes current code in SVN beats the heck out of any other format. A single Tiny.x renders at 78fps on my machine - my MultiAnimation demo shows that I can do 100 tiny.x at 95fps (hardware skinned and blending two animations).

hehe, I found the problem, someone turned culling off by default in the SVN,

add: node->setAutomaticCulling( EAC_BOX);

Ah I totally misread you. I thought you meant with weights as part of the vertex data, you were stuck to software skinning instead of hardware skinning. But actually it meant, that software skinning this way is slower than software skinning with weights part of skeleton data. Clear now.

bitplane wrote:store the actual animated mesh data in the SceneNode

Yes, makes sense for CPU skinning and DX10 vertex write back, not so for DX9.

By the way, yesterday I managed to get 3dsmax Biped animations exported via FBX to X thanks to this loveley tutorial. Jeez ...
Could someone give me a quick pointer on how to export .b3d from max please, i.e. which plugin to use.

Tnx, Battlestar