My problem is an assertion error I get from Lemur:
[java]java.lang.AssertionError
at com.jme3.math.Ray.setDirection(Ray.java:479)
at com.jme3.math.Ray.<init>(Ray.java:84)
at com.simsilica.lemur.event.PickEventSession.getPickRay(PickEventSession.java:282)
at com.simsilica.lemur.event.PickEventSession.cursorMoved(PickEventSession.java:351)
at com.simsilica.lemur.event.MouseAppState.update(MouseAppState.java:154)
at com.jme3.app.state.AppStateManager.update(AppStateManager.java:287)
at com.jme3.app.SimpleApplication.update(SimpleApplication.java:239)
at com.jme3.system.lwjgl.LwjglAbstractDisplay.runLoop(LwjglAbstractDisplay.java:151)
at com.jme3.system.lwjgl.LwjglDisplay.runLoop(LwjglDisplay.java:185)
at com.jme3.system.lwjgl.LwjglAbstractDisplay.run(LwjglAbstractDisplay.java:228)
at java.lang.Thread.run(Thread.java:722)[/java]
Assertion fails because I have specified quite big far frustum:
[java]farCam.setFrustumPerspective(45f, aspect, 0.1f, 1e7f);[/java]
What happens is that PickEventSession.getPickRay(…) calculates clickFar=[-Inf, -Inf, -Inf] and Ray constructor is called with direction=[NaN, NaN, NaN].
Is this something that should be fixed in PickEventSession as Lemur seems to be the limiting factor for far frustum - or is my only option to tune down far frustum (1e7 -> 1e5)?
Are you sure you need such a frustum? You get all kinds of issues with such large values. How about scaling down the world instead? (not making it smaller for the player, just scaling it down, e.g. 1 unit = 1000m or so)
@orlof said:
That is certainly one option, but I just haven't noticed any other issues (yet). Far frustum is actually set by jmeplanet that I use.
The issue with such a far frustum is that it will suck up all of the depth buffer. So even objects close to each other that are near to you will have lots of z fighting when they shouldn’t. And basically, with this setup picking will never work, I guess. There isn’t enough precision in float to calculate the vector needed.
If you don’t ever need 3D picking then you can just turn it off:
stateManager.getState(MouseAppState.class).removeCollisionRoot(app.getViewPort());
…just remember you’ve done it in case you later feel like asking why picking in the 3D scene isn’t working.
Then you can get back to working on your game until the next issue with the far frustum crops up.
Thanks - After getting the same advice from all of you I will change the frustum Is there some rule of thumb for “good” frustum values? Originally I thought that 1e7 would not be a problem with floats.
However, I have used picking and it seems to work fine, but I have also seen some flickering in overlapping objects. Perhaps those are the symptoms of z-buffer problems and indeed my next issue.
@orlof said:
However, I have used picking and it seems to work fine, but I have also seen some flickering in overlapping objects. Perhaps those are the symptoms of z-buffer problems and indeed my next issue.
Exactly. basically the more objects are far away the less you have precision, and the less the renderer knows what is in front of what.
The thing is the precision drop VERY fast as you move away from the camera, so you may have issues even for moderately far objects.
