Floating Origin

Unity Engine
, , ,
1

Will floating origin be a built in feature for Phyiscs & NetCode in the future?

6 Likes
2

Hey! Short answer: Can’t say, assume no. Our Entities Transport team are still thinking about how best to deal with massive worlds. There are lots of stakeholders on this feature.

With that said, floating origin is not viable in most multiplayer games, as any freedom of movement allows two clients to move hundreds of km away from each other.
But, a floating origin following a VIP player could likely work (where other players are locked within a radius), but you’d need your own bespoke solution for that.

Opting into double precision Positions may be a simpler answer, and is being considered. Again though, nothing concrete at this moment (apologies).

3 Likes
3

Further context in a similar thread: Large world coordinates - double precision data - Unity Engine - Unity Discussions
And again, nothing concrete to share a la implementation details.

1 Like
4

Updated (I am clarifying this post because I realised there is an assumption in My post as to the meaning of “floating origin”):
I think you are making incorrect assumptions. There is no reason why real floating origin, where the players are stationary at their own origin, would not be viable in multiplayer. I do it all the time and it works for any distance and for any number of players.

Additional clarification: most people use the term “floating origin” to mean something opposite to what I originally intended in my 2005 publication. I.E. in the sense of the fake algorithm in the old unity wiki that was taken down, where the player moves in absolute coordinate motion until a threshold distance from the origin is reached, then everything, including the player is shifted back so the player is back at the origin.

Real floating origin does not move the player from the origin: motion is fully relative: the World is moved in relative differentials, around the stationary player. The assumption of absolute motion (being necessary) was proven false by Einstein, and this was clarified by Hawking who wrote “only relative motion is important”.

1 Like
5

Ah, very true, thank you: I agree, my above post is extremely misleading. I’ll amend to: “Floating Origin” is not sufficient to solve this problem, unless you support its implicit dependency; “Higher Precision Transforms”.

I.e. I used/interpreted the term “Floating Origin” in Jawsarn’s question to mean only the specific technique whereby all transform position vectors are offset by a global i.e. per-client delta, distinguishing it in discussions from the broader feature of “Higher Precision Transforms”, which - as mentioned - needs buy in from all of the stakeholders who rely on Transforms.

And so I mentioned “Double Precision Transforms”, as it is probably the most well understood example of a “Higher Precision Transforms” solution, but there are many others, of course.

“Floating Origin” can also describe the optional bandwidth optimization whereby the WorldPosition’s of ghosts are delta-compressed relative to a single per-player/per-connection “floating origin”. We do not do this in Netcode for Entities (yet), but we do use other delta-compression approaches.

1 Like
6

And I have just clarified what I meant by the term as well, as there is constant confusion and mixed messaging around the term all the time!

1 Like
7

There was no confusion in the terms. The OP and NikiWalker correctly attribute the naming.

Fractional numbers in computers are stored in two parts:

  • The mantissa which is the digits of the value
  • The exponent which expresses the magnitude of the mantissa value

So the word “float” in “floating point number” means that the radix point of the number “floats” in its representation depending on the magnitude of the number defined by the exponent.

The problem of precision in larger game worlds comes from the fact that with the increase of the magnitude of the numbers representing the coordinates the radix point floats so much further out that it reduces the mantissa size enough to show a significant precision loss.

So the term “Floating origin” refers to the technique of resetting the “floating origin” by returning the “floating point” radix back to the origin, with the lowest exponent, restoring the capacity of mantissa once again. The “origin” refers to the position of where from the radix point starts floating out again with the further magnitude growth, which is origin of the number, which is the number 0. The technique is called simply “floating origin” because it indicates the correct understanding and usage of the numbers of the IEEE 754 standard.

In the case with representing space this just happens to coincide with the local frame coordinates origin reset too, but that is just a side effect. It is important to understand that the original problem was not coming from the representation of the coordinates, and the coordinate system did not need any reset. The problem was coming from the representation of the numbers, which needed the reset. The coordinates remain as they were, only the precision of the local reference frame is reset.

Thinking that this is somehow related to the game coordinates in the first place is a mistake, albeit a very common one in the game dev community. Unfortunately many people misattribute what is the “origin”. The “Floating origin” technique is used in many other places just as well, for example in some scientific computations where there are only values that need to have a higher precision, but using full-fledged fixed precision is not worthwhile.

The “floating origin” problem also exists for all the other values in a game that might grow beyond certain scale, but which need to remain precise and well-determined. For example various economy-related numbers in some strategy or a tycoon game. In most cases it’s possible to switch the whole calculations to integer numbers and thus avoid the floating point problem altogether, but specifically for talking to the GPU this is impossible. Thus space remains almost the only domain in games that is concerned with the problem of the floating origin.

The notion that moving the whole world around the player is somehow a new and effective technique is openly misleading.

Moving the whole world around the player, while keeping the player at the center is nothing new, and is a very well-known approach which was sometimes used in old games.

For example, the original Elite used this system:

As far as I remember, a lot of other games used the player-as-the-center approach, shifting the whole world around it, games like:

I only found the reference for Elite itself now, but back then it was kind of a common knowledge, maybe you can find more references online if you’re interested in this subject.

Historically, this was where the term “floating origin” came from. It was just later understood that it’s more feasible to do it much more rarely, and in increments, thus the more complex periodic shifting mechanism was devised. Otherwise, there’s no difference between continuous and periodic origin reset.

Speaking of keeping the observer always at the coordinates of zero and moving all the world around: this is never done in modern games anymore because of obviously much higher computation costs. As well as an unjustifiable increase in complexity of integrating the world around more than one centre in case of multiplayer, with the cost and complexity growing in an exponential rate with the amount of players/centres. Newtonian physics and collision simulation also becomes highly unfeasible quite quickly.

Also, just to mention this: some graphical frameworks, like the famous OpenGL example, are known to kind of “move the world around the camera”, but this is just a mathematical formalism meaning that they use the transformation matrix for projecting the world on the surface of the camera plane, as opposed to transforming the unprojected values like DirectX used to do.

8

Sinaari, you seem a little angry, I am sorry if you were upset by my post.

Firstly, there is one point where we are both in agreement: “Thinking that this is somehow related to the game coordinates in the first place is a mistake”. Yes, and that is one of the reasons why I write about moving from ideas of absolute-valued computing to relative computation.

Your historical information is very interesting, particularly the one about 6502 assembler code.

I seek only to have a standard definition of “floating origin” that refers to a single, general, best practice algorithm for all positional computation.

From 2009 there has been confusion from two camps:

  1. One involving absolute space and motion concepts with “jumps”/”shifts”/”resets” which became popular and widespread from 2010 after the publication of the “floating origin” Unity wiki. and

  2. The other involving continuous, fully-relative motion. I first published a version of this approach as “Floating Origin” in 2005.

Before explaining further, I want to address a misconception and contradiction.

This conclusion:

“So the term “Floating origin” refers to the technique of resetting the “floating origin” by returning the  “floating point” radix back to the origin”

is not directly implied or required from the IEEE floating point number representation.

I.E. a specific motion algorithm is not implied by a specific of number representation and to argue so is not logical.

Additional proof 1: My Floating Origin algorithms, are continuous: they continuously move the World around the stationary origin-centric player/view. There is no reset involved and therefore a reset it is not implied by the definition of floating point numbers.

Additional proof 2: As already stated by @NikkiWalker, many approaches to problems of scale involve switching to double precision. This allows absolute, continuous motion over larger scales without noticeable error. No reset required.

There is a contradictory juxtaposition between:

“Floating origin” refers to the technique of resetting the “floating origin” and

“Moving the whole world around the player, while keeping the player at the center “

because “keeping the player at the center” is a continuous method.

Such contradiction leads to exactly the type confusion that I endeavour to remove by making clear distinctions between continuous relative motion and absolute-valued shifty motion.

Putting all that aside, the aspect to this that matters much more than debates surrounding representation and dates was developed over 400 years and first proven, in great detail, by Einstein is exposition of special and general relativity [1].

In that exposition, he described a “continuum”: continuous motion through a series of points, without “jumping” over any points [1]. Based on the logic of his continuum he made the point that motion cannot be considered absolute.

We algorithm as we think. Shifty/reset algorithms involve the notion of absolute motion: of the player, moving through absolute-valued coordinates, with occasional sudden resets.

Einstein argued this type of thinking is incorrect.

“every motion must only be considered as a relative motion.” [1].

Hawking clarified this aspect in multiple, concise statements. Here are two of them:

“in 1915 Einstein introduced his revolutionary general theory of relativity. In this, space and time were

no longer absolute” [2]

and

“relativity … implied that only relative motion is important” [3].

I briefly summarise the relationships between Hawking and Einstein’s writings and my work in Relative Information and Motion [4].

Einstein and Hawking wrote about relativity in relation to moving observers, the laws of physics, space and time. In my Thesis [5], I extended this to all computation on positional information and described the concept of position independent observations: where each computation is an observation. I even use this idea to optimise the accuracy and performance of distance determination [6], whether there is any motion or not.

Relativity could not yield much benefit to general information processing. Two more steps were required before the full (optimal) benefits could be attained:

  1. To be specialised as stationary, fully-relative form, and
  2. For that stationary position to be always Zero.

References

  1. Einstein, A. 1916. Relativity, The special and the general theory, A popular exposition.Authorised translation by Robert W Lawson, D.Sc., University of Sheffield,Third Edition 1920
  2. Hawking, S. 2022. How did it all begin? www.johnmurraypress.co.uk.
  3. Hawking, S. 2001. Hawking 2001. The Universe in a Nutshell. Bantam press, 57910864.14.
  4. Relative information in motion, https://www.researchgate.net/publication/382361412_Relative_information_in_motion.
  5. Christopher G. Thorne. 2007. Origin-centric techniques for optimising scalability and the fidelity of motion, interaction and rendering. Ph.D. Dissertation. The University of Western Australia, Crawley, Western Australia. https://www.researchgate.net/publication/331274253_ORIGIN-CENTRIC_TECHNIQUES_FOR_OPTIMISING_SCALABILITY_AND_THE_FIDELITY_OF_MOTION_INTERACTION_AND_RENDERING
  6. https://www.researchgate.net/publication/354077461_FAST_FLOATING_ORIGIN_DISTANCE_CALCULATIONS.
1 Like
9

Here are just some significant differences:
1. Shifty algorithms suffer significant errors from not “closing the last mile to zero” [1]. As I describe in Healing cracks in cyberspace, the greatest rate of accuracy loss is in the first mile movement from the origin. The rule-of-thumb estimation of the base relative error is 3.4 x distance x machine epsilon [2]. So, for 1024 meters from the origin there is 3481.6 times more error compared to being at Zero. That is before additional error propagation due to calculation. That is a very significant difference. From the forums, I recall that developers often use 3000 and the shift threshold, so you can multiply this difference by 3.
2. As I described in my previous post, the shifty algorithms are based on absolute-valued motion, with an absolute-value jump back (reset), then more absolute motion, and so on. Real floating origin is based on fully-relative motion. Absolute motion is the total opposite.
3. The shifty methods move the player, which may be under the World transform. In real Floating Origin, the player sits at the top level outside of the World transform and Floating Origin moves the World, not the player. Complete opposites.
4. Shifty algorithms suffer from significant and varying changes in the accuracy of z-buffer depth resolution. For a good visual example see [3]. In contrast, real Floating Origin has the property of invariance to distance from origin: the resolution at any given distance is always the same. Variance versus invariance: total opposites.

The above lists 4 significant differences and it was therefore false to suggest there is no real difference. I can site more differences, but it is not necessary.

References:

  1. [Healing cracks in cyberspace](https://www.researchgate.net/publication/337759338_Healing_Cracks_in_Cyberspace_towards_best_practice)

  2. [https://www.researchgate.net/publication/343927683_Geometric_relative_error](https://Geometric relative error)

  3. [Real versus fake floating origin: 1]https://youtu.be/4W5yC9yOTPI
10

Because of how the physics engine stores world data to speed up collision detection moving the world around the player is expensive. So moving the world around the player every frame is going to be very demanding. PhysX has a feature that can improve performance of moving the world but Unity doesn’t support it and it’s still quite costly.

For now the best method is to only shift the world when the camera/player goes 10km from the origin.

11

The risk of Origin-shift

I am posting this at the top level because of the large post supporting origin-shift in oposition to Floating Origin.

Analytical Risk

In 3D information space, geometric floating point error increases with distance from the origin according to the approximation: 3.4 x distance x machine epsilon [1].

This means that, for 1024 meters from the origin, there is 3481.6 times more error compared to being at Zero. That is before additional error propagation due to calculation.

Further explanations of 3D geometric error are provided in the video [4] and Figure 1 illustrates some problems that can become visible with Origin-shift.

Qualitative manifestations

Experiments have been performed to attain visual measures of different cases of origin-shift error and its failures to produce fit-for-purpose results [6, 7, 8, 9, 10].

The F loating origin fighting cubes part two video [10] records an experiment with physics collisions and graphical rendering.

Two cubes that fight against each other in front of a background cube. The experiment uses of origin-shift with threshold of 3000m. In the first part, two cubes collide and push against each other as the entire system is moved under origin-shift at an accelerating speed.

originShiftFailures50pc
originShiftFailures50pc1041Ă—726 130 KB

Figure 1 illustrates a very small sample of the failures that will happen, mostly invisibly, in applications that rely on the Origin-shift class of algorithms.

Conclusions

Any effort that reduces software error in a consistent, general, and verifiable way is worth supporting. The scientifically based Floating Origin algorithms offer such an innovation.

Although algorithms such as Origin-shift can reduce the scale of error, they still incorporate the seed of random, uncontrolled, and unpredictable error. They thus represent an unnecessary risk to applications, particularly to mission critical systems and could limit usable screen time and lead to health risks.

Antiscientific disinformation efforts to convince people that origin-shift solutions are as good as scientifically-based Floating Origin algorithms pose the danger of faulty approaches being used in industry.

The Framework developed around Floating Origin offers consistent improved accuracy, scalability, reliability and performance. Floating Origin encapsulates the most significant scientific principal of recent centuries, relativity, and the Framework is designed deliver it into the foundations of modern computing for the benefit of all.

Origin-shift is a risk not necessary.

References
1. https://www.researchgate.net/publication/343927683_Geometric_relative_error.
2. When, how and where jitter occurs in games, https://youtu.be/B5zwCkadpdo.
3. Real Floating Origin for games versus fake “shifty” algorithm: planet zoom to small scene,
https://youtu.be/dPavVPq92Gk.
4. Accelerating origin-shift failures with intersecting checkerboards, https://youtu.be/ZHwgRH0tjpM.
5. Short distance floating origin comparison between origin-shift and continuous floating originhttps://www.researchgate.net/publication/337759338_Healing_Cracks_in_Cyberspace_towards_best_practice
https://youtu.be/RtqsgA80tFA.
6. Physics and rendering failures of origin-shift with speed and distance with speed and distance. https://youtu.be/vbIb9dh1f7o
7. Floating origin fighting cubes part two: failures of origin-shift in games,
https://youtu.be/80W113eL6wQ.