The reason, on a low technical level, is described at Precisions, Precisions | DME Component Libraries for .NET 2024 r1 . This article explains where the problem is coming from. (And it describes a specific solution. This solution is not directly applicable to rendering a glTF asset, but the underlying idea for avoiding the jittering is very similar: It boils down to the question of what exactly is sent to the shader for rendering, and whether these values are “too large” to be sensibly be represented with standard 32 bit floating point values. CesiumJS is using an approach for rendering glTF that is not prone to this form of jittering)
For those who are curious and don’t know what this refers to, exactly: Here is a GLB file with a unit cube, where the root node has a translation of (300000, 300000, 300000)
unitCubeWithLargeTranslation.zip (701 Bytes)
And here is a comparison of rendering this (and rotating it a bit), once with https://gltf-viewer.donmccurdy.com/ and once with https://sandbox.babylonjs.com/ :
(In CesiumJS, you should also not observe any jittering, of course)
One could now roughly say that ~“certain aspects of the implementation in BabylonJS are not ideal for this kind of model”. But this wouldn’t be entirely correct: One should note that things like the BabylonJS sandbox offer a tremendous toolbox for analyzing the structure of glTF files (via the “Inspector”/“Scene Explorer” tabs), and by default, this does simply not apply the techniques that are required for avoiding the jittering for this kind of model.
There seem to be approaches for avoiding the jittering in BabylonJS, though: Quick searches bring up issues like origin shift with large coordinate · Issue #4516 · BabylonJS/Babylon.js · GitHub or the corresponding documentation at Babylon.js docs . I haven’t looked into the details there yet (after all, the question refers to BabylonJS, and not CesiumJS…), but things like the “floating origin” functionality will likely allow you to solve this issue.