There are some quirks as to how the scene graph works in jME. Make sure all nodes have bounding volumes and updateGeometricState() is called. There might be other stuff I am forgetting…
Maybe the time to cull is too small compared to the actual rendering time, so that it doesn't matter much if culling speed improves ?
Can you measure, how much time is spent in culling compared to the other part of the update/render cycle?
Core-Dump said:
Maybe the time to cull is too small compared to the actual rendering time, so that it doesn't matter much if culling speed improves ?
Can you measure, how much time is spent in culling compared to the other part of the update/render cycle?
i wanted to measure that, but didnt feel like recompile a jar haha.
but the question is, if the time is so small, then it really isnt worth the effort to actually try to optimize the scene graph then. that in some sense also means that the jme scene graph culling isnt really helping on performance.
Momoko_Fan said:
There are some quirks as to how the scene graph works in jME. Make sure all nodes have bounding volumes and updateGeometricState() is called. There might be other stuff I am forgetting..
and i did that. but still, the results turned out to be exactly the same.
ive updated the code in the OP.
Hi,
Are the tests in package jmetest.stress not for showing those things?
I think the jmetest.stress.swarm.TestSwarm is very interesting.
Regards
i think the reason y my test results r some what biased in this case is coz that the frame rate is mainly GPU bound. i guess with a better graphics card, there would be a performance increase
You're right, in this test you are GPU bound so the performance increase of culling will not be noticed.
It is strange. I get a huge boost when I use a structured forest of non-acyclical graphs (between 16 and 90 FPS) rather than a simple tree with all children (about 11 FPS).