.MD2 have better performance than .X

[Noiecity]

I just confirmed that animations in .MD2 have better performance than .X files, they also weigh half as much (md2=275KB, x=563).

I compared them under the same circumstances, the only difference is the rotation(it looked like this when converting the file).

The md2 file does not give me bones with which I can relate an external object to the model, it is probably because of this that it offers more FPS. That is, it gives me only one bone, while the .X file gives me all the bones of the rigg, it is probable that the md2 file only works with the positions of the vertices, without relating bones, like the sydney.md2 model.
Interestingly, it is also possible to create different animations and call them by name (as in the hello world example in the documentation).
You can call it by the names already created or simply with its name inside quotation marks, for example node->setMD2Animation("stand");

I did a quick test so I experimented with a single texture(see the axe).

irrlicht needs a functionality that lets you choose the initial and final frame of the loop, without having to restart the animation when modifying this value (as it happens at the moment), so it would be easier to work with different animations and their intervals.


.x


.md2



(convert file software: fragmotion)

[CuteAlien]

md2 is a binary format, .x is a text-based format - that's likely why it's smaller. At least for this case. I don't know that much about .md2 really as I haven't worked with it yet, but I just checked the source and if I understood it correct on a quick view it saves the whole mesh per frame. And then interpolates between those frames. So indeed no bone-based animation. Which has advantages sometimes (when meshes are small and the animation is short and fixed). Thought with enough long animations it's probably going to be way larger.

And Irrlicht doesn't really have unified those animation systems aside from the interface. But in theory it would be possible to create a frame based animation like that from a bone animation system to cache the frames. Which could be quite useful for optimization (I thought about that a few times already) in some cases (small, fixed animations for small meshes).

But well, something for the far future I suppose. Unless someone else works on that.

Bit tired right now, but I guess setFrameLoop could have another parameter to avoid resetting the loop. As workaround I think you can remember last frame before changing it with getFrameNr() and after changing you can set it again with setCurrentFrame (and don't ask me why those 2 function names aren't symmetric... I'm pretty sure they are about the same thing).

[Noiecity]

md2 is a binary format, .x is a text-based format - that's likely why it's smaller. At least for this case. I don't know that much about .md2 really as I haven't worked with it yet, but I just checked the source and if I understood it correct on a quick view it saves the whole mesh per frame. And then interpolates between those frames. So indeed no bone-based animation. Which has advantages sometimes (when meshes are small and the animation is short and fixed). Thought with enough long animations it's probably going to be way larger.

And Irrlicht doesn't really have unified those animation systems aside from the interface. But in theory it would be possible to create a frame based animation like that from a bone animation system to cache the frames. Which could be quite useful for optimization (I thought about that a few times already) in some cases (small, fixed animations for small meshes).

But well, something for the far future I suppose. Unless someone else works on that.

Bit tired right now, but I guess setFrameLoop could have another parameter to avoid resetting the loop. As workaround I think you can remember last frame before changing it with getFrameNr() and after changing you can set it again with setCurrentFrame (and don't ask me why those 2 function names aren't symmetric... I'm pretty sure they are about the same thing).

Thanks for the information, then I will try to work with getFrameNr()