setFrameLoop causing performance issue?

[cww]

Hi,

I am using latest irrlicht ogles branch on Android and am facing a performance issue when setFrameLoop is being used. I have a considerable number of animated mesh nodes in the scene, and irrlicht is able to animate them at around 15 fps if I do not use setFrameLoop on the nodes (basically irrlicht just loops through all the frames over and over again). Once I use setFrameLoop, however, the performance can drop significantly, to say to 2-3 fps. Anyone has any idea on what might be wrong and how I can work around the problem?

Thanks in advance on any advice or help.

Regards.

[CuteAlien]

Only idea I have right now is that maybe the part where you use setFrameLoop has a lot more keys than the whole animation on average. So those might be the keys with really bad calculations.

[cww]

@CuteAlien Thanks for the suggestion. To verify this, I tried node->setFrameLoop(0, , node->getMesh()->getFrameCount()) so that it animates through all the frames, but still face the issue, hence I doubt that's the cause...

[CuteAlien]

Clever test... I'll check if I can reproduce that on PC as well (or maybe with Android next week).

[cww]

Hi CuteAlien,

Thanks for offering to help. I did some more test and also looked a bit into irrlicht source code, turns out my original good performance (~15fps) is unrealistic and is a result of me using irrlicht in an unnatural manner, i.e. I loaded many nodes of the same 3d model at startup, and the 3d model is loaded as a skinned mesh in irrlicht.

During rendering, the mesh is animated for the first node, but since all subsequent nodes are also at the exact same frame, the mesh is cached internally and no longer needs to be animated. Hence, when I set each node to a different frame, the performance appears to drop due to 'additional' mesh animation required, but is actually the correct performance under normal use cases. So I believe the fault lies with me and nothing wrong with irrlicht.

Sorry for the false alarm.

[cww]

I have a new observation that HardwareSkinning (a private bool) is false in the corresponding CSkinnedMesh instance. I am hopeful enabling this can close the performance gap (please correct me if I am wrong). Any idea if this can be enabled in for ogles1? If yes, how?

Thanks!

[CuteAlien]

Sorry, I don't know about that yet. But thanks for the info above - this explains it certainly.

[Nadro]

This method will be useful in future, anyway not for OGL ES1 driver. Skinning on GPU require shaders and OGL ES1 doesn't support it.

[cww]

Hi Nadro, thanks for the info. I thought over this for some time. For my usage, I don't think I can get reasonable performance without hardware skinning. Irrlicht is ideal for my usage except for this last case, do you think it is feasible to hack a simple custom scene node that does hardware skinning on ogles1 using matrix palette extension? I will like to give it a shot if deem feasible. Thanks!

[Nadro]

You should modify Irrlicht source to apply this feature. Built-in vertex format which will support bone weights and indices will be helpfull too. Anyway next fixed vertex format should be really easy modification. When mesh buffer is drawing and SkinningVertexFormat is in use you should activate matrix palette.

[hendu]

Restricted fixed-function skinning? Yeah, it does seem possible, if your hw supports that.

Alternatively, if you have a small-ish set of animations, you could precalculate all of them, meaning no cpu overhead at runtime.

[cww]

@Nadro thanks for the pointers! I will go in the recommended direction.

@hendu i did consider creating a map of {frame => animated mesh} as cache so that each frame is only animated once, but fear it may become another bottleneck further down the road, hence think will stick to the fixed-function skinning. iOS devices (3GS onwards I think) support matrix palette and I am hopeful most newer Android devices support it too.

[Nadro]

If you target app to iPhone 3GS or newer device you should use OGL ES2 instead of ES1.

[cww]

I am staying with ogles1 cos it is better supported by irrlicht at this point in time? I tried v2 and didn't get it to run properly, hence thought it will be more tricky.

[Nadro]

If you use custom shaders (it's recommended in OGL ES2) all should works fine, but you will get better performance than in OGL ES1.