Is there a way to get animation data from a mesh and insert it into another mesh?

[CuteAlien]

Very Sleepy is a stochastical profiler. It stops the running programming once per ms or so and just checks where it is at that point. Meaning it's bad to profile single functions, but it's quite good in pinpointing bottlenecks in game-loops and gets better the longer it (the same stuff) runs. Also it's big bonus is that it's so simple to use. It's so simple you sometimes can even get customers to use this and get info from them! Just ensure your program is compiled with pdb information. There is some misleading info in the results as it's only checking a single thread, but for Irrlicht that tends to work well ;-)

[SomeGuyWithAComputer]

Hmm, I'm developing this on Linux. It's been a while since I last had my project running on Windows. I think I need to make a system of converting file path forward and backwards slashes based on platform before it would run on Windows. Basically all the game resources are loaded based on data in xml files but my xml parsing system is platform independent. I've also added Open AL and FreeType since I last tried it on Windows so I'll have to figure out the linking for that. I am using threading via pthread but only for sound at the moment. Using VerySleepy is not a readily available option for me right now but std::chrono is really powerful if used correctly.

I wrote me some quick test for EJUOR_CONTROL: https://github.com/mzeilfelder/irr-play ... ontrol.cpp

In your example, where do I get the exampleHelper.h file? I want to plug my meshes into it and see if I get the same performance impact or not.

Also my approach of fenangling the ISkinnedMesh keyframes to circumvent these awful performance issues ultimately failed. I was actually able to mathematically compensate for most of the unpredictable rotation stuff but bones that have anything to do with inverse kinematics behave so unpredictably that I had to give up. This would have solved my performance problems but I guess I'm stuck with IAnimatedMesh.

I thought I was on to something yesterday but it turns out I wasn't. I found that if I cut down on the face count of my meshes by not making them double-sided, it resulted in more than a 2x performance increase but ISceneManager::drawAll() still takes around 20ms-22ms per frame if I add 2 animated characters with 2 articles of clothing each. Triangulating all the faces instead of using quads increases the performance impact and makes things much worse. When looking away, the framerate shoots up to 60fps and ISceneManager::drawAll() stops taking so much time. I've tried adding different culling settings to the clothing nodes but it has made no difference. I also speculated that perhaps faces clipping into each other causes lag but I have single sided, non-solidified clothing meshes with 400 vertices that lag things into oblivion and making it "fit" looser just isn't changing how slow it is.

I don't believe putting ISceneManager->drawAll() in a separate thread would even work but if it miraculously did work it would allow me to have like, 4 animated meshes on the screen at the same time and still maintain 60fps. Has anyone ever done that before? I know this 100% can't be done with SDL but maybe Irrlicht is different. I have to either figure out how to make drawAll not take so much time, improve it myself somehow or switch to Godot and start all over. It's frankly my fault for not noticing this performance limitation in the beginning before I spent a year doing all the stuff that led to this point I guess.

[CuteAlien]

On Linux you can use valgrind --tool=callgrind <yourtool> to get similar profiling results. Run it on any application as long as it's compiled with debug-data. The longer you run your game-loop with this the more exact the results will be. So compile with release optimizations (NDEBUG), but add -g in the compile options (add it to the CPPFLAGS in the Makefile). This gives you results in some file called callgrind.out.<id>). To interpret the results there are several tools like callgrind_annotate for command line or for UI kcachegrind is a nice one. The advantage over using std::chrono is that you don't have to code any tests. Using such a profiler is kinda the first lazy step before you even start putting in real work in hunting down speed problems.

You descriptions sounds a bit like the per-vertex operations might be too many - which makes sense in a way. But it shouldn't be much slower then with bones than with modifying the joints directly but about the same speed (as in both cases it will go over every vertex). That's why I suspect something else is going on.

As for threading ... what might make sense in this case is threading each animation step per node. So skinMesh in parallel would make sense to me. Or those functions which call it - so going upwards that would be getMesh -> getMeshForCurrentFrame -> OnAnimate. Now there is a bit of a problem because OnAnimate is automatically called in SceneManager::drawAll... but I think it might work nevertheless. Because our timer is using virtual ticks - which are only increased once per frame. And for the skinning there seems to be a test if that frame was already skinned. So if you manually call OnAnimate on nodes before scenemanager->drawAll you can probably do that in parallel threads. Slight overhead is that transferJointsToMesh will likely be called several times, but that should be cheap I think (and if not we can work on suppressing that or I'll finally add some variable to drawAll which allows suppressing animation).

exampleHelper.h is in the Irrlicht trunk header files. So if you copy my code over some example it should directly work.