The jitter returned again, I set the setTarget to planet2, I need to zoom in a little so that planet2 can be seen
Okay that’s weird I must admit.
Somehow moving everything back to its original position after rendering breaks the floating origin?
Just commenting the afterRenderObservable callback makes it work again. I would expect it to have no impact on rendering as it is executed afterward 
I am not sure what is happening here, but @Evgeni_Popov might know something?
I’m not sure I understand the PG, because in a floating origin mode, the camera position should always be (0,0,0) so that the view / viewProjection matrices don’t store large values. If I look with Spector, the PG in the floating origin documentation:
But in your PG:
I think this is something that should be corrected first, otherwise you’ll always have artifacts due to the large coordinate values used.
Regarding the problem with onAfterRenderObservable, if you use onBeforeAnimationsObservable instead of onBeforeRenderObservable it does work. The former runs before the animations are applied, whereas the latter runs after.
My understanding was that the position should be (0,0,0) at render time when the float64 of view and projection are sent to the gpu as float32 Following that I thought that moving everything back after rendering (for animation purposes or even for physics continuous collision detection) would work as long as we ensured the camera is at the origin when rendering?
The idea was to do the following:
- Perform the animation (which sets the position of the planet far away from the origin)
- Translate the camera to the origin alongside everything else
- Render the scene
- Put everything back in place
This makes me confused as of why using onBeforeAnimationsObservable instead of onBeforeRenderObservable. In that case it seems like step 1 and step 2 are reversed and it leads to the camera being far away from the origin when rendering in step 3
@Stanikkje you can displace the scene from the camera target
1 Like
Indeed, but that’s not what happens in the PG: the camera is not at (0,0,0) when rendering (look at my screenshots, vEyePosition is the position of the camera).
Yes the view matrix is indeed not what I would expect from moving the camera to the origin, rendering and then putting it back in its original place.
What would be the right Babylon way of doing that then? Because making that work would eliminate a lot of the complexity of any floating origin implementation (especially if the physics engine is involved)
I think it should be something like what’s done in the OriginClass class in https://playground.babylonjs.com/#LHI514#66. I don’t see another way of doing it (though I don’t know if it can apply to an arc rotate camera…).
There is probably a way to adapt it for ArcRotateCamera by using globalPosition and using a translation instead of setting the position to 0
But in this example again, all objects in the scene are teleported each frame, which would require using disablePreStep=false on all physics bodies if we were using a physics engine, which is expensive 
Indeed… But I don’t see any other way.
1 Like
I still haven’t been able to solve this problem, with this problem it’s probably not even worth continuing to do my pet project, if you suddenly find a solution, please let me know, I’ll be grateful
Yeah I am really sorry I can’t help you more. You could still probably continue the project by ditching BabylonJS animations and compute directly the planets positions over time.
If I find a solution for the animations I will let you know here 
1 Like