Does ECS have plan to solve Open World float presicion problems?

Unity now create new foundation for faster and better Unity and this is gorgeous

Many games want to have big seamless worlds. Unity Megacity show how to solve runtime loading and unloading issue but what about float precision on big distances from origin?

Have ECS some features or plans for future to solve float precision issue on big distances from origin?

 

Regarding float, I know Unity aims to make it deterministic. But for large words, you either implement floating origin. Or use doubles. But with doubles, you loose many advantages of ECS performance. Burs is not supporting it, as far I am aware of.

 

Oh that is interesting to know. Thx for confirmation.

 

As far as I know origin shifting is somewhat bad design and it does not fit well with any 3rd party packages that not build specifically for origin shifting. Because after shift all global positions will be wrong and every component or system that store some global say target must know about origin shifting and recompute it.

As I understand we need some default approach from Unity for Origin Shifting and use only those packages from store that has support for it otherwise game will not run properly. Doubles is the same story

Creating big Open World game without plugins from store is pain

Big games has already 30k maps and what about bigger worlds?

 

so the doubles will be deterministic ? oh no my project use the float.....

 

This is then an design failure! System should never store global states!

Also wrong! This is the key feature of ECS... Adding new features without changing other code...
You only have to take all position relevant data and apply a offset to that position.
If this isn't possible to you, then you have also a design failure!


But what about static objects and lightmaps?

 

I mentioned about deterministic floats. I don't know about doubles, but assume so too?

 

I wouldn't call it a design failure, it's just how things get implemented if you don't specifically design your code to be origin shifting proof.

Just as an example, I've implemented "turret fires missile at target position" many times and it was never a failure in its design, but wouldn't work with origin shifting:

• Turret fires missile
• Missile stores its target position (inside the Missile Component, not as global/static variable)
  
• Origin shift happens
• Missile target position is not valid anymore

This would work flawlessly without OS, but needs to be handled differently with OS in place. Thus, if the game isn't using OS, I would not design the code for it.

I wonder if all this would not be an issue if everything is under a root gameobject that is shifted around, basically the entire world. But Unity recommends to avoid deep hierarchies etc (1).

 

I am very interested in this as well. I had to do a project that sort of hit a wall with float precision. as some meshes were too small and some were extremely big (simulating sun, earth and satellite to scale).
I could not make the mesh of the satellite to render correctly, it was clipping inside itself, my thought was that given the scale and the precision was not enough. If i scaled things differently such that the satellite would render then the sun would become way too big

 

Will the PhysX 3.4 Origin Shifting Function become available in Unity via ECS?

 

Unity can't fix every problem for every type of game. Floating point precision is not something you can just fix. It has a limited amount of bytes it can use in a float.

If you want to make a game with a large world, you will have to solve some of the issues yourself. That could be with origin shifting, or "zones" with a local coordinate system.

Creating a large open world game has technical challenges, which require you to design your game and your code for it. Plugins are solutions to general problems. If the plugins don't fit your special situation, it's not Unitys fault.

 

Only the PhysX engine used in Unity has an origin shifting function that is not made available within Unity...