www.jpct.net
jPCT - a 3d engine for Java => Bugs => Topic started by: atreyu64 on March 14, 2016, 12:23:18 am
-
Hi boys and boys,
I've noticed a strange behaviour when I modify the near plane value.
In my apps I have two types of camera controls (and I can switch from one to another at any time) : orbit camera and "walk camera" meaning that the camera is very close to the ground, which of course leads to some "frustum" effects.
Here is basically what I do to avoid this problem when I change the camera control type :
if(walkMode) {
Config.nearPlane = 0.25f;
Config.farPlane = 10000000000f; // yes I want to see everything...
}
else { // orbit camera settings :
Config.nearPlane = 1f;
Config.farPlane = 1000f;
}
cam.setFOVtoDefault();
cam.adjustFovToNearPlane();
I thought that adjustFovToNearPlane function would be enough but I also had to call setFOVtoDefault to avoid zoom-in/zoom-out effets, but this is not a problem, it solves my frustum problem very well.
The problem is that when the near plane value is different than the default value, the calcMinDistanceAndObject3D method returns wrong results.
Indeed, when I call the following method, I get wrong results :
// cursor projection on terrain :
protected SimpleVector getCursorProjection(int x, int y) {
SimpleVector cursorProjection = null;
SimpleVector dir = Interact2D.reproject2D3DWS(cam, fb, x, y).normalize();
Object[] res = world.calcMinDistanceAndObject3D(cam.getPosition(), dir, 1000000);
Object3D pickedObject = (Object3D) res[1];
if(pickedObject == terrain) {
float distance = (Float) res[0];
cursorProjection = dir;
cursorProjection.scalarMul(distance);
cursorProjection.add(cam.getPosition());
}
return cursorProjection;
}
The method still returns something, but it's like if the coordinate system of the frame buffer was different. Maybe the near plane value is not taken into account in the reproject2D3DWS method. Or maybe I'm doing something wrong ?...
Thanks in advance for your answers, cheers,
Sylvain
-
No, it doesn't take the near plane into account that way (because it doesn't have it). You might want to try the method that takes a z-value in addition (documented as "the z position in camera space") and fill that with the value for the near plane.
This whole clipping plane thing is rather poorly designed. The next version will move the setting from the World to the Camera, where it actually belongs. And then, these methods should work fine again.
Please let me know, if the method with "z" fixes the problem.
-
Thinking some more about it, I think what the method does is actually correct. It's more likely an issue with the frustum calculation itself at that stage. I'll look into it. You can try my former suggestion though, but I don't think that it's the right solution!
-
I think I found the problem. I'll upload a fixed version later.
-
Please give this version a try with your present code and see if that helps: http://jpct.de/download/beta/jpct.jar (http://jpct.de/download/beta/jpct.jar)
-
The reprojection function now works great, thanks a lot !
But I still have a problem : the method Interact2D.project3D2D returns wrong values.
-
Might be a related issue. I'll look into it tomorrow.
-
Yes, it's the same issue. I'll upload a fixed version later today.
-
I've updated the jar file that I linked to above. Please give it a try.
-
Everything works perfectly now. Thanks a lot !
Do you plan to report the corrections on jpct-AE ?
Cheers, thanks again for your precious time.
-
Do you plan to report the corrections on jpct-AE ?
Yes, sure. I just haven't uploaded a fixed jar for it. Do you need it?
-
Yes I would need it, but no worries, I'm not in a hurry.
-
Hi, have you upload the fixed jpct-ae jar yet ?
-
Ahem..no. I'll try to upload it later today. But that version is heavy WIP, so be prepared for some mayhem.
-
Ok, here it is: http://jpct.de/download/beta/jpct_ae.jar (http://jpct.de/download/beta/jpct_ae.jar)
As said, it's WIP. Mainly because it already contains the new shadow stuff that I'm doing for the next version. But I'm using this version in the latest Naroth release as well, so it should be stable.
-
Ok thanks a lot !
I don't use any shadows so it should be ok.
Cheers,
Sylvain
-
Sorry to bother you again, but it seems like setting Config.glIgnoreNearPlane to false does not work properly on Android.
Have you ever noticed anything wrong with it ?
-
I'm not aware of any problems. I'll look into it. What does 'not properly' mean in this context?
-
I had a look and did some tests with it...I can't find an issue. It looks fine to me. Can you describe your problem in a little more detail? Do you have a test case?
-
Well actually it's like if glIgnoreNearPlane was not taken into account, but sometimes the display is ok, only when I don't call the renderScene method, which happens here when "displayNeedsUpdate" is set to false :
if(displayNeedsUpdate) {
cameraChanged();
displayNeedsUpdate = false;
world.renderScene(fb);
world2.renderScene(fb);
}
world.draw(fb);
world2.draw(fb);
blitting();
fb.display();
I'm doing this to avoid rendering again the scene when nothing has changed in the scene.
If I try to call renderScene evry time, it is like glIgnoreNearPlane was ignored.
-
If anything, I would have expected it to be the other way round. If you omit the renderScene()-call, the draw()-call actually triggers some additional calculations that had to be done per frame but are usually done in renderScene(). These calculations were done too early to take a modified plane into account. However, I'm not sure why this should explain the behaviour that you are describing.
Anyway, I've updated the beta-jar of jPCT-AE. Please give it a try and see if that helps. If it doesn't (or makes things worse), can you please provide me with a test case?
-
Ok I'll give it a try tonight, thanks a lot Helge.
So what you're saying is that I should move the renderScene calls out of the "if" block ? Like this :
if(displayNeedsUpdate) {
cameraChanged();
displayNeedsUpdate = false;
}
world.renderScene(fb);
world2.renderScene(fb);
world.draw(fb);
world2.draw(fb);
blitting();
fb.display();
-
Not necessarily. But from your description, it worked when you omit them but not if you are actually calling them...which puzzles me. Anyway, please give the modified jar a try and see if that helps. If not, try to move them out of this block and see if that helps. If that doesn't help either, I need a test case.
-
The new beta jar did not change anything, that said I have found the solution.
Actually I use a skybox, and I was calling the skybox.render() method after world.renderScene().
After switching this call order, everything works fine.
Thanks again and sorry for bothering you, cheers !
-
No problem. The order in the draw()-method was wrong anyway. Even if it wasn't a problem in your case, it's better to have it fixed.