hi,
if i render meshes in a far distance (x >= 6400 y=64 z=0), the meshes starts to “shake”. is it a jme renderer problem or a float position thing?
the chunks consits of 16x16x128 boxes. after that i create a new mesh from the boxes of the chunks, calc the faces, buffers, etc. and attach it to the root node.
at the origin all works fine… no clipping bugs, no shaking meshes 
here is a video (position at xyz(640000 96 64):
http://youtu.be/ct8vPoW7wIQ
where can i find the viewMatrix and worldMatrix compute function in jme3?
i want to modify the matrices to get rid of the flickering/float precision problems
viewMatrix[3][0] = 0;
viewMatrix[3][1] = 0;
viewMatrix[3][2] = 0;
worldMatrix[3][0] -= cam.GetPosition().x;
worldMatrix[3][1] -= cam.GetPosition().y;
worldMatrix[3][2] -= cam.GetPosition().z;
@alrik said:
where can i find the viewMatrix and worldMatrix compute function in jme3?
i want to modify the matrices to get rid of the flickering/float precision problems
viewMatrix[3][0] = 0;
viewMatrix[3][1] = 0;
viewMatrix[3][2] = 0;
worldMatrix[3][0] -= cam.GetPosition().x;
worldMatrix[3][1] -= cam.GetPosition().y;
worldMatrix[3][2] -= cam.GetPosition().z;
Pretty sure this will not get rid of the issues if you continue to desire sub-meter precision at 600k+ coordinates. 32 bit floats can represent really big numbers and it can represent really small numbers... it just can't do it at the same time. So when you send really big numbers through a matrix where all of the values are less than 1 (some much much less than 1) you are going to lose precision.
Within 1000 meters or so (which is what your far culling distance is set to) you should not see flickering unless you have objects directly overlapping as in your early overlapped boxes case. But this is a z-fighting issue.
thats the point i set the camera to zero pos and subtract the cam pos from the world pos. => the float value gets smaller
if the objects or the camera being translated, the xyz float position are coming in. this is the point where i can reduce the big float numbers.
a friend is writing on his own engine and he had the same problem, but these simple changes works. he can now render in distances bigger than 600.000. this elimates the BIG NUMBERS
so where can i find the matrices? RenderManager.java?
@alrik said:
thats the point i set the camera to zero pos and subtract the cam pos from the world pos. => the float value gets smaller
if the objects or the camera being translated, the xyz float position are coming in. this is the point where i can reduce the big float numbers.
a friend is writing on his own engine and he had the same problem, but these simple changes works. he can now render in distances bigger than 600.000. this elimates the BIG NUMBERS
so where can i find the matrices? RenderManager.java?
So you would do this for every object's world matrix?
If you are just doing this at the root then it's really not any different than changing the local translation of the root node.
1 Like
And actually, I think that’s pretty much what we suggested. Leave the camera at 0,0,0 and move the root node.
ok that sounds really good. thank very much. I have you misunderstood where you mentioned that i should move the world instead of the camera
…
Looked like you were having problems even right under the camera… and the random missing meshes is a little disconcerting.
This points to something wrong in your code and not really a floating point issue. After all, your meshes should be located on even 1 meter boundaries most likely to precision at that point shouldn’t be a problem.
i can’t imagine how is that possible. the meshes have a fixed position but why did they start shaking if i rotate the camera?
@alrik said:
i can't imagine how is that possible. the meshes have a fixed position but why did they start shaking if i rotate the camera?
What is the position of the camera?
What is the position of the meshes?
How is your scene graph structured?
Even better, can you make a simple test case that shows the issue?
Wait a second…
@alrik said:
if i render meshes in a far distance (x >= 6400 y=64 z=0)
@alrik said:
here is a video (position at xyz(640000 96 64):
Is that really 640000 or 6400? The first will definitely cause precision issues.
Don't do that. If you want to support big worlds then move the world and leave the camera in one place. Floating point precision can't handle it otherwise.
1 Like
yes both values are correct. at ~6000 the faces of the meshes starts flickering… at ~600.000 the whole meshes starts shaking and flickering.
ok so i have to move the world instead of the camera … thanks 
6000 should be fine. 600k will definitely not be fine. The flickering faces may be something else.
Perhaps the flickering mesh is a sorting issue: with them meshes twitching around like that their bounding boxes may be overlapping triggering odd sorting.
Hey guys,
i’m working together with Alrik on this game and i made a small demo application that showcases the problem.
http://pastebin.com/uCQBwNft
Just start it as a simple Java App and follow the box-line. The problem is already visible at around x=300, even more at x=1000.
Any suggestions are appreciated
Edit:
Well sorry for that stacking-into-each-other. I just noticed that at x=500000 
Changed the pastebin link to the newer version.
It helps when you don’t stack the boxes into eachother. http://hub.jmonkeyengine.org/javadoc/com/jme3/scene/shape/Box.html#Box(float, float, float)
Still smaller gaps are there. After printing out the values of the objects in viewspace, there of course is decreasing precision with bigger numbers, but they aren’t really jumping around all that much.
the pastbin code is now up to date but the problem still remains
1 Like
I presume this is a type:
cam.setLocation(new Vector3f(500000, 0.5f, 1));
Since you won’t even be able to see the objects from that distance.
500k distance from the origin? You can’t do that. Move the world instead of the character, and remove objects that are too far away, or change everything to work with doubles.
So I’ll ask a naive question.
I’ve made a game with a big terrain and I’m changing the camera position and running into the same flickering problems. If I want the world to move instead of the camera I assume I set the terrains local rotation and translation ? Is there a simple way to calculate these based on the camera position ?