@Dad72 I just checked in a fix for webGPU – you can test your playground in the snapshot from the PR Switch scenes example | Babylon.js Playground
[FloatingOrigin] Web GPU Fix by georginahalpern · Pull Request #17356 · BabylonJS/Babylon.js
3 Likes
Yes, it seems to work fine with this PR.
Thanks for the fix.
1 Like
@samuelgirardin Good job on your demo 
I did render Magellan (https://www.magellangps.com/) maps with the GPU. And a comparison of my fist pass with Google Maps ( Tessellation? ).
Hi @georgie
I found another problem with the water and sky.
I don’t know how to explain it, but there are offset.
The sun, for example, from the skyMaterial, is shifted to the right. And the water material has artifacts that I don’t know how to explain.
I have made a variable on line 1 to enable/disable useLargeWorldRendering pour voir la difference :
For example for water on my project it looks like this with useLargeWorldRendering enabled. (It’s pretty, but it’s not the effect it should be)
And if I don’t enable useLargeWorldRendering, the water looks like this (which seems okay to me):
I hope I report problems in the right place. Maybe I should create new topics if that’s not appropriate.
2 Likes
Indeed, I think it would be better to report these kinds of issues in the “Bugs” section of the forum so that we can group them together in the right place.
That said, here is the fix for sky and water materials:
4 Likes
Above PR was closed, here is the new one 
[FloatingOrigin] Support clip planes, skymaterial, and water material by georginahalpern · Pull Request #17398 · BabylonJS/Babylon.js
3 Likes
Hello!
Is there a way to track the “position” of the camera. Or its offset, whatever. So some code can determine where the camera is in the virtual space?
would that be a property on the camera? the scene/engine?
edit:
scene.floatingOriginOffset?
or just camera.position?
Many thanks
plop
The camera’s position after the offset is applied (i.e. the value we send directly to the shader) is at the world origin 0,0,0
If you want the camera’s position before offset is applied, you can just grab position from the camera directly as you normally would (camera.globalPosition)
thanks
trying to figure out how to make it work in the context of a worker/offscreen canvas.
Any suggestions?
I’m not sure there is a difference with an offscreen canvas. The engine / camera code remains the same
2 Likes
Hello
I would love to get a clarification on the camera’s position.
Let’s say I fly around a scene that has useFloatingOrigin set to true and its engine with useLargeWorldRendering = true.
[Not sure useFloatingOrigin is needed apparently?]
But my question is: if the scene has _huge_ coordinates, even when taking account the floating origin. Say, 1e12?
I ask because let’s imagine I fly to (1e11,0,0) and run console.log(camera.position);. I see the console output (1e11,0,0).
If the camera does indeed still have those coordinates… then how is it rebased to the origin? I quote: “the offset is not detectable from any public matrices / position getters“. But then for real huge coords such as those, how do we do?
I have seen such problems arise when flying around far far from the origin, and displaying details there. As it turns out, the precision is lost for those local details, even though they are close (around 10,000 client-side units).
edit: perhaps having an extra flag to rebase the camera every frame? an optional one?
Thanks!
editedit: bonus points for whoever guesses where the sound in the video (unintended!) comes from! xD
As I understand it, the camera is never rebased to the origin. Instead, shader uniforms are preprocessed to remove the camera offset to get small values inside of the shaders.
If you have custom shaders, you need to perform those offsets yourself as well to get the precision benefit! You can reuse the code at Babylon.js/packages/dev/core/src/Materials/floatingOriginMatrixOverrides.ts at 8a34c9810dd2ed1d8e7cc7c56ff88f4a097d8618 · BabylonJS/Babylon.js · GitHub to do that.
Hi Crash X
Thanks, and .. ok fair enough. However:
Isn’t this prone to creating problems when, say, calculating distances/lengths of vectors at high-value coordinates and using those in shaders? If precision is lost cpu-side, surely it can’t be regained or maintained gpu-side?
Either way, I’m ok with rebasing the camera and transformnodes/whatnot every frame, but I would have imagined this new native way of doing it would do it automatically
Thanks
Yeah if you have cpu-side imprecisions (Do you use a single frame of reference for galaxies for Ad Lumens?) this new feature is not solving that I believe. Instead you retain f32 gpu-side precision given that you already have precise f64 data cpu-side.
This is also an issue when using a physics engine like Havok which is 32bits as I understand it. I also need to rebase the origin to preserve physics precision at astronomical scales 
(Although I can rebase every 100km instead of every frame with largeWorldRendering)
2 Likes
yes I use a single frame of reference although server side I am working on a i32/f64 coordinates split to conserve precision even at those large distances. But that’s another subject.
Ok well looks like we have similar issues due to our insane coordinate values 
Question, though: assuming I rebase to origin and subtract from specific in-scene nodes, will I run into issues with the largeworld and floatingorigin flags? Am I to expect shaders to suddenly behave in an unexpected way and so on (including my noobish custom ones by the way….)?
The joy of making space games 
I didn’t have issue, when using something like this: CosmosJourneyer/packages/game/src/ts/frontend/helpers/floatingOriginSystem.ts at main · BarthPaleologue/CosmosJourneyer · GitHub (I needed some computeWorldMatrix(true) thingies to make sure the transforms are synced though)
1 Like
→ for me 
1 Like
@plopidou if you can share a playground repo that would be helpful! the feature is designed to support exactly that scenario (large coordinate system, camera is positioned super far away from origin but closeish to the associated mesh). all getters (of both matrices and positions) will still show the camera far away, but at the very last mile I override the viewmatrix to be 0-centered (effectively positioning the camera at origin) and offset the worldmatrix of the meshes (plus some necessary position uniforms)
for the CPU-side calculations using super large coordinates (like the distance you mention above), that floating point imprecision is handled by setting the useHighPRecisionMatrices flag on engine (which is set by default when using useLargeWorldRendering)
if you can share a repo I can investigate! thank you!
Hi @georgie, just a word to share my experience with the new useLargeWorldRendering feature. It’s great! My code is still a bit messy, but zooming from 20,000 km down to 2m looks very promising.
10 Likes
Hi @georgie, just a word to share my experience with the new useLargeWorldRendering feature. It’s great! My code is still a bit messy, but zooming from 20,000 km down to 2m looks very promising.
Awesome!!! Glad to see the feature being used
1 Like