Hey all! We’re introducing LargeWorldRendering for 9.0 to prevent jittering caused by floating point imprecision when dealing with large coordinate systems calculations.
Note that the feature is still experimental / in development (there are some known limitations today, such as shadow rendering and billboard/infinite distance modes) however we can use this thread to consolidate asks/observations related to floating origin / large worlds
You can see usage in this playground which enables swapping between scenes and testing combinations of the below engine/scene creation options. Left is without largeWorldRendering, right is with. And if you move camera you will see the jittering is gone
For complete large-world rendering support across all scenes:
create engine with{ useLargeWorldRendering: true }. This will internally
Set engine to useHighPrecisionMatrix – which uses 64bit matrix computations instead of 32bit default, ensureing we don’t lose accuracy in the CPU-side math when calculating matrices on large world coordinates
Set all scenes to useFloatingOrigin – which offsets matrix uniforms (plus some position-related uniforms/attributes) before passing to shaders – centering the camera at world origin and displacing all other scene nodes by camera’s world position. This ensures accuracy in the GPU math, as the scale of values sent to shader are smaller and can be handled with 32 bit floats.
For scene-specific large-world rendering:
create the scene with{ useFloatingOrigin: true } and create engine with{ useHighPrecisionMatrix: true }
Doing this reduces perf impact on smaller coordinate-based scenes (because we can avoid offset matrix calculations)
(highPrecisionMatrix is an engine-level setting that cannot differ per-scene)
Some notes
P.s: Note that because the floatingOriginOffset is applied right before sending values to shaders, the offset is not detectable from any public matrices / position getters (which was a guiding philosophy as I implemented) This ensures all logic within Babylon or written by users can remain unchanged regardless of mode.
P.s.s: Also note that the usage of this feature has changed in Pull Request #17334 · BabylonJS/Babylon.js, previously it was only a scene-level creation option called ‘floatingOriginMode’).
I will add robust documentation once the feature is no longer experimental / the API is confirmed!
Even if we have the ‘floating point problem’ solution and want to use for GIS, there is still consideration on normalising the geometry (usually for streaming) before it hits the engine. Cesium has its own powerful API to transform this data before it hits a rendering engine. So the answer is yes and no
I would still run a Cesium server and/or use their APIs if developing a BJS GIS solution.
BJS won’t become a replacement for GIS solutions. There is a very relevant tech cross-over so plugins and simple GIS solutions are definitely plausible. Cesium have documented BJS examples.
that is fair feedback! As the feature is still experimental I can change the name of the flag if it is confusing to many people. Perhaps ‘useEyeRelativeRendering’ instead of ‘useFloatingOrigin’ and ‘useLargeCoordinateRendering’?
For ordinary people, supporting xyz blocks, geojson， Coordinate conversion is sufficient to meet most needs, and 3dtiles can already be loaded into babylonjs through third-party tools. It would be even better if it were officially launched by babylonjs
I tried to test on my project by adding useLargeWorldRendering: true in the engine initialization.
I don’t know if it’s normal or what, but something is wrong with the ground.
My terrain has decreased in size as if it had been rescaled.
All my objects on the field have not moved their place, but since the field is smaller and lower in Y, no object placed it properly anymore.
Hi @Dad72 if you are passing {useLargeWorldRendering: true} as the options param when creating engine then that is correct and the behavior you are seeing is due to the feature not being fully complete
Can you share more details on how you create your ground? A playground repo would be best so I can investigate /fix.
@plopidou@Tarks once feature complete yes, this mode will work with both billboards and physics. Please feel free to test out today and share what you notice
@georgie
I tried to do a PG, but without success.
And I was like, “a but I’m using WebGPU on my project.”
So I tried my project again with webGL and it works.
But with WebGPU this creates the problem where the ground generate by heightmap seems to be rescaled.
I put the PG I tried, but I don’t know how to use WebGPU using useLargeWorldRendering: true
So maybe the feature is not yet integrated into webGPU
@georgie@Evgeni_Popov
I found the problem and managed to reproduce it in the PG.
It is not the terrain that creates the problem but the MixMaterial
In this PG with WebGPU and mixMaterial it do not works
In this PG with WebGL and mixMaterial it works
On the pg, I made a normal terrain with heightmap and I serialize it. to see the land in the first time as it should be.
Then I reload another terrain from the serialization and apply a mixMaterial and we can see that this terrain created with the mixMaterial, that should be the same size as before is no longer the same size.
If you try without applying the mixMaterial, it works.
This is so much cleaner than rebasing the origin every 10km, I am going to use it everywhere in Cosmos Journeyer!
