Adding an animator makes the whole thing so slow

[KP84]

But I can't understand the slowdown when I move the camera instead.

If you have a terrain and a camera and you rotate the terrain OR you rotate the camera around the terrain, basically the same thing is happening.

Have you watched it as a wireframe? Then you can see what is happening. Use a FPcam too to see, so you can see updates when you move.

It's recomputing it's patches everytime the distance between the camera and the terrain is changed then saves the indices in the patches to an indexbuffer. At least something like that. Then it renders the 'new patched indexbuffer' until the distance is changed. That distance check is happening at line 597-613: CTerrainSceneNode.cpp

LOD systems are strange things actually. There goal is to reduce gpu time, to do that the cpu gets grazy when updating resulting in exactly that thing wich you want to avoid - low FPS rate - so that update should be reduced and you get some neat terrain.

Maybe the next three functions can manipulate the update LOD update.

Code: Select all

CTerrainSceneNode::
virtual void setCameraMovementDelta(f32 delta);
virtual void setCameraRotationDelta(f32 delta);
virtual bool overrideLODDistance( s32 LOD, f64 newDistance ); <-- not sure about this one but sounds interresting :)

Don't know what an Android is but it sounds very compact and tiny, so try to smooth the heightmap as file instead of using the smoothing factor in the code. That should help too.

KP84

EDIT: By the way, it's not computing anything on load, just loading the heights from the file then only calculating the smoothing and normals. When the node is being registered for rendering (line 568) it will check if recalculating is neccesary. That check is done every frame. And when the distance isn't changed out of the movement/rotation delta, it is skipping the recomputing thing.

btw btw: Thus the smoothing is only done once.

[ratamovic]

Thanks for your answer KP84.
I am a bit suprised by what you say because I see in the doc that Irrlicht terrain is using the geomip-mapping algorithm whose goal is to unload the CPU by buffering LOD chunks in graphics memory. Except generating some index buffers dynamically (or even better just degenerating a few triangles), it should not be "CPU-heavy".


Actually I think I found my problem and the good point is that it's not related to Irrlicht. The bad point is that it seems related to my hardware/OS. I found some "CPU may be pegged" messages in Android logs. A discussion on google groups indicates that this problem is especially related to HTC devices...
http://groups.google.com/group/android- ... nGL&lnk=nl&

It seems that there is a kind of bad lock happening during surface processing. A trick is to use eglWaitGL() right before eglSwapBuffers(...). This actually works (no sudden and awfull slow down) but FPS is rather reduced (barely acceptable)...


Irrlicht is acquitted! Thanks a lot for your help anyway .

[KP84]

I am a bit suprised by what you say because I see in the doc that Irrlicht terrain is using the geomip-mapping algorithm whose goal is to unload the CPU by buffering LOD chunks in graphics memory.

Don't pin me down on what I say, it's only my finding and I am no irrlicht nor a c++ guru. Just finding things out together. thanks for the word geomip-mapping to use on my search.

Ofcourse it is unloading the CPU but somehow it is needing all the data to determine what indices should be displayed. At least that sounds logical to me. By setting the deltas you decrease the CPU load due to the lesser calulations (and lower quality). Loose the distance check and I think you will get the same output as you experienced

Google search, maps, groups, adds, computer CRACKING devices in front of your home. Is there any way to get rid of google or not? Sorry just getting neurotic everytime I see the name (not a word) Google. They're actually found guilty in many countries and never have been acquitted. Nevermind

Good news you have found the problem.