Frame-based animation/md2 performance issue

[npc]

Hi guys,

This might sound like a simple question, but I'm too stupid to figure it out so hopefully one of you knows the answer right away

I want to have models with a very simple frame-based animation walk (or better crawl) around a map. The model is not huge, it has 1,700 vertices and 3,400 faces. The only way I could get the (self-made) animation to work is through the old .md2 file format. Irrlicht is fine with a few of those, but at about 20 instances of the model, the performance goes way down, to about 15 FPS or less. The problem is that I need couple of hundreds of these models.

What's curious is that the performance remains bad even if I turn off the animation, or remove the animation from the md2 model altogether, it makes basically no difference, so it must have to do with the md2 format itself. If I convert the model to ms3d, then the performance is great, but ms3d doesn't support frame-based animations, as far as I know. I also tried converting to md3, but Misfit 3D (is there anything else?) complains about too many vertices in a single group (also tried to split it into multiple groups, the error doesn't go away).

I know that there are more elegant ways of animating models, but I just want a rather simple solution for now, and the rendering looks great if I only have one or two models. Also, md2 seems like quite an outdated format, but what else is there as an alternative? Any practical way in which other formats could be used to support frame-based animations (they are just darn easy to create, and besides, my model doesn't have any bones)? Or anything in particular that Irrlicht could have a problem with (I'm not using anything fancy, it's really just the models).

My system has a 4x3.6GHz core AMD processor, 16GB RAM, and is running Ubuntu Linux 14.04. Any help is greatly appreciated.

Merry Christmas!!

[chronologicaldot]

md2 is convenient indeed.
I haven't worked with it in Irrlicht, so no telling if this works, but you could try loading the mesh once and then assigning it to multiple scene nodes. The thing is, I don't recall if, for md2, this makes all of their animations act in unison (e.g. they all run, walk, etc. at the same time). Note that Irrlicht stores the mesh when you load it and there is no theoretical limit to the number of scene nodes you can assign it to. This saves memory, so you'd definitely want to do this for things like trees.

[Cube_]

... that sounds off, surely there's a theoretical limit? Something like uint_least32t or uint_least64t, I find it unlikely that there could be [infinite] references to one mesh, at best I could believe [a very large amount that's practically unlikely to be reached but that is nonetheless finite and thus has a limit]

[npc]

Hmm, 2 or 4 billion models would be nice, but for now, I'd settle for a couple of hundred

Anyway, the issue here has nothing to do with the animations themselves. If I place 20 ms3d models (with or without mesh caching, chronologicaldot, it makes no difference other than affecting load time) on the map and don't do anything else, Irrlicht runs fine at 60 FPS. If I convert the ms3d to md2 format, and do the same thing, it lags and doesn't get above 16 FPS. In other words: Irrlicht does something different or recomputes something if the model came from a md2 file that it doesn't do for the exact same model loaded from a ms3d file. The big question is: what exactly is the difference, and how can I fix it? I started reading through the md2 loading code, but haven't come across anything obvious - does anyone know?

P.S.: With ms3d models, I still get very good performance with 200+ objects. If only I could get these animated, I would be very happy...

[mongoose7]

Probably, MD2 is an animation format, so Irrlicht animates it, even if the animation is idle. Perhaps this could have been optimised except that no one loads an MD2 model to have it static. Your problem probably relates to animation and would be the same if you could animate the MS3D format.

If you used skinned meshes (B3D) you could use useAnimationFrom and partition the models according to which ones are doing what. If you want all models to have individual animations then you might want to look at hardware animation using shaders.

[npc]

Hi mongoose7,

Thanks! Yes, you are right, it does animate even if there isn't anything to be animated, and that's the issue - the MD2 animations look quite good, too, but it's somewhat of an overkill for what I am doing. I'll look into skinned meshes, but I found a solution that works very well for now, which is to load the models as ms3d, and then simply switch the mesh every other frame or so. I tested this with 4 frames/meshes and 200 nodes, and it renders just fine. And since the meshes are cached anyway, increasing the number of meshes shouldn't be a problem - I assume - since, in theory, all it does is switch mesh pointers. The other nice thing is that I can both individually animate each node, as well as switch to dynamic animation by manipulating the mesh vertices directly for the nodes in close range, so that they can get more expressive, and then I can spend resources exactly where needed, and spend less CPU for the ones in the distance.

[hendu]

So pretty much exactly what md2 and md3 do inside, except they also interpolate if you ask for a frame halfway. It's this interpolation that causes your cpu use. Your approach is completely fine, though.

[Mel]

Definitely go for the skinned meshes, all the engines out there use them now a days (morph targets can be used as well, that is what MD2/MD3 models do, but only for small stuff) and eventually you can move to hardware skinning when you need more complex meshes to be animated (30000 triangles per mesh isn't as crazy as it sounds with shader skinning for instance)

[npc]

Hey guys,

Thanks for your feedback, that really helps a lot! I think I'm all set for now (and it looks quite impressive ), but I'll definitely look into skinned meshes too, as that seems the way to go in the future.

Cheers,

npc

[hendu]

This sounds like a RTS, with hundreds of units. Skinning them all would just use up GPU power every frame for no reason - much better to waste the VRAM and switch like he's doing. It's the fastest possible runtime way, and the space used per mesh is tiny compared to a texture (OP's model would be less than 70kb - about the size of a 128x128 texture).

[npc]

Hi Hendu,

Can you elaborate a little bit more?

A little background: yes, it is for a RTS of some sort, it's an ant colony with hundreds of individuals, most of them controlled by some machine learning AI, which I run on a (beefy) server and use a wrapper around Irrlicht as the client. The thing about the animation here is that ants move quite quickly as a whole, and if you look at dozens or hundreds of them further away, they look good even if the animation is crude - as long as they do different things. Once you get close to one, or a few, ants can move in very complex ways, doing all sorts of signalling, biting, carrying stuff etc. - so that would ideally be animated in a more realistic way, hence the switching. Moreover, a single ant requires a fairly complex mesh model, otherwise it's not "creepy" enough, whereas on the other hand, their actions do not depend on their animations, i.e. if they are out of sight, the only thing that needs to be updated is their position, rotation, sound, and action. That also works in multiplayer, as long as the client determines what's in sight (modulo issues such as shadows, reflection etc., but I'll defer that to later).

Any thoughts that you have are highly appreciated!

[chronologicaldot]

... that sounds off, surely there's a theoretical limit? Something like uint_least32t or uint_least64t, I find it unlikely that there could be [infinite] references to one mesh, at best I could believe [a very large amount that's practically unlikely to be reached but that is nonetheless finite and thus has a limit]

I said theoretical not actual/real. There is definitely a real limit to everything in computer science, but for practical purposes, I don't worry about this one. There are limits in Irrlicht. One is the number of scene nodes you can have, and one is the number of vertices that can be output in one pass. You can get this number for OpenGL via the parameter MaxGeometryVerticesOut from the method IVideoDriver::getDriverAttributes(). That said, you obviously can't draw 4 billion meshes in the same frame.

Edit:
@npc - Do all of these ants need to act independently or can you do one scene node that draws a bunch of ants, each with their own parameters stored in a list?
I believe hendu was saying she thought your idea of switching out simple meshes was better than using a skinned mesh.

[hendu]

Skinning means that you're doing the interpolation on the GPU. Every frame, even if it matched the rest pose perfectly. It's a lot of calculations, and while the GPU can do it faster than the CPU, it is pointless to repeat it if you can cache it easily, like in your case.

When you have each frame cached like that, drawing it is therefore much faster, either allowing for lower-powered HW or saving electricity. There is no repeated work then, but you're trading memory for it.

[npc]

@hendu: Ah, I get it, thanks! Memory shouldn't be an issue, since all the ants look the same anyway, and the complexity comes from the movement, which can be re-used for all of them. So yes, there is plenty of CPU to either pre-calculate, or dynamically calculate for certain nodes if needed.

@chronologicaldot: I do have a list of ants, each with their own state etc., and they have their own scene node; I think that makes sense, because they do need to act somewhat independently (e.g. each ant can get lost and needs to find its way home to the others, or one finds food and communicates that back to the others). The idea behind that is that a very complex - and unpredictable - system can be built from relatively simplistic parts, but for that to work, they need to act as individuals. I can, however, also imagine a scenario in which they do act the same, but there will be a lots more of them... but let's get the basics working first, and I think this is on the right track now

[Cube_]

I said theoretical not actual/real.

ah, the kind of theoretical that ignores underlying datatypes - got it (if it used n-bit integers I'd accept it - but there's definitely a pre-decided datatype for the references, then the only things preventing infinity are memory, computing power, and opengl limitations)

in any case, this is offtopic and not really contributing so we should probably leave it here.