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 :

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.

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!