# Why doesn't babylonjs use (Rendering Relative to Eye) to solve the loss of precision? **URL:** \ **Category:** Questions\ **Created:** [April 20, 2022, 8:17am UTC](https://forum.babylonjs.com/t/why-doesnt-babylonjs-use-rendering-relative-to-eye-to-solve-the-loss-of-precision/29532 "2022-04-20T08:17:04Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![Luck\_Good](https://sea2.discourse-cdn.com/flex024/user_avatar/forum.babylonjs.com/luck_good/32/8286_2.png) [@Luck\_Good](https://forum.babylonjs.com/u/Luck_Good)\ **Post date:** [April 20, 2022, 8:17am UTC](https://forum.babylonjs.com/t/why-doesnt-babylonjs-use-rendering-relative-to-eye-to-solve-the-loss-of-precision/29532/1 "2022-04-20T08:17:05Z")
Why doesn’t babylonjs use (Rendering Relative to Eye) to solve the loss of precision? > **[Babylon.js Playground](https://playground.babylonjs.com/#V1FZLS%233)** > > Babylon.js playground is a live editor for Babylon.js WebGL 3D scenes Here are good examples > **[Babylon.js Playground](https://playground.babylonjs.com/#7QHQ2U)** > > Babylon.js playground is a live editor for Babylon.js WebGL 3D scenes ---
**Author:** ![Deltakosh](https://sea2.discourse-cdn.com/flex024/user_avatar/forum.babylonjs.com/deltakosh/32/26635_2.png) [@Deltakosh](https://forum.babylonjs.com/u/Deltakosh)\ **Post date:** [April 20, 2022, 3:27pm UTC](https://forum.babylonjs.com/t/why-doesnt-babylonjs-use-rendering-relative-to-eye-to-solve-the-loss-of-precision/29532/2 "2022-04-20T15:27:03Z")
Hey! can you elaborate a bit more? ---
**Author:** ![imerso](https://sea2.discourse-cdn.com/flex024/user_avatar/forum.babylonjs.com/imerso/32/46445_2.png) [@imerso](https://forum.babylonjs.com/u/imerso)\ **Post date:** [April 20, 2022, 11:01pm UTC](https://forum.babylonjs.com/t/why-doesnt-babylonjs-use-rendering-relative-to-eye-to-solve-the-loss-of-precision/29532/3 "2022-04-20T23:01:50Z")
I believe he is referring to a trick used to render very big scenes, called floating-origin. The idea of floating-origin is to keep the camera fixed at world’s origin (0, 0, 0) and instead of moving the camera, move all the objects around the camera. That trick makes floating-point imprecision to happen far from the camera, that is, far from the observer, mitigating the problem. That is not hard to implement, although it causes some extra efforts regarding physics simulation etc. I have implemented floating-origin in Javascript, on one of my old homebrew webgl engines. By coincidence I am porting the main parts of that to Babylon.js, hopefully will have something to show in two weeks or so. ---
**Author:** ![Luck\_Good](https://sea2.discourse-cdn.com/flex024/user_avatar/forum.babylonjs.com/luck_good/32/8286_2.png) [@Luck\_Good](https://forum.babylonjs.com/u/Luck_Good)\ **Post date:** [April 21, 2022, 2:24am UTC](https://forum.babylonjs.com/t/why-doesnt-babylonjs-use-rendering-relative-to-eye-to-solve-the-loss-of-precision/29532/4 "2022-04-21T02:24:26Z")
Great that your description here is my problem. Looking forward to babylonjs with related support. I think it may involve modification of “light”, “shadow” and other related programs ---
**Author:** ![Luck\_Good](https://sea2.discourse-cdn.com/flex024/user_avatar/forum.babylonjs.com/luck_good/32/8286_2.png) [@Luck\_Good](https://forum.babylonjs.com/u/Luck_Good)\ **Post date:** [April 23, 2022, 12:03pm UTC](https://forum.babylonjs.com/t/why-doesnt-babylonjs-use-rendering-relative-to-eye-to-solve-the-loss-of-precision/29532/5 "2022-04-23T12:03:43Z")
Here are good examples > **[Babylon.js Playground](https://playground.babylonjs.com/#7QHQ2U)** > > Babylon.js playground is a live editor for Babylon.js WebGL 3D scenes ---
**Author:** ![mawa](https://sea2.discourse-cdn.com/flex024/user_avatar/forum.babylonjs.com/mawa/32/12384_2.png) [@mawa](https://forum.babylonjs.com/u/mawa)\ **Post date:** [April 23, 2022, 12:15pm UTC](https://forum.babylonjs.com/t/why-doesnt-babylonjs-use-rendering-relative-to-eye-to-solve-the-loss-of-precision/29532/6 "2022-04-23T12:15:37Z")
I’m eager to see that. Pls, Let us know when ready 😋 ---
**Author:** ![imerso](https://sea2.discourse-cdn.com/flex024/user_avatar/forum.babylonjs.com/imerso/32/46445_2.png) [@imerso](https://forum.babylonjs.com/u/imerso)\ **Post date:** [April 27, 2022, 7:08pm UTC](https://forum.babylonjs.com/t/why-doesnt-babylonjs-use-rendering-relative-to-eye-to-solve-the-loss-of-precision/29532/7 "2022-04-27T19:08:00Z")
The required change to make floating-origin global into the engine is very simple. When updating any object’s matrix – at that final update just before rendering – it is just a matter of subtracting the current camera position from the object’s position, and then setting this offset to the view matrix. The camera position must not be directly in the view matrix anymore, it’s just used to calculate that offset, and the offset itself goes into the object’s view matrix. The effect is that the camera is always at (0, 0, 0) and only the objects float around the origin. That simple trick removes huge numbers from the GPU, when objects are close to the camera. As an example: Camera at (10000000, 0, 0) Object at (10000500, 0, 0) object.position - camera.position (that is, the view offset) = (500, 0, 0) That is, even at huge coordinates, there is no floating-point imprecision at all! Now, if the object is too far from the camera, then there will be imprecision, _but_ as it is very far, we won’t see! In C++ we would use doubles for all coordinates, but in Javascript that is not even needed, as Javascript already uses doubles by default. There are then two alternatives here: One is to simply create an Entity class which does that calculation every time it’s called. That requires a separate loop in the game to iterate through all objects updating that offset. This works, but is not the best because we add an extra loop to update the offsets. The other would be to implement that directly into the engine, in the loop which updates all object’s matrices. This is the best, as we remove the need of a second loop. As an additional note, this all also works best with logarithmic zbuffer, which as I see is already implemented. Maybe someone from the dev team could spend “a few hours” and implement a switch for that? Edit: saying is always easier than doing – disclaimer here is that atm I don’t know enough about the internal Babylon.js details to state that this would not have some weird collateral effects, so, I was just saying anyway. When I did that, I did from the start, and although it did work nicely, the engine was much smaller than BJS. ---
**Author:** ![Deltakosh](https://sea2.discourse-cdn.com/flex024/user_avatar/forum.babylonjs.com/deltakosh/32/26635_2.png) [@Deltakosh](https://forum.babylonjs.com/u/Deltakosh)\ **Post date:** [April 27, 2022, 8:51pm UTC](https://forum.babylonjs.com/t/why-doesnt-babylonjs-use-rendering-relative-to-eye-to-solve-the-loss-of-precision/29532/8 "2022-04-27T20:51:37Z")
The first one could be easy to do with a few lines like: ```auto scene.onBeforeActiveMeshesEvaluationObservable.add(() => { scene.meshes.forEach(m =>m.position....); }); ``` ---
**Author:** ![Luck\_Good](https://sea2.discourse-cdn.com/flex024/user_avatar/forum.babylonjs.com/luck_good/32/8286_2.png) [@Luck\_Good](https://forum.babylonjs.com/u/Luck_Good)\ **Post date:** [May 5, 2022, 5:20am UTC](https://forum.babylonjs.com/t/why-doesnt-babylonjs-use-rendering-relative-to-eye-to-solve-the-loss-of-precision/29532/9 "2022-05-05T05:20:36Z")
Are there any new developments that I can see from babylonjs? ---
**Author:** ![imerso](https://sea2.discourse-cdn.com/flex024/user_avatar/forum.babylonjs.com/imerso/32/46445_2.png) [@imerso](https://forum.babylonjs.com/u/imerso)\ **Post date:** [May 5, 2022, 2:42pm UTC](https://forum.babylonjs.com/t/why-doesnt-babylonjs-use-rendering-relative-to-eye-to-solve-the-loss-of-precision/29532/10 "2022-05-05T14:42:18Z")
There is a workaround: > [@Floating Origin Template for BJS 5.x](https://forum.babylonjs.com/t/floating-origin-template-for-bjs-5-x/29833): > > Ok, so this is a template for people who want a floating-origin solution on BJS 5.x – that is, support for huge scenery (ex: a solar system). [fp] I did not care about visuals at this moment, atm I just wanted to build a reasonable solution which did not require engine changes and was easy to use. I will be using this on my own planetary project and am giving it away for those interested in having huge scenery support without imprecision far from the origin. It is still a wip, but the concep…