Origin Shifting (dealing with floating point precision)

Hey everyone,

We’re visualizing an incredibly large digital surface model that finally requires origin shifting to avoid wobbly vertex points, and I’m wondering if Babylon has a built in feature that handles this. I haven’t found anything in the official documentation, so I’m going to assume no. If I were to do so, would it be through accessing the scene object or is there a root node that represents the “world origin”?

Thanks in advance for your help :slight_smile:

Hey! most generally I would recommend to have your scene under a transformNode to easily move the origin

But nothing more out of the box (besides logarithmic depth for what is worth)

2 Likes

Okay, sounds good. In theory I see this solving my problem but I wonder if this will break the Babylon Animation class, as it tweens between Vector 3 positions (that will now be changing per frame). If that’s the case, I’ll have to do origin shifting on a case by case basis, instead of dynamically.

I think you should be fine as animations know to deal with parenting

I’ve almost finished coding what I consider to be a solution, but I want to just clarify for my own sanity (in case my method is less efficient): Camera movements will be inversely moving a Transform Node that has all of the scene’s children, and the camera itself will be staying at 0,0,0 – or am I updating the world matrix of the Transform Node based on the camera’s world position? Thanks for your patience :slight_smile:

1 Like

This is how I would have done it as well :slight_smile:

I feel like I’m still missing something. Every time the camera moves, a Transform Node called “WorldOrigin” (with all the scene’s objects parented to it, minus the camera) gets sent to:

worldOrigin.position = new Vector3(
        worldOrigin.position.x - camera.position.x,
        worldOrigin.position.y - camera.position.y,
        worldOrigin.position.z - camera.position.z
      );

Then camera goes back to Vector3.ZeroReadOnly. I haven’t touched anything regarding an object’s “_worldMatrix”, just literal repositioning.

My map is 177,699m x 277,136m and looks fine from far away:

up until I get about 2m from the surface where the armature animation of my gltf and the alpha of my water layer completely breaks:

I’ve console logged the camera’s position, and it does reside in the world-space of (0, 0, 0), but I feel like everything parented to the WorldOrigin node is being moved around respectively, but the vertices and textures are being rendered as if they’re miles away from the camera.

The solution is probably under my nose, and hopefully it’s obvious to you too :slight_smile:

Thanks in advance!

would be great if you could share a tiny playground we could have a look into to help ? no need of the full experience, just the bare minimum so that we could dig in the issue ?

1 Like

Will do!

@Deltakosh @sebavan Here’s the playground: https://playground.babylonjs.com/#Y34F9G#8

The model itself looks like it is having an issue as moving the origin to 0 does not solve it could you verify this part ? https://playground.babylonjs.com/#PBL6X0#18

I wonder if your export tools suffers from precision as well

Also about the weird faces it comes from alpha blend mode and face order which you could solve by splitting the opaque faces in submeshes instead of relying full on blend everywhere.

I’m using Blender as an exporter, and placing the objects in their respective positions within Blender as well – in this case, x: 250,000, y: 0, z: 150,000. However, I generate an “Ocean Mesh” within Babylon itself, set the width/height to 250,000/150,000 and the alpha and UVs break when I’m zoomed in.

I’m not too concerned about the alphas atm as I know that’s just finger troubles on my end. Just the vertex positioning.

Could you try exporting in blender at 0 0 0 ? just to see if it could be export related ?

@sebavan
So exporting the object at 0,0,0 in Blender, then moving it far away in Babylon seemed to fix the vertex wobbling! https://playground.babylonjs.com/#Y34F9G#13

I removed the buoy’s material to avoid distractions, however, I added a texture and alpha to the water mesh and it remains broken. Is it the crazy mesh size that’s causing issues with the UVs?

yup the ground should not be that big… or it will mess with derivatives in the bump.

You could create tiles and move them like the rest ?

1 Like

That will work. Thanks for your help :smiley:

1 Like

@sebavan @Deltakosh Hey guys, I thought I’d post a bit of an update, as I ran into what I precieve as a bug with the SceneLoader object. Positioning the root mesh far away from 0,0,0 and parenting it to the World Origin transform node worked like a charm, but if I included multiple objects (armatures with meshes and bones) and tried to parent them separately to the World Origin node, I’d either get wierd render artifacts, or the mesh would disappear if viewed at a certain angle, or I’d be unable to move said armature, bone or mesh entirely.

I figured it was an object hierarchical problem, so I broke out every child object (node, mesh or skeleton) and tested parenting it to the World Origin node and would apply large positional transforms. Nothing worked as expected, except for exporting the three objects separately from Blender, and moving each root mesh to the desired position (which worked).

If you’re interested in following it up, I’d do it with incredibly large scenes, as testing in the Babylon Sandbox seemed to work, but moving it faaar away in my app just broke it.

1 Like

You can t change the hierachy below the root node or some of the required transforms in it would not be applied anymore.

1 Like