Improbable Icon

Huge scales and floats


After a chat with @dvanamst, I noticed that a lot of the questions that I have revolves around scale and floats. I want to open a discussion how others, for example @Bossa, solve this and if part of this cannot be solved from within the SpatialOS SDK.

Suppose you have enough workers covering an area of 1.000.000x1.000.000 units there are going to be entities that are outside the area where Unity can still service them. As a game developer I can try to implement my own Floating Origin solution but what a starting developer may not realise is that you need 2 Floating Origins. One on your Worker and one on your Client.

Or that person may not even be aware that the workers all use global coordinates inside Unity and that they are responsible for dealing with this problem in a larger simulation.

Is this something better facilitated by Spatial’s Unity SDK? So that the developer does not need to worry about scale or floating origins?

A somewhat related issue has to do with large gaps in spatial coordinates. A simulation that does not provide content in between every location, such as a network of star systems, will probably spawn a Worker per node (yes, this is a problem I face ;)). This sounds wasteful to me, and I was wondering if this type of situation is also something which might be interesting to address in SpatialOS by ‘compacting’ empty space somehow.


This topic may seem similar to Spatial World Resolution but I opened this as a foundation for a broader discussion instead of as a specific question


My understanding of this problem is that Unity and SpatialOS have different philosophy about “the world”.

Unity says, this is the world(scene) there may be or may not be things in it, but this is the world(limited by floating-point precision)

SpatialOS says, there may be or may not be other things in the world but this is what you can see.

The two can hardly be reconciled without some hacks. If the Improbable team can find a way it would make our life easier for sure though!


While I do not have any solution for Unity. But with UE4 I myself use the World Origin Shifting to overcome the floating issues. I use this both on the client side and server side. It does however add an ApplyWorldOffset value that I need to send along with my transforms but the result works amazingly well in the end.

I am sure something similar can be done for Unity if there is not already some marketplace asset to do just this.


@Tom316 what offset do you give it on your worker? AFAIK you cannot determine the origin point of a Worker


The origin point / center of the worker is a feature they are / where considering for a future update. For right now I best guess the center location by just grabbing the location of the entities in its local view and then using some wizard like math to figure out a center point based on that.

The beauty is that it does not have to be an exact center point but more a point that keeps the coords at a low enough number that physics and math do not go all crazy.

I also limit my works to specific sizes so that they will not exceed the size set (Doesn’t seem to fully work with the current UE4 SpatialOS SDK but I imagine it will be fixed soon(ish). Load balancing in general with UE4 workers seems hit or miss at times.


Would you mind elaborating a bit more about what doesn’t work so we can make sure we’re tracking the problem?


I will make a new post in the support section with my finding so far on it.


So just thought I would chime in on the Unreal Side of things.

First off - I would recommend people watch this. They cover world origin shifting although this is on the client side IIRC. I know it can be enabled in multiplayer but that is with the default UE4 Network Stack.

More details here ->


I would personally love to see this as a detail that the user should not need to care about; having to implement your own Floating Origin, and remembering that each worker needs a separate Floating Origin, is a hassle. Even with Unreal’s support for the client-side of things; that only solves half the problem. Not to mention that on workers the origin cannot be retrieved but needs to be inferred based on the active entities on a regular basis because workers can wander around :slight_smile:


I vote add a component to the Unity and Unreal Integration’s that are “fire and forget” so to speak that can be used track their location in the world.