Simple but importatn question, what is the maximum size of a world(well more a empty box, but whatever) that jme is able to handle?
It all depends on the accuracy you are seeking. Generally speaking, you could make it any size you want. Keep in mind that in order to see really far distances, you will need to adjust the far clip plane of the camera frustum, which may lead less accurate depth testing(?). (Going from something I remember reading, I'm sure I'll be corrected if I'm wrong.)
nope, that's pretty much it right there.
(except to say that worlds that are really big or really small will suffer from floating point error…)
So theoretically a Solar System is just fine, if I don't care about mm/cm
Yes. You could even scale your whole scene down towards units of 1, if you ever run into floating point issues.
You just need to use some means of varying the size of the units.
Precision at huge scales is only really a problem if you need huge distance and precision at the same time.
In most instances, you don't really care if a pencil is positioned accurately on the moon, unless you are on the moon aswell.
Empire Phoenix said:
Simple but importatn question, what is the maximum size of a world(well more a empty box, but whatever) that jme is able to handle?
Personally, my RAM is not infinite, my "world" is composed of 757128 vertices according to JMonkeyEngine 2.0 and I am already forced to increase the maximum memory available for the JVM :cry:
[java] vertex count=757128
[java] free memory = 8062024
[java] total memory = 71172096
[java] max memory = 532742144
The frame rate is ridiculous for the moment, 4 frames per second. It is my fault, I don't know this engine enough, I don't use nor backface culling neither locking.
You are not supposed to render your entire world every frame. Your game is an indoor FPS right? That means you can optimize world rendering by only drawing the room you're in. Backface culling is basic stuff. Other than that, consider using VBO. Another thing is that jME is not that good with resource management (actually it's non-existant). If you allocate textures, shaders, VBO, locks, etc they won't be deleted but leaked till the application closes.
Momoko_Fan said:
You are not supposed to render your entire world every frame.
Yes but I cannot use the algorithm used in my previous engine in JME 2.0 for the moment as it doesn't support forests of graphs (nodes with several parents for example). I have found no smart way of implementing this inside JME for the moment.
Momoko_Fan said:
Your game is an indoor FPS right? That means you can optimize world rendering by only drawing the room you're in.
That's what I did in my previous engine. I got between 26 and 40 FPS with my own scenegraph on (27 MB RAM) and 16 FPS with my scenegraph off (11 MB RAM) when I sent the whole geometry to the graphics card inside a single interleaved VBO.
Momoko_Fan said:
Backface culling is basic stuff.
I know, the impact is quite small.
Momoko_Fan said:
Other than that, consider using VBO.
I thought JME does it automatically when I load a model as my graphics card support ARB VBO (OpenGL 1.3, ATI Radeon 9250 Pro).
Momoko_Fan said:
Another thing is that jME is not that good with resource management (actually it's non-existant). If you allocate textures, shaders, VBO, locks, etc they won't be deleted but leaked till the application closes.
Now I understand why I get a OutOfMemoryError after rescaling my world, thank you. I rescaled the world with another preprocessing program and now it is better:
[java] vertex count=757128
[java] free memory = 35372480
[java] total memory = 66650112
[java] max memory = 66650112
It is fine, JME 2.0 uses 31 MB whereas my previous very limited engine uses 27 MB to display the same level :D It is acceptable as JME 2.0 provides me a lot more features :D
I thought JME does it automatically when I load a model as my graphics card support ARB VBO (OpenGL 1.3, ATI Radeon 9250 Pro).
No. You have to set an VBOInfo object manually for every static Geometry in your scene graph. If you want to avoid the leak you must call Renderer.deleteVBO() on it when you don't need the Geometry anymore. For textures there's a delete() method in TextureState, and some cleanup methods in TextureManager but they are global. For shaders.. nothing. Displaylists, I believe there's a deleteDisplayList method in Renderer, but I am not sure.
Momoko_Fan said:
I thought JME does it automatically when I load a model as my graphics card support ARB VBO (OpenGL 1.3, ATI Radeon 9250 Pro).
No. You have to set an VBOInfo object manually for every static Geometry in your scene graph. If you want to avoid the leak you must call Renderer.deleteVBO() on it when you don't need the Geometry anymore. For textures there's a delete() method in TextureState, and some cleanup methods in TextureManager but they are global. For shaders.. nothing. Displaylists, I believe there's a deleteDisplayList method in Renderer, but I am not sure.
Thank you very much for your explanation. I'm going to look at your suggestion. The wiki doesn't explain what a batch is, could it be useful for me?
Using this doesn't improve the frame rate:
((TriMesh)model).setVBOInfo(new VBOInfo(true));
Have I forgotten anything?
Yeah it works!!! I have added this:
model.lock();
Results:
[java] vertex count=757128
[java] free memory = 35276552
[java] total memory = 66650112
[java] max memory = 66650112
[java] frame rate = 0.06305568
[java] frame rate = 12.195122
[java] frame rate = 11.111111
[java] frame rate = 12.658228
[java] frame rate = 12.820513
[java] frame rate = 12.658228
[java] frame rate = 12.987013
So you're making a spacegame? If the player gets away too much from the origin you'll start to experience precision issues. To fix it you must relativize all entity positions every so often so that they are oriented around the player.
Yes the core maths it is based on floats.
You should probably take a look at this thread, which links an article discussing float usage:
http://www.jmonkeyengine.com/jmeforum/index.php?topic=10136.0
In essence, floats are considerably less precise at very large values.
With a space game (and most things, really) there is usually a pretty obvious frame of reference to allow acceptably precise local positioning, though.
Sorry but when I load a world whose coordinates are between [0;0;0] and [16777216;0;16777216], I get strange results (I set the frustum correctly, I compared with another engine) and I am forced to rescale.
Uh either a typing mistake, or you world is 2d?
I mean between "[0;0;0] and [16777216;0;16777216]" with typing mistake…
Empire Phoenix said:
Uh either a typing mistake, or you world is 2d?
My world is in 3D and in this case, I see only a part of the ceiling. As I found a workaround (rescale), it is no more a problem but maybe people that don't want to rescale should know what might happen with huge models.