Hello all,
I've been experimenting with the TestIsland.java project … I like the way the water goes on for ever so I came up with an idea. I want a model of the world so I created a 512x512 Textureblock for each continent, each continent is built in its own class then added to the rootNode … but after I add the third terrain to the scene I quickly run out of buffer memory and I'm unable to add more continents. Why is this … knowing that most games will have way more objects than this why is it that I am running out of memory … shouldn't I be able to add the 7 continents and then some??
Is this a jme issue, or java memory issue (have you tried increasing the latter)? 512x512 should be okay… your sure of the size?
how are you adding the terrains? some code? maybe there is an error or bad practice…
It seems to me to be a java issue, I've tried increasing the memory but for some reasons had no luck … and I followed all the directions I could find as far as setting the JVM settings. But if you think about it doesn't this bring up another issue.
If I have to increase the memory on my machine wouldn't a user have to do the same, and I can't imagine having to try and explain to a non-tech user how to increase their memory just to play my game … makes no sence to me.
But in any event I combined all the images into one hieghtmap with a size of (256x256) once loaded I just scale it up to the size I need … looks great and frame rates are still maxed out which is nice.
Thanks for you input though.
well the game exe or jar file can specify alotted space for the jvm… at any rate, the question was really to try and narrow down the source issue not as a solution.
good to know you got it working though, still surprised you maxed out the java jvm, i thought it had 250 mb for data…
Regarding how to distribute your game, you can use launchers for Java like Launch4j (Windows only), which create a nice executable that you can prepare to include all libraries, native libraries and other options you need (like memory settings).
For linux you can create a shell script, or maybe you can find some Java launcher for Linux too.
Regards.
512x512 is a big terrain, you're talking about a quater of a million vertices.
Seven of those is a very complicated scene even now.
msj121 said:
well the game exe or jar file can specify alotted space for the jvm.... at any rate, the question was really to try and narrow down the source issue not as a solution.
good to know you got it working though, still surprised you maxed out the java jvm, i thought it had 250 mb for data....
ok thanks, thats great to know ... how about this ... is there a command or method you could use in your code to increase or decrease the JVM memory. And how do I know what it is set at to begin with? Ive used commands like
java -Xmx256M at the command line but never got a success or failure response, all I got was a JVM help menu. Couldn't find a command to see what to memory was set at.
In any event as I said I did get it working by combining all the 512x512 terrais into one 256x256 then scaling it up.
Alric said:
512x512 is a big terrain, you're talking about a quater of a million vertices.
Seven of those is a very complicated scene even now.
I kinda figured this myself ... as it was, with all seven terrains this would amount to well over 1.7 million vertices... seems like way to much for just a terrain.
you can use with the command line:
-Xms40m
-Xmx256m
java class -Xmx256m
not sure why it doesn't work for you, in fact you can edit your .ini file for eclipse and add the command in, so that you can have the extra space even when running from eclipse. also add to the eclipse file:
–launcher.XXMaxPermSize
256M
I am sure if you google it, you can find more info (changes depending on OS and jdk i think).
When it comes to things like this the only way to handle it reasonably is with scene management. You never want to render that much stuff at once. You need to split your terrain up into smaller parts and use LOD. No reason to render that terrain one mile away at full resolution, right?
Momoko_Fan said:
When it comes to things like this the only way to handle it reasonably is with scene management. You never want to render that much stuff at once. You need to split your terrain up into smaller parts and use LOD. No reason to render that terrain one mile away at full resolution, right?
LOD's one great scene management technique. In addition, in most cases there's no reason to use RAM and processing for terrain blocks of any resolution beyond a certain distance. Use sky boxes and fog to prevent the user from noticing that distant terrain blocks are not loaded.
Something else that anybody riding the performance edge with terrain should do is run tests to determine optimal X and Z scales, instead of using the defaults. Should be low enough to show the height variation that you require, and no lower. I forget if the stock TerrainBlock/height classes accommodate separate X and Z a.o.t. lateral, but you will usually want both lateral scales (X and Z) to be the same. To give you a starting point, I find that ~ 1 ft. in your game world scale is about right if you intend to use typical cams in an earth-like terrestrial setting. If you need to show small cracks or holes, you would need to reduce.
This is just one opinion. I'm sure there are others who get good results with other conventions.
Hmmm, I presume there are many efficiency techiniques, just mentioning the ram for anything, I personally increase my Ram for AI programming.
But yes, many LOD techniques are useful for vertices and textures, also culling with fog or in general is great, or using sprites for far off objects replaced at proximities, Vertex Buffer Objects (which I hope JME uses) etc…
is there a good LOD example out there ??? How would I aply it to my terrain??
There are several LOD and Terrain examples in the jME 2 code base, with appropriate class names. LOD can be applied to terrain Geometries the same as to any other Geometry.
blaine said:
There are several LOD and Terrain examples in the jME 2 code base, with appropriate class names. LOD can be applied to terrain Geometries the same as to any other Geometry.
I had a look and came up with this ....
DistanceSwitchModel dsm = new DistanceSwitchModel(1);
DiscreteLodNode dln = new DiscreteLodNode("lod node", dsm);
dln.setLocalTranslation(new Vector3f(-30, 0, 0));
dsm.setModelDistance(1, 0, 500);
dln.attachChild(tb);
dln.updateGeometricState(0, true);
rootNode.attachChild(dln);
But it didn't seem to increase the fps at all ... At this point I do have well over 200fps on average so I have a lot of room to play with given the huge terrain I have ... but as time goes on the game will obviously get more complicated ... I would just like to have the know how to increase any performance issues I may have.
well i think you can set the max frame rate, I wonder if the default is 200. Doing too many frame refreshes without necessity would likely slow down your computer without any improvement in look. I have no idea though, just an idea.
ok thats nice to know, On some of the terrain examples I've seen the fps are over 300 now thats fast, if I could set this as the game gets more complicated that would be great … anyone know anything about this … manualy setting the fps??
phmenard said:
ok thats nice to know, On some of the terrain examples I've seen the fps are over 300 now thats fast, if I could set this as the game gets more complicated that would be great ... anyone know anything about this ... manualy setting the fps??
Check the API for methods that take frame rate parameters, and classes with "framerate" in the name. You also have access to the update and render methods of the OpenGL thread, so you can throttle however you want to.
blaine said:
There are several LOD and Terrain examples in the jME 2 code base, with appropriate class names. LOD can be applied to terrain Geometries the same as to any other Geometry.
I've just learned that this actually depends on how you use the LOD classes. ClodMesh.create() actually changes vertex values, as opposed to just changing the index buffer. This has implications to making adjoining blocks line up, sewing, etc. Because of this, plus the catastrophic instantiation times of AreaClodMesh with terrain-appropriate poly counts, I'm embarking on a Custom CLOD implementation for my terrain blocks now.
I just posted a demo which includes my new, custom, large-scale terrain LOD.
http://www.jmonkeyengine.com/forum/index.php?topic=12357.0