Guess I’ll put up my results on the test case:
assetLoader = false; (ie using BinaryImporter method) = it loaded 200 tiles and the max was about 74Mb Direct used.
asserLoader = true; (ie using AssetManager.loadModel() method) = went OOM on tile load 63 at about 250Mb Direct used
interesting…
Does the same issue occur when the TerrainQuads in the J3Os are replaced with regular models (e.g. Spatials?).
Caching behavior might work differently with terrain.
@Momoko_Fan said: Does the same issue occur when the TerrainQuads in the J3Os are replaced with regular models (e.g. Spatials?). Caching behavior might work differently with terrain.
Hi, thanks for looking into this.
I will test the loading of non-terrainQuads after I get home from work (8 hr shift just about to go there).
Although I’m thinking the issue wont be there, otherwise I’m sure this issue would have been noticed before.
Pure speculation here from a learning programmer, but I’m guessing its a reference fight between the assetManagers cache and the geoMipMapping stuff and/or the leaf-nodes caching their neighbors reference for that, tho sploreg did add a function to clear that reference there may still be that issue.
One possible fix / temp fix is to maybe get the assetmanager to not cache when it uses the terrainQuad loaders?
Just ideas, I’ll hack some more variations tonight when I get home.
Thanks
There aren’t any references being saved in the TerrainQuads or TerrainPatches. Just plain height data, a couple ints, floats, and Vectors.
When terrain is cloned a fresh new terrain is created with the height data. So loading the terrain as a .j3o probably is not the issue, and the asset manager should be calling .clone() on it properly.
@Momoko_Fan said: Does the same issue occur when the TerrainQuads in the J3Os are replaced with regular models (e.g. Spatials?). Caching behavior might work differently with terrain.
I just modified the test case to use geometry made of a sphere(256,256,64) and left everything else the same (just changed terrainQuad into Geometry)
Same issue: using assetManager the direct memory builds until it ooms
using BinaryImporter it doesn’t even build, just runs along no issues…
so @sploreg I do apologize for blaming the terrain 
tho I did say it was just noob speculation 
So where to go from here…
OK, I finally figured out how to setup a DesktopAssetManager manually ( Hey I’m learning 
) and get it to do the loading instead of using the base assetManager.
First run was just like before, leaking, so I then added the .clearCache(); method just before loading each spatial.
And what do you know, NO LEAK!!!
So in my little mind, the cache is the culprit, nfi how tho 
Was a challenge for me to figure out how to setup a new manager with the required loaders/locators but figured it out…
New main java file here for this one.
I think that’s it for my abilities atm… I guess I’ll continue on the code for now until i get more direction…
I had an idea in the shower this morning. And just reading your post I think it is confirmed. When using the asset manager to load the tiles it will create a unique key for each one, since they have different names. Then when it loads them, it will load and then clone one, giving you the cloned one and keeping the original in memory. Thus if you load with the asset manager you are doubling your memory consumption for the tiles. But when using the importer there is no cache.
Strangely had that same thought myself but wasn’t confident to say it.
Still doesn’t excuse it for not cleaning up and clearing the old cache itself.
Terrain tiles are kind of special when it comes to caching them: you really don’t need them cached as you only load and use them once (in terms of their relevance to the asset manager). Same goes for entire scenes. However. for many other spatials you might not have any in the scene but want access to them quickly so you can spawn a new one. So I don’t think the asset manager not removing the unused spatials from the cache is a bad thing, in fact I think it is good (pre-loading).
Maybe a method on AssetKey like setCache(false) would be useful.
In the mean time, you can just remove them from the cache right after you load them. Load them with the ModelKey and then just remove them. Two lines of code instead of one.
Yes, now I know how to use the DesktopAssetManager I’ll use that instead and manage the cache myself.
And yes cache is very needed in many cases eg grass… load once spawn 1000’s 
Maybe add some cache management functions to AssetManager like in DesktopAssetManager ? just to save others some effort. if that’s possible?
Otherwise the only other way around it is to somehow make the cache management smarter and.or more aggressive in managing its usage… again if possible.
I seem to be OK on this for the time being in my case, if there’s anything else I can help with please let me know.
Again thanks for all