Hi
A couple of questions-
My game project involves the player moving around a world which is updated by attaching new Nodes representing the landscape (containing geometry) ahead of the player, and removing other nodes behind the player,
These nodes can be up to several hundred, and there’s a lag in movement when all of these are attached/detached/moved at the same time (as the player moves through cell positions). So i’ve been looking at ways to optimise this, and can only guess that it’s to do with updateGeometricState. I’m confused about this method because of this https://wiki.jmonkeyengine.org/legacy/doku.php/jme3:updategeometricstate
Yet my project wont run without updategeometricstate - which is used quite a lot. I’m confused because I set up a simple BasicGame test with some cubes attached to Nodes - moved them around etc- but I didn’t need need to call updategeometricstate.
My game project however uses everything from collisions to filters, so maybe something in here requires the call.
I also started my project as a BasicGame template - so I don’t know if theres something else I should be doing in terms of OpenGL and rendering tricks not possible with this template to improve performance.
Any advice on improving performance with large amount of nodes being dynamically attached/removed/moved would be great, thanks.
updateGeometricState is not expensive. Whats expensive is pushing new mesh data to the GPU. Still I doubt it has to do with the attaching alone, probably more so with other types of processing such as collision information generation etc. You can prepare and load mesh parts if thats the problem then simply attach it on the render thread. If its really the amount of mesh data that has to be pushed then you will have to push it more gradually to avoid the lags.
all the mesh data is already pre-made - i’m just attaching and moving positions of them relative to the player as he moves.
the lag only happens with large amounts of nodes/geometry though .
what you suggested about gradual feeding of new geometry might help thanks.
That’s what Mythruna does… I only add one new terrain object per frame to avoid drops. The objects are built in a separate thread and then added to a queue that is drained one element at a time per frame.
thanks 
- I love Mythruna -
this is my game ‘Hexyle’
http://glennmarshall.wordpress.com/2010/12/04/hexyle/
when you say ‘thread’ do you mean actual CPU multitasking? (I presume not…)
I like idea the of the tile per frame method thanks,
hope to be picking your brains more about this kind of stuff
Actual CPU multitasking.
In networked play especially, the rendering of the ‘tile’ requires that it be fetched from the server and converted to a mesh. This can take a while. All of that is done on a worker thread that puts the results in a queue.
On update, one node is pulled from the queue and added to the scene.
I see - I’ll maybe look into multi-threading when my project develops more, sounds a bit daunting to implement,
for now I’ll maybe try a crude tile per frame method using a single call every frame update call.
quick question -
does removing tiles/nodes of geometry have any impact on the updating?
i’ve programmed in the gradual attachment of new tiles per frame, but I’m also removing gradually as well -
I’m just wondering is it okay to remove everything that needs to be removed in one go.
You can try it. I found this to cause frame drops at some point and I’ve never circled back to see if they’ve gone away now. I do one add and one remove or two removes per frame (<- it’s just how my parameters end up working as it’s controlled by variables)
yeah i’ll do some testing thanks…