Hi all, I have started looking into tearing down my scene graph, etc.
Using the Profiler I have been able to determine ‘my app’ no longer has refrences to any spatials, etc (including the rootNode).
However I am seeing something called LighList[] having many references to my spatials previously created.
Also of note, there are zero spotlights/lights, etc shown in the profiler.
So…this leads me to question, given a scene that has lights, what is the proper way to tear down the scene to ensure these lightlists remove there refrences as well?
I see spatial, exposes 2 methods: getLocalLightList(), and getWorldLightList().
Am I supposed to call these methods prior to ‘destorying’ a spatial, and explicitly call clear on these? 'shouldn’t removing of the light do this automatically?
Well are the lightlists still reachable from a living object? It is completely valid to have a network of objects that can no longer be reached, but are not yet gc’d, so this does not have to be an error.
Well, from what I can tell everything points back to GLContext having the ‘owner’ references (even though rootNode has no children).
also of note: this scene actually has no lights in it (everything is unshaded).
The objects are loaded via the assetManager.loadModel (blender loader)…and going throught the reference chain I do see BinaryImporter.
Which…kinda makese sense to me, I assume when you load stuff via the assetManager, it holds reference…is there a way to flush/unload the assetManagers references? or way to dump the current assetManager and obtain a new one?
As well, I tried clearCache() that appeared to have no effect
anyways I think I miss-spoke (typed) previously, its not actually spatials that remain in memory, but rather a bunch of spatial[] array objects.
The Spatial[] actually contains direct references Geometry Objects, my actual ‘Spatial’ count is in fact 0.
Many of the objects loaded up via the loadModel(…) contains instanced geometry from the blender scene, which I think could potentially explain why I still have a bunch of Geometry floating around.
If I trace the ‘parent’ node graph, from these geometries, they all eventually point back to the node representing the ‘blender’ file loaded.
guess my next line of attack will be to simply load up the scene, and tear down immediatly, to see what happens.
hmm, ok I just did a test, and I’m essentially seeing the same the thing (the number Geometry objects for the same .3jo file, I see is bit lower (147 vs 200+).
The code sample code is essentially:
[java]
public void simpleInitApp() {
setPauseOnLostFocus(false);
Spatial s = assetManager.loadModel(“Models/cleanTest.j3o”);
cam.setLocation(new Vector3f(0.0f, 29.5f, 25.2f));
cam.lookAt(new Vector3f(0f,0f,-5), Vector3f.UNIT_Y);
rootNode.attachChild(s);
} @Override
public void simpleUpdate(float tpf) {
tearDown();
}
public void tearDown(){
rootNode.detachAllChildren();
DesktopAssetManager m = (DesktopAssetManager)assetManager;
m.clearCache();
System.out.println(“torn down”);
}
[/java]
You are sure taht a gc was run after that? (enable verbose gc and make sure a full gc is done) since there is no gurantee when stuff will be cleaned up in java .
so…I added the gc, call with no differences shown, I am still seeing the 147 geometry objects.
I will try and come up with a simplified test scene, that I can perhaps upload somewhere.
I changed the teardown as follows:
[java]
public void tearDown(){
rootNode.detachAllChildren();
DesktopAssetManager m = (DesktopAssetManager)assetManager;
m.clearCache();
System.gc();
try{Thread.sleep(1000);}catch(Exception e){}
System.out.println(“torn down”);
System.out.println(“torn down”);
}
[/java]
logging output with verbose gc: (looks like).
[GC 3485K->3131K(125120K), 0.0005784 secs]
[Full GC 3131K->3059K(125120K), 0.0327545 secs]
torn down
torn down
If geometries would reside in memory I could not play Mythruna for several hours. Direct memory is not always collected even if the gc runs, maybe it has to do with that. Do you have an actual real world issue or why do you investigate this?
I wonder if the nodes are removed from the scene but then the update loop is not run anymore that the light list does not get rebuilt or something. Since he looks in the profiler and still sees references then that could be the reason.
If so, then that’s probably a false positive in this case. Since I don’t know why you’d want to empty the scene and otherwise keep running the app without then adding more things and rendering them (which would rebuild all of that stuff).
I’m only speculating based on the limited evidence presented… and the fact that as normen points out, Mythruna chews through Geometry objects like sweet candy and can run for hours and hours at nearly constant memory.
Yeah, I started looking into this due to huge slowdown (~40%) on android, essentially when I unload the scene graph, then reload to play another ‘map’, the 2nd ‘instance’ map played, is always much slower, and it continues to degrade each time I switch to a new map. On my desktop I do not notice nearly as severe a drop in performance, but…of course on my desktop the gpu can handle/memory/cpu can handle the ‘extra’ overhead, so I believe.
I can do a test that pspeed suggests, (load 1 blender file), then unload it, and load another scene or maybe even the same scene, and then check if I can locate ‘older’ geometries floating around.
