jPCT - a 3d engine for Java > Bugs

Changing Near plane leads to weird "reproject" results

(1/5) > >>

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 :

--- Code: --- 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;
--- End code ---

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 :

--- Code: --- // 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;

return cursorProjection;
--- End code ---

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,


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:


[0] Message Index

[#] Next page

Go to full version