Hi there! I’m new to using JME and I have ran into a problem.
Basically I’m building a Minecraft styled world (so original) and I ran into problem when I implemented my own movement code.
What happens is when I move the world positions change( that’s what it looks like at lest) so every chunk and block that gets generated is in a different place, The distortion is proportionate to how much I’m moving( even tho the world generation and the player is completely unrelated )
ex I move to the left they get generated more to the left and so on.
This is the world when I don’t move during the generation process
and these are from when I move during the generating process
I kinda suspects that it has something to do with floats and the way those work.
So any suggestions would be greatly appreciated
@zarch said:
Didn't you already post this once....I'm sure I remember replying?
Hi, and yes you did But when I edited the first post to fix the images the entire thread disappeared. I just didn’t know how to fix it apart from doing a new thread
And to answer what you wrote, how do I do it in World space and not Screen space?
@zarch said:
Didn't you already post this once....I'm sure I remember replying?
Hi, and yes you did But when I edited the first post to fix the images the entire thread disappeared. I just didn’t know how to fix it apart from doing a new thread
And to answer what you wrote, how do I do it in World space and not Screen space?
We have no idea how you are not doing it in world space… so only your code has the answers.
@zarch said:
Didn't you already post this once....I'm sure I remember replying?
Hi, and yes you did But when I edited the first post to fix the images the entire thread disappeared. I just didn’t know how to fix it apart from doing a new thread
And to answer what you wrote, how do I do it in World space and not Screen space?
We have no idea how you are not doing it in world space… so only your code has the answers.
So basically this is what I do, I don’t see how this is not in World Space?
[java]
for (int localX = 0; localX < chunkSize; localX++)
{
for (int localZ = 0; localZ < chunkSize; localZ++)
{
@pspeed said:
a) you know that block worlds are not made of boxes, right? You're better off using quads right from the start.
b) where does this.x and this.z come from?
a) Yes I know, that’s why I made my own “Box” class that just generates the faces that has air around it, works very well
b) this.x and this.z are sent in via the constructor, its basically where in the world this chunk are located and are basically 0, 16, 32, 48 etc depending on where the generator wanted this chunk
Well, I suspect if you write those values out that they will be strange. There is nothing wrong in your code unless your custom box class is doing something odd with vertexes.
@pspeed said:
Well, I suspect if you write those values out that they will be strange. There is nothing wrong in your code unless your custom box class is doing something odd with vertexes.
I did what you suggested and the values was correct, nothing strange going on there. The values where in the correct range and in the correct order.
I also tried to use the regular Box and not my specialized one and the problem still occurred, so I doubt that its my custom Box class
The problem only started occurring when I implemented my own movement code, when I used the standard physics driven controller there was no problem.
I wrote in some comments in the movement code for the player, its basically two lines that makes the problem occur or not, and btw thanks for the help, really appreciate it.
[java]
public void simpleUpdate(float tpf) {
Vector3f camDir = cam.getDirection().clone().multLocal(1f);
Vector3f camLeft = cam.getLeft().clone().multLocal(1f); //myLight.setPosition(cam.getLocation());
walkDirection.set(0, 0, 0);
//doCollisionChecks();
//Straight from the beginner tutorial basically
if( tpf > 0.3) {
tpf = 0.3f;
}
if (left) {
Vector3f temp = camLeft;
temp.y = 0;
walkDirection.addLocal(temp);
}
if (right) {
Vector3f temp = camLeft.negate();
temp.y = 0;
walkDirection.addLocal( temp );
}
if (up) {
Vector3f temp = camDir;
//temp.y = 0;
walkDirection.addLocal(temp);
}
if (down) {
Vector3f temp = camDir.negate();
//temp.y = 0;
walkDirection.addLocal(temp);
}
velocity = walkDirection.mult(200 * tpf);
//If this row below is not commented out the problem occurs
//velocity.y += gravity * tpf;
if (jump) {
velocity.y -= gravity * tpf *20 ;
}/**/
playerState.velocity = playerState.velocity.addLocal(velocity);
playerState = rk4.integrate(playerState, 0, tpf);
//If these two row below are commented out the problem occurs, if I use the gravity above the problem still occurs even if I do this
float r = 4f * tpf;
playerState.velocity = playerState.velocity.mult( 1f - r);
cam.setLocation( playerState.position);
}
@pspeed said:
Oh, I see now:
node.getWorldTransform().setTranslation(this.x * 2, 0, this.z * 2);
^^^ That’s very very very bad. Do not set the parts of a node’s transform directly or you cause all sorts of leaking garbage.
Call node.setLocalTranslation()
Changed to node.setLocalTranslation(this.x * 2, 0, this.z * 2); and the problem persist.
I have experimented some and the geometry is pretty much offset by the velocity that I calculate in the player, and no neither the player or the camera is used in the world generating.
@pspeed said:
Oh, I see now:
node.getWorldTransform().setTranslation(this.x * 2, 0, this.z * 2);
^^^ That’s very very very bad. Do not set the parts of a node’s transform directly or you cause all sorts of leaking garbage.
Call node.setLocalTranslation()
Changed to node.setLocalTranslation(this.x * 2, 0, this.z * 2); and the problem persist.
I have experimented some and the geometry is pretty much offset by the velocity that I calculate in the player, and no neither the player or the camera is used in the world generating.
I have trouble believing this now. Either you are modifying a constant vector somewhere or the code you have changed didn’t really change.
The problem you reported before could have been caused by updating the translation outside of the spatial’s control (ie: going directly to the transform).
I think you will have to produce a simple test case that illustrates the problem. When that test case works fine (which likely will) then you can back track and figure out what you do differently that causes the issue.
@pspeed said:
Oh, I see now:
node.getWorldTransform().setTranslation(this.x * 2, 0, this.z * 2);
^^^ That’s very very very bad. Do not set the parts of a node’s transform directly or you cause all sorts of leaking garbage.
Call node.setLocalTranslation()
Changed to node.setLocalTranslation(this.x * 2, 0, this.z * 2); and the problem persist.
I have experimented some and the geometry is pretty much offset by the velocity that I calculate in the player, and no neither the player or the camera is used in the world generating.
I have trouble believing this now. Either you are modifying a constant vector somewhere or the code you have changed didn’t really change.
The problem you reported before could have been caused by updating the translation outside of the spatial’s control (ie: going directly to the transform).
I think you will have to produce a simple test case that illustrates the problem. When that test case works fine (which likely will) then you can back track and figure out what you do differently that causes the issue.
I know what you mean… I made a little test using only one chunk and rerendering it every frame and the chunk basically followed me around.
However I believe I have found the source of the problem:
[/java]
It appears that just calculating this and not even using it causes problem. Is it possible that it has something to do with floats and their accuracy?
And yes I am 100% certain that I do not use any of these variables anywhere else then here.
No. It has absolutely nothing at all whatsoever to do with float accuracy. Floats would be pretty poor if that were the case.
More likely you did something like setting velocity to Vector3f.UNIT_Z and now you are modifying it and anything else trying to use that constant.
That’s why I suggested a simple test case… self contained, single class, sort of thing. Since that will most likely work perfectly then you can trace back to see what is different in your own code.
@pspeed said:
No. It has absolutely nothing at all whatsoever to do with float accuracy. Floats would be pretty poor if that were the case.
More likely you did something like setting velocity to Vector3f.UNIT_Z and now you are modifying it and anything else trying to use that constant.
That’s why I suggested a simple test case… self contained, single class, sort of thing. Since that will most likely work perfectly then you can trace back to see what is different in your own code.
Aaah… Yea I was using Vector3f.ZERO. Heh. For some reason I believed that Vector3f.ZERO just returned a new zeroed vector3f…
Anyway thanks for the help, really appreciate it and sorry for the trouble
But when I edited the first post to fix the images the entire thread disappeared. I just didn’t know how to fix it apart from doing a new thread