I tested this on 3.1 stable as well as the newest version of 3.2, and I’m finding that whenever I edit terrain and save the j3o file, the direct memory usage continuously goes up until you it eventually reaches a point that loading a simple terrain tile takes 1500 mb and you have to throw it away and start over. I can make an extremely complex terrain that takes up less than 100mb, but if I re-open this terrain in the editor to sculpt or paint areas that could use cleaned up, the memory goes up by a small amount every time. Even when I go back in to flatten out the terrain, the memory will go up.
Could someone please test what I’ve been doing and let me know if this happens to you?
Createa a new empty j3o scene
Open in the terrain editor and create a terrain of any size
Sculpt some hillis and save the terrain
Run a test case where you load this j3o file and use the following code to see the direct memory usage
float amt = MemoryUtils.getDirectMemoryUsage() / 1000000;
System.out.println("Mem: " + amt + "mb");
Re-open your j3o file in the terrain editor and flatten out the hills, so that the terrain looks like it was just generated
Run the test case and compare the new direct memory usage. Is it higher or lower than the original amount?
For me the result is always higher, and if i repeat step 5 the memory just keeps going up. Everything else is working perfectly fine with the terrain editor and I’ve been able to make some amazing landscapes so if anyone could let me know if this happens to you as well I’d really appreciate it, thanks.
Yeah it happens even in a jme game, and the j3o file size also grows after every edit.
And thanks I’ll have to look at that when I have some time later on to work on this some more. My best guess so far is that it has something to do with the history system for j3o scenes- it makes sense that the file size grows if it has a history feature, but I’m thinking the asset manager is also loading and caching all of this extra data in the j3o file when all you need is the most recent splat map and height map.
I don’t think that j3o has some versioning features at all, technically a terrain is only a few textures before loading.
How does the file size grow? Because if its only low, it could be related to the texture file format like you add more entropy and hence the size grows.
Because it does not store any pixel which is not black but uses some complex compression. And in addition to that you can’t probably flatten the terrain 100% but have heights of like 0.00000001223.
Maybe its not even a bug then but a limitation there?
I got the file size to grow by 20kb and it also took up a very small amount more of direct memory in game from renaming a terrain and saving without doing anything else.
And I was wondering if it was possibly storing really low values and that’s causing the problem, but wouldn’t that cause any and all complex terrains to follow this rule regardless of how many times it was resaved? I didn’t go in depth off all the testing I’ve done to see if this was actually happening, but I can create a terrain, open it, and I’m able sculpt and flatten cliffs for as long as I want as long as i want with no drawbacks as long as its the first time ive opened it, and it will have a very low memory usage, but if you reopen and resave it after making the tiniest changes it will go up no matter what.
I hope It’s not just a limitation because then it would be impossible to edit a scene’s terrain more than 4-5 times after creating it, unless there’s some way to extract it’s heightmap and splat map and assemble it with code to bypass the extra memory that keeps going up
I just ran the profiler’s object mode with my test case in two scenarios, and I tried to highlight the objects that have to deal with terrain, I hope I’m not missing any, but it looks like there was a difference.
First I made a new terrain again and sculpted some hills, saved it and ran the profiler with these results
Then I re-opened my terrain in the editor and changed the height of the hills i had already sculpted and ran the profiler again
It looks like the second case has 150% the amount of every terrain related object that’s found in my first scenario which was only saved once after initially being created. So it looks like every time a terrain object is saved as a j3o, it recreates all of its fundamental data rather than overwriting it? I’m just guessing but I assume these objects shouldn’t all increase this way when I barely changed 5% of my terrain.
Has anyone else noticed this issue, or is there anybody who can please run through the few steps in my original post to try and recreate this issue on another device? It should only take 10 minutes or less
I don’t like running around yelling that something’s broken before I’m certain this is a real issue with the SDK, but this is the only thing holding me back now from finishing my game I noticed this issue nearly a year ago when I was new to jmonkey and didn’t know it was a potential SDK problem; I was beginning to think it was nearly impossible or just extremely difficult to create a low poly scene above a size of 256 and I was really discouraged, I even threw out models with 5-10k polys because I thought these were the issue
Maybe @nehon or @Momoko_Fan can help here?
The only thing I can tell is that I am uncertain whether it’s related to the SDK or rather a bug in the Terrain System in conjunction with MipMaps(?) or maybe that the SDK triggers some pattern which crashes the Terrain System?
I’m not at all sure where the problem may be, I have little to no knowledge of the actual workings and code of the SDK or terrain editor sicne im fairly new to jme still, otherwise I’d try to be more of a help rather than just pointing out a problem but I’d still like to try and help in any way I can if this really is an error for the SDK or Terrain System, and not just something I messed up on my device
Well I think someone else already complained about this so I am suspecting it’s not your device.
Unfortunately I am neither really experienced and short on time, which is why I can’t help you out much.
Maybe you can get the textures out of the j3o file? In that case one could run them through like Photoshop (maybe with the negative layer blending), so you could see the actual differences.
Just to be clear: The file size does not grow as rapidly (like the aformentioned 1.5GB)
Yeah I was wondering if there’s a way to do that and also see the image files that make up the terrain like the splat and heightmaps. And for that unusually large terrain that took up nearly 1500 mb in- game, I edited it nearly 50-60 times before it got that high, but you’re right the file size only grows by a small amount each save, so if you can make a terrain in 1-2 edits it will usually work out even though it still takes slightly more memory than it should.
java.lang.IllegalStateException: Scene graph is not properly updated for rendering.
State was changed after rootNode.updateGeometricState() call.
Make sure you do not modify the scene from another thread!
Problem spatial name: Root Node
at com.jme3.scene.Spatial.checkCulling(Spatial.java:361)
at com.jme3.renderer.RenderManager.renderSubScene(RenderManager.java:719)
at com.jme3.renderer.RenderManager.renderScene(RenderManager.java:712)
at com.jme3.renderer.RenderManager.renderViewPort(RenderManager.java:1086)
at com.jme3.renderer.RenderManager.render(RenderManager.java:1145)
at com.jme3.gde.core.scene.SceneApplication.update(SceneApplication.java:321)
at com.jme3.system.awt.AwtPanelsContext.updateInThread(AwtPanelsContext.java:194)
at com.jme3.system.awt.AwtPanelsContext.access$100(AwtPanelsContext.java:44)
at com.jme3.system.awt.AwtPanelsContext$AwtPanelsListener.update(AwtPanelsContext.java:68)
at com.jme3.system.lwjgl.LwjglOffscreenBuffer.runLoop(LwjglOffscreenBuffer.java:125)
at com.jme3.system.lwjgl.LwjglOffscreenBuffer.run(LwjglOffscreenBuffer.java:156)
at java.lang.Thread.run(Thread.java:745)
File terrainE.j3o saved successfully
Creating an empty scene, then using the terrain editor to create the heightmap throws this exception also.
Plus the other memory problems mentioned where just opening up the j3o in the editor and making any change increases the file size and memory usage eventually to an unusable size.
Edit: Doesn’t do this exception everytime either.
Edit2: Can reproduce if I exit and restart SDK. Create the empty .j3o and, use terrain editor to create the heightmap and then exit the terrain editor. Seems to only do it that first time using the terrain editor basically.
I just downloaded and gave it a try and it looks like the problem happens there as well. Although I did notice that with the ss editor it can only happen once every time you open the file. So if I already have the j3o file open in your editor then saving it again will not cause the memory to go up, but if i close the file and reopen it then the next save will cause its memory usage to increase by a small amount the same way the scene composer does.
I’ve been looking into this more and it looks like its a bug with j3o files that only occurs after you’ve added a terrain to that file. If you right click on a j3o in the SDK, you can see a “show history” option, and if you view the history of a j3o containing a terrain, its full of multiple copies of the file.
The “show history” window is empty for all my other models that don’t contain a terrain in the scene.
I had some time to try and look into the real cause of this further but didn’t get far; I tried to look through some of the engine’s source code for the terrain editor and scene composer, but i’m still completely unfamiliar with most of the source code since im still newer to JME, and I don’t know if I was looking in the right places at all I understand most developers don’t have time to fix little bugs in the engine like this since every developer runs into their own bugs and has their own requirements for their game, so I’d like to try and familiarize myself with the engine and sdk source code more to fix something like this on my own, so if anyone could atleast point me in the right direction to start that would be great. Thanks
Thanks, that’s interesting if it’s only happening to me on both of my devices; I’m going to double check my secondary device to be certain that I was actually able to reproduced the issue on both, but if I’m correct this happened to me in both the SS editor and SDK terrain editor on both of my devices, although in the SS editor it only happened once I saved and restarted the whole editor.
I double checked and it happens to me on both devices, although I only checked it with the SDK on the other device since the SS isn’t on that one, but on my primary computer it occurs on both the SS editor and with the SDK running 3.1 and 3.2
I noticed this issue nearly a year ago when I was new to jmonkey and didn’t know it was a potential SDK problem; I was beginning to think it was nearly impossible or just extremely difficult to create a low poly scene above a size of 256 and I was really discouraged, I even threw out models with 5-10k polys because I thought these were the issue 
but I’d still like to try and help in any way I can if this really is an error for the SDK or Terrain System, and not just something I messed up on my device
I understand most developers don’t have time to fix little bugs in the engine like this since every developer runs into their own bugs and has their own requirements for their game, so I’d like to try and familiarize myself with the engine and sdk source code more to fix something like this on my own, so if anyone could atleast point me in the right direction to start that would be great. Thanks 