ISceneManager :: OnAnimate() question

[riveranb]

Just for curious,
Now in irrlicht, scene nodes sharing the same mesh source would share the same mesh buffer.
Is the reason for this choice that to save memory expense at run-time?

[mongoose7]

More than that, I think. The transformations are outside the mesh so only affect the world transformation. Therefore the one set of vertices can be sent to the graphics card and can be used to draw many instances. They can't be animated though (changes the vertices) unless all instances share the same animation.

[mongoose7]

And multiple scene nodes for holding the same mesh is also another big problem.
Now I still have no idea about solutions of this problem.
Anyway thanks again, hope that I can help a bit, maybe in the future.

If all nodes share the same animation then the skinning will occur once per frame. Well, they all have to have the same animation but they needn't be on the same frame. If this is the case, it would be better to load the mesh multiple times.

But what is the business case for many nodes holding the same mesh, with the same animation, but on different frames?

[riveranb]

Well, I'm a beginner in game develop. And I'm just throwing some confused or misunderstood questions.
So you can just ignore that question/situation.

I think I have to do more study on skinned / animated mesh.

[mongoose7]

Err, just a comment. I had a look at the code and I see you used a boolean. But then you had to pepper the code with changes. Hmmm, not good.

Better, I think, would be to set it to the number of the last frame skinned. This only needs to be set to -1 when the object is instantiated. At the start of the skinning code (skinMesh()?) you check if the current frame is the same as the last frame skinned. After skinning, you set the variable to the last frame skinned to the current.

Although, from what I recall, the frame number isn't passed into skinMesh()?

Hmm, didn't want this to get lost.

[hybrid]

Wouldn't have been, but anyway. So I don't have to quote your answer.
The change too bool was indeed because the frame is not passed to skinMesh and we cannot easily check against the LastAnimatedFrame value. Moreover, there are places where animation works ok, but joints are updated and we need to re-skin anyway. So we need several flag resets in the code. If there's one more now does not matter.

[mongoose7]

OK. Of course, it would be better to skin after setting the joints, but you can't know in advance if the joints will be set. Fair enough!

[hybrid]

Actually this was also just a wild guess for me (well, based on some knowledge about the internals and good gut feeling). I never fully understood the whole new animation system. Neither what things would happen typically in user code, nor what all these fancy extra methods in animatedmeshscenenode and skinnedmesh are meant for. That's why I also assess things wrongly. Just like my over-generalization of animate() and skinMesh(). So if my assumptions are wrong or just too pessimistic, just hint me to better results. I'd love to see a more streamlined skinned mesh implementation.