Multiplayer & Floating Origin

Hi there!

Are there any multiplayer solutions ready to use which can handle floating origins?

Thanks in advance!

 

I'm not aware of a multiplayer solution with floating origin integrated.

Spoiler

When I've investigated floating origin for network multiplayer, I've not been able to get away from needing my own double precision world space for use on the server. You can't floating origin the server itself, because which player do you have the server follow? The players could be far from each other.

So you have the server deal with everything in a custom double precision world space, and any position updates to the clients are sent in that world space. The clients when receiving the updates will convert them to their own single precision world space using whatever floating origin offset distance they are from the server's double precision world space origin.

So that doesn't sound too complicated at first, you're basically writing your own network transform syncing script and a floating origin system, but the real issue is all the usual Unity stuff like colliders, rigidbodies, the physics engine, various transform and math functions, all can't be used server side. You'd need to recreate whatever functionality you need yourself for your double precision world space. That sounds like an enormous undertaking, so I personally dropped the idea for now.

 

Basically - what Joe Censored said above. Floating Origin in multiplayer would all be done client side. However you will need some type of server side solution to handle physics and collisions in large vast areas. One option is to replace the Unity physics with a 64 bit physics engine (maybe bullet physics?). The Unigine game engine also has a version that has a 64 bit position system created specifically for this issue but it is not free. Another solution is to do dynamic subdivision of space - then simulate a floating origin at the midpoint of each subdivision and only do collision detection on the objects in the subdivision. Space Engineers and Kerbal do this and there are blog posts from their developers with more info - I don't have the links but google will help you. Or you can assign each subdivision to a physics layer so they will not interfere with each other - but you will run out of layers quickly if you have a lot of objects. Or you can use physics scenes - but I found this to be very CPU intensive. Anyway good luck. I gave up on it.

 

@antsonthetree is right there are plenty of approaches. If you want to use double precision on the server for keeping a high precision map and tracking that will work fine.

However, one thing that is missing from all such ideas is that once you know some player's relative position to something, you don't need to use double for their coordinates. That something could be a planet, then a place on a planet: just symbolic references. When two players interact they are way closer than you need doubles for. My first multiuser system was in VRML and was all in float precision.

The other thing that is not well recognised is that you can dynamically change the effective resolution of a local area in a continuous space by solving for distant relative jitter - see video:

The "Sunday drive to Pluto-Charon video on the same site is all continuous single precision space from Earth to Pluto but with dynamically adjusted resolution for as places are approached.

Note also that the origin-shifting method of KSP is not floating origin - it never was.

 

Check out my component ($9.99): https://assetstore.unity.com/packages/slug/204179

You can ask a staff member in the Discord to get multiplayer-ready Mirror components out of the box.

Here is the getting started tutorial:

 

FYI, here is demo of my initial integration of Continuous Floating Origin with Mirror network.

 

Sync all positions with local space across network, place all networked objects under a parent, move the parent via the origin. @cosmochristo Your amazing!

 

Thanks, @OnlyTheCosmos. Great name are you working on a space game?. However, note that Mirror, like so many apps, is not designed for continuous floating origin so there is a bit extra to trick it, so to speak, to give it what it needs. I have to sort out some kinks before putting the asset online, but when I do, you will see what I mean.

 

Can't wait to see your work! Also, thank you, I love all things Universe! Also yes! My first game is space themed!

 

if you want to do full scale endless space have a look at the Dynamic Resolution Spaces asset. It is what I use to scale an open world beyond 70km. It uses the same Continuous Floating Origin that I am using with the multiplayer code.

 

Progress update: two avatar pushing each other over the network, plus common environment movement and interaction.

 

a 3 and 4 player example:

 

Hi! Great work. I'm dealing with the same issue, some years ago I created this proof-of-concept about floating origin, I never implemented it over the network: https://github.com/uta-org/ContinuousFloatingOrigin_PoC

Could you share it?

 

Hi @z3nth10n , thanks for the comment. I am just finishing adding a very basic shooter system and will probably upload it in the next week. I'm not a great fan of the fps genre but it makes for a good test of network methods. I will have a look at your project and give my feedback.

 

@z3nth10n I can't follow how the main program works or what your overall design and objectives are. It would help if there was a document to explain.

You have dlls, under the name Harmony, I can't help on things without source. Harmony is also the name of my project.
There are fragments of some of my old code, but no reference to where it came from.
There is some version of the old unity wiki incorrect "floating origin" in there.

I have no issue with people making something out of my work, that is what I want people to do with my Unity assets.
My advice, if you want help, is to clearly document sources, acknowledge prior work and don't be anonymous.

 

A quick update of basic shooter test.

 

Hi, I know that my project is very undocumented. I'm using Harmony lib (not your project) which allows me to modify the Unity's Engine dlls/assembly classes (Transform.position, ...) in order to have all positions/time (not yet) referenced over an origin to avoid jitter as you mention in your article.

I look at https://www.researchgate.net/publication/359076587_Temporal_Floating_Origin

And I saw that you apply only over the time which I'm not interested in (maybe yes, because if I calculate correctly, then 100000 seconds (which is where you start to lose precision), 27 hours, so if you play the game for that time everything will get worse)

I'm interested in positions and I don't know if you are focused on fixing that.

Anyways, could you upload the full project source to know about more your approach, please?

Thanks!

 

That set of techniques provides improved accuracy, and error invariance (over time), in addition to the positional accuracy improvements provided by Continuous Floating Origin and related assets.

The worst-case relative positional error that 100000s injects into the application is
= 2 x 100000* <machine epsilon>
= 2 x 100000* 0.000000119 for single precision
= 0.0238
and this will be magnified by any calculation that uses it.
That is an extraordinary amount of random error to inject, .... but it is a design choice.

I'm interested in positions and I don't know if you are focused on fixing that.

No. I only collaborate under certain conditions and do not just upload whole copies of assets that others actually pay for!

 

The multiplayer version of Continuous Floating Origin is now online.

FYI Proof of the positional consistency between avatars and shared environment is essential and I recently had a bug creep in that broke this rule. Here is an example of the (corrected) version for 4 players.