Hi there, I've just started looking at JME to see if I can convert some existing code to use it. I have a number of questions which may seem stupid, or blindingly obvious, sorry about that.
How practical is it to modify the node structure in the scene graph while the game is running? By adding or deleting nodes? I'm worried about what I would have to do to release resources like display lists and textures.
Thanks for any help!
Actualy I am not sure if Displaylists are deallocated when you remove stuff from the scene graph. Might want to call unlockMeshes before detaching just to be sure.
You would just have to remove them from your scene, and call updateGeometricState which will create the new display lists or VBOs or whatever the implementation has decided to do. It is that simple.
Doesn't the opengl renderer replace display lists on an as needed basis?
No. The whole idea is that displaylists are as fast as possible to render. The programmer decides when a list should be made or destroyed (using the lock methods in jME, in our case).
OpenGL has no knowledge of your scenegraph anyway, a diplays list is exactly what is says, a list (of OpenGL commands that display things). There's no "objects" in there that OpenGL can detect changes on…
No, a display list is a precomplied set of OpenGL instructions that reside in the memory of the vcard. Therefore the OpenGL renderer knows when it was last accessed, how big it is, etc. Just like textures I believe it (the OpenGL renderer) is free to flush (or swap in and out of RAM) when needed.
Thanks for the replies - while OpenGL implementations may move textures and display lists to main memory from the graphics card if you leak enough of them this will still kill things.
To get jME to decide to use display lists you have to lock the mesh? Presumably it always allocates the texture or do you need to lock that as well?
Yes… locking creates the list or VBO according to the card capabilities. Not sure about the texture…but it should be in the card mem.
basixs said:
No, a display list is a precomplied set of OpenGL instructions that reside in the memory of the vcard. Therefore the OpenGL renderer knows when it was last accessed, how big it is, etc. Just like textures I believe it (the OpenGL renderer) is free to flush (or swap in and out of RAM) when needed.
Swap in and out of RAM, yes (sure, it can do that with everything)
Flush, no. Once created (or better put, compiled) a display list will always keep existing (unless you destroy it of course). After all, there is no way to garantuee that OpenGL can recreate the same list.
Locking in JME does nothing with VBOs. There are seperate API methods for VBO.
i'm building my dungeon out of nodes (zones) containing nodes containing only sharednodes containg the walls, ceiling and ground models.
i dynamically create and remove zones depending on which are visible right now. if i lock the zones, there will be display lists created for the meshes in the sharednodes, so i can safely detach zones without creating display list garbage, right?
Yes, make sure you lock the geometry inside the SharedNode, not the sharednode itself. Not sure if you can lock everything though, if you have problems, play around with the individual lock methods.
You may want a "leave dungeon" clean up routine btw.
i locked the sharednode itself without any problems. actually, i'm locking my dungeon on sector level.
as far as i understand, it delegates the lock to the contained node which then creates a display list for its mesh and locks its own bounds/shadows etc. which saves performance on updateXXX calls.
make sure you lock the geometry inside the SharedNode, not the sharednode itself.
why?
Think the reason why is that it is the geometries you want to lock, some of those geometries may be in other shared nodes. Also, you may wish to have some nodes with their own rotations etc