floating point precision in large open worlds — origin shifting keeps breaking my stuff

344 views 2 replies

Working on an open world project, roughly 8x8km playable area, and I've been fighting floating point precision issues for two weeks straight. You know the ones: objects start jittering when you're far from world origin, physics colliders go slightly wrong, particles drift sideways for no reason. Classic stuff.

The go-to solution is origin shifting, periodically recentering the world around the player so coordinates stay small and precise. Conceptually simple. In practice it's a bag of edge cases that keeps growing every time I add a new system.

Problems I keep hitting:

  • Joints and constraints between objects snap during the shift if you get the order of operations even slightly wrong
  • Particle systems using world-space positions get teleported unless you explicitly offset every emitter
  • Third-party cloth sim stores positions internally and has no idea the shift happened, it just silently diverges
  • UI elements reading world positions (map markers, floating damage numbers) need their own correction pass

Unreal handles a lot of this with Large World Coordinates in UE5, double precision under the hood, which is genuinely solid if you stay in-engine. I'm in Unity though, and the community origin-shifting scripts I've found handle maybe 70% of the cases. The other 30% is a different bug every time.

My current setup is a global WorldOriginShift event that every system subscribes to and applies its own position correction. It works but it's fragile as hell. Every new system I add has to remember to subscribe, and I always forget one, and then something starts drifting 6km from spawn and I spend an afternoon figuring out which system it was.

Is there a better pattern for this in Unity specifically? Some architecture that makes new systems opt-out instead of opt-in? Or does everyone just accept a certain amount of manual wiring and move on?

confused
Replying to ShadowMoth: origin shifting is rough to get right. one thing that helped me a lot: shift the...

the discrete steps thing is the right call. continuous shifting causes this subtle low-level jitter that's easy to miss until a player sends you a screenshot. one extra thing I'd add though: when you do the shift, make sure you notify your physics engine explicitly. forgot to do that once and spent a full day wondering why collision geometry was slowly drifting post-shift while visuals looked completely fine. the renderer updated, the physics world didn't.

origin shifting is rough to get right. one thing that helped me a lot: shift the origin in discrete steps rather than continuously. wait until the player is more than X units from world origin, then teleport everything. continuous shifting means you're accumulating tiny float errors every frame during the shift itself. also double-check that you're shifting everything including your physics world state and any cached world-space positions in scripts. that's usually where the weird ghost jitter comes from after a shift.

side eye
Moonjump
Forum Search Shader Sandbox
Sign In Register