Yes, but the only thing that would cause what you are seeing is an improper model bounds on the Geometry. We don’t really have enough information to determine why it’s bad but 95% guaranteed that it’s the issue.
I"d got the issue in perspective camera, I didn’t use the ortho or perspective methode from jme, and directly set the projection (see top message).
I’d the issue all the day, but since I change the model, and reload the previous, I can’t reproduce it. Previously I restart the jme side, several times to add trace, visual info (ftustum, bounding box) but I keep blender as is, and was able to reproduce each time. I’ll try with an other model (I got the issue last WE).
OK, I see a few weird things. First, never use Camera.setProjectionMatrix(), because it will not update the camera frustum planes. Second, never use Camera.setFrustumNear / setFrustumFar, you should be using either Camera.setFrustumPerpsective or Camera.setFrustum.
I didn’t use setFrustumPerspective(float fovY, float aspect, float near, float far) and setFrustum(float near, float far, float left, float right, float top, float bottom)
Because Blender (the data source) doesn’t provide fovY, aspect, left,… If I try to evaluate the value from available data (on blender side) and use them in jme, the final projection matrix is different, So displayed objects move/scale/… when I switch from jme POV to blender regulars view (solid,…).
Maybe the workaround will be on jme side (of the project) to do :
it’s the projection matrix for perspective only, the easiest. I’ll search for the missing. With your help I found the cause, the hardest part. I’ll reverse how jme compute projection matrice to give it the expected value
This would cause culling artifacts when the Blender camera FoV is greater than jME3’s. You cannot use setProjectionMatrix, no no no, cannot use it, no, its there, but its not for you, so don’t use it.
The equation I gave you describes exactly how to derive the values … You just need to solve for alpha. Here’s the solution: