Memory leaks

On running TestGameStateSystemSystem, it highlights that memory is being eaten and not released.

Each time you press enter and escape ( one state cycle ), memory consumption increases.

Have the same issue on the project that im working on. When the system needs to display a different scene, it reuses the top node ( rootNode ) and detaches all children before preparing for the new scene graph. the new scene graph once created is attached to the top node and the update cycle is restarted. However, there is something left behind that it released and memory continually increments on each scene switch.

It helps to null out items like terrain page and detach all of its children before hand, but im still getting memory consumption increasing like TestGameStateSystemSystem when a new scene is built ???

On running TestMotionBlur, the issue can easily be highlighted by pressing g. This loads new Textures.

Try it, make sure you can see the memory usage for the java thread when you run it. Memory usage will only increase

It looks as if unreferenced textures are not being garbage collected. The same issue happens with texture spaltting

Is there any way to clear down the textures. Ill try and delve down deeper, but im not a LWJGL specialist so it may take a long while

Can this also be confirmed as a bug

Textures can be cleared by calling TextureManager.doTextureCleanup() to remove it from the card and then TextureManager.clearCache() to remove it from memory.

the methods TextureManager.doTextureCleanup(); and TextureManager.clearCache(); are indeed like significant colonic irrigation. Thanks for the suggestion

tried on TestMotionBlur, looks pretty washed out however after either of these methods are called

if( KeyBindingManager.getKeyBindingManager().isValidCommand( "g", false ) ) {





seems that ALL textures are garbage collected including the ones in the active scene whene using either methods ?? any other ideas. Guess there are two states to consider - a total flush and throwing away the last spatial texture

Im Using the profiler with java hprof - rather nasty -Xrunhprof:heap=sites,cpu=samples, if anyone knows of a decent one please say so

Looking into SceneElement.setRenderState

looks like it simply doesnt try and clean up any replaceemt textures in the line renderStateList[rs.getType()] = rs;

should TextureManager.releaseTexture(Texture texture) be called before hand ???

Pondering further - its quite reasonable from a performance thing to simply replace the texture of a sceneelement.

the tricky part is how to release its former texture state and to know that there isnt any other scene element also using that texture. Seems that one cannot rely on the good old JVM garbage collection for this - or am i wrong…

It also means that there is a significant floor in the core as it stands if im right, or it needs to be highlighted that all texture references need to be explicitly cleaned when it is known they are not needed.

Maybe its only a few rare cases where a player would be on a terrain, and the game uses texture splatting to show players highlighted. for each splat, a duplicate would be added into the cache and maybe its just on splatting/renderpass/motionblur/ ? shadows  that the old texture reference should be explicitly cleared.

Not sure if i am reading it right, but seems that texture manager is caching all textures, however the cache does not know if the texture is still needed and therefore maintains the texture in the cache until explicitly cleared.

Help pls - cant see how anyone can release any serious game with this happenning. Would be pleased to help out if i knew where

Have found that SceneElement.setRenderState actually returns the old state, so the developer can choose to clear down this TextureState on adding a new state - this works fro splatting-

Experimented with adding this method into SceneElement

public void clearTexureStateFromTextureManager() {

What needs cleaning about alpha or material?

Will alpha/material states need to b cleaned. GLSL do

In the current state, I agree about the shader states.  Those are likely to be drastically changed in the next release or so though.

Its ecouraging to hear that shaders will be changed, so this issue will go.

Guess my concern on using TextureManager.doTextureCleanup() and TextureManager.clearCache() is that it will clear everything - including the cursor, the fonts for the FPS node. Any JMEDesktop will alo get flushed

If using gamestates, and one state required a complete cleanout. How would this be done without cleaning up textures you want.

Dont know how three rings are doing it in bang howdy, but i guess they have a resolution somewhere, but when you finish one of the gold games, they mut remove all of the models and textures from memor,

Well, those two methods are mostly for game cleanup or perhaps major game state changes.  If you are doing constant texture (re)generation (which personally I would try to avoid) I would instead use TextureState's deleteTextureId method to remove an old specific texture (by id) from the card and one of TextureManager's releaseTexture methods to get it out of the cache.

Thanks renanse, take your point on texture regeneration, much better to reuse the Texture than replace

How would you go about clearing renderstates on a node and children ??, something like


Or can you see any pit falls

I would write a simple recursive function that takes a Spatial.  Something like this pseduo code:

clearTextures(Spatial spat) {

    TextureState ts = spat's tex state;

    for each Texture in ts:
        remove the texture from the cache


    if spat is a Node.
        for each child of Node

In the next checkin, I'll add a method to TextureManager for passing in a TextureState.  Textures in the texture state will be removed from the cache.  Then you can call that method instead of looping through the state yourself and calling delete for each Texture.  Actually, I'll just overload the deleteAll method with one taking a boolean that will clear cache if set to true.

Hope that helps.

:smiley: That sounds perfect !!