2D Floating Origin Specifics- Does it "compress" positional coordinates?

Unity Engine
, ,
1

Long story short, I’m working on a 2D 4X style game. Yes, its space themed, hence Floating Origin. I’ve created it (as far as I’m aware) correctly, where every 1000m or so (I don’t specifically remember) everything shifts 1000m in the opposite direction, grouped by a sector system I created, where different areas of the map are stored via children, so the whole map is currently 9 sectors, each holding… stuff. Star systems and ships and whatnot. Once the camera moves too far, everything shifts back. The camera has a zoom system, which can zoom into individual ships, and zoom out to the whole galaxy, using various systems of speed manipulation, sprite alpha shifting, and not rendering 3/4 of objects past a certain zoom level.

That being said…

The floating origin system fixes the error caused by only 7 points of accuracy, keeping “important” things close to the origin/player/camera. My question is, with this type of system, do far away objects (like the sectors, or individual testing objects) not have their location properly stored after moving too far away?

For example, lets say I place an object on the far right of the map, and move the camera in the opposite direction for a while, so the object goes way beyond 1 million units away, or at least enough for it to “break”. if I move the camera back to the original position (and even to the object), would that object be in the same position, or would the 7 point precision errors “compress” its position to be off from where it started?

This is mostly hypothetical as I’m still messing with scaling, world size, etc., but I cant find anything specifically about this, and I cant think of a way to test it, since any benchmark would move the same way the testing object would.

Any help is appreciated, and even suggestions for how to better handle my game world if I’m actually a big dummy and don’t realize it. Thanks in advance!

Moving Cube Keeps Tipping Over
2

Yes if you or your world’s objects move far from the world origin then they may no longer be at the exact same position relative to each other when they return. So it’s important not to place objects too precisely and restrict their precision to four decimal places or the dollar bill you placed on the table may be inside the table after you return from your trip to the neighboring town.

3

Hm I never thought about having each object manually account for that by just… having their coordinates be “large” enough to work with that… Out of curiosity though, how would you get around that?

4

Many large open worlds get around it by streaming the assets in as you approach them. But without streaming you would only really need to be concerned about very small or thin objects. So in the case of the dollar bill on the table you could make the table’s height a millimeter short of a meter and then the dollar bill can be positioned at exactly 1 meter high. Or in some cases it may be better to model the table with items already on it.

5

Another solution is to make objects children of other nearby objects and then the children’s positions won’t be affected by a long journey. So don’t just place the dollar bill on the table but also make it a child of the table.

6

If you recall, thats what I did with my sector system. Each sector houses the various ships and systems within, and I have a simple algorithm made so that when a ship passes between them, it changes parents to that sector.

Now that I think about it, I could get away with shifting the triggers origins… so they are all at the center of the map (less likely to go REALLY far away), but their colliders are where they should be… i will look into that. Thanks for the help!

7

[quote=“Odyssean, post:1, topic:1547432, full:true”]
My question is, with this type of system, do far away objects (like the sectors, or individual testing objects) not have their location properly stored after moving too far away?[/quote]
When a player moves, it is the view of the data that is changing in accuracy based on distance from the player position. As long as the changed values in the view are not being constantly written to the original data stored on disk then there is no issue. When you move back to a position you moved away from, the positional data becomes more accurate again because of the shorter distance from the origin.
That is why, in a multiplayer game, the view position of one player A cannot affect the accuracy of information viewed by Player B, no matter what distance player B is from A.

8

This idea that the information would be changed when you move back is incorrect and so is the suggestion that you should not place objects too precisely.

9

Here’s a little demonstration:

using UnityEngine;
public class PrecisionTest : MonoBehaviour
{
void Start()
{
	transform.position=new Vector3(0.0123f,0,0); // set the object's initial position
	Debug.Log(transform.position.x);
	transform.position+=new Vector3(90000,0,0); // move/shift the object 90km
	transform.position-=new Vector3(90000,0,0); // move it back
	Debug.Log(transform.position.x); // object's x position is now 0.0156
}
}
1 Like
10

Thank you @zulo3d for explaining. I have verified your code and produced the same results: the absolute value of the object/player’s position does change under this shifting approach.

I should have explained why I was saying those ideas are incorrect. The reasons come from the math and science of relativity. Some take a bit of explaining so please be patient.

  1. Firstly, the subject is “Floating Origin”. Under the real Floating Origin algorithm, which I first published under that name in 2005, the player/camera is stationary at the origin. Motion is fully relative and therefore the player’s absolute position cannot change like this. The main issue here is that most developers have been led to believe that floating origin is the threshold-based shifting method, described by @Odyssean, through more than a decade of misinformation.
  2. The whole discussion is based on the incorrect idea that absolute-valued position matters. Some of the biggest scientific mines of the last 400+ years have proven that this is false.
  3. Motion, and position in space and time, can only (correctly) be considered as relative, not absolute. All my code implements this, and I have written a lot about it. A brief coverage of what Einstein and Hawking said on the subject can be found here: Relative information in motion. I summarise it here:
  • Einstein states: “Hence the Generalised Principle of Relativity asserts that “absolute” motion cannot be detected even with the help of gravitational laws.”

and:

“It was at all times clear that, from the point of view of the idea it conveys to us, every motion must only be considered as a relative motion.”

  • Hawking wrote: “in 1915 Einstein introduced his revolutionary general theory of relativity. In this, space and time were no longer absolute”.

From Galileo to Hawking there is one message that rings out loud and clear: We need to change our thinking from absolute to relative. I have done so and have many proofs of concept online, like this video.

An important aspect of this change in thinking is to recognise that basing your ideas, designs and algorithms on the motion of single point will lead to mistakes. Relativity requires at least two points and the recognition that only the relative information between them is important. Hawking puts it like this: “Einstein’s postulate that the laws of nature should appear the same to all freely moving observers was the foundation of the theory of relativity, so called because it implied that only the relative motion was important”. See: The digital observer

The fake floating origin publications (starting around 2009) lead one to think in terms of single, absolute-valued positions, which are irrelevant, instead of what matters: the information between positions.

I hope the above explains why I challenged the statements on motion and position.

1 Like
11

@Odyssean it is good to see you are asking the right questions before committing to design decisions. The 7 digits of decimal number rule, for single precision floating point, is not a very good basis for design guidance because it gives the impression that there is no significant error until 7 digits is reached.

Better guidance comes from understanding that linear floating point error doubles at the number 2.0, doubles again at 4.0, and so on.

ExponentBoundariesDrawingCrop50pc
ExponentBoundariesDrawingCrop50pc1029×168 13.4 KB

For single precision numbers, the minimum gap error is 2.3841857910156 x 10-7, so, at first glance, it will take a lot of doubling and propagation to produce noticeable jitter near the origin.

The next step is to include a geometric relative error estimation, and for 3 dimensions can be approximated by: 3.4 × ε m × distance from origin, where ε m is the gap error for a given precision (32 or 64bits).

It includes a factor of two because it estimates the worst-case error between two points, which may jitter in opposite directions.

It is arguable that better guidance will come from empirical measurements from similar games and the next best is measures from more specific experiments. My measurements in 3D demonstrate that noticeable jitter is likely at about 70km from the origin. I often use 50km as rule. For sensitive calculations, or when there is significant error propagation, jitter can start at 1km. I have even measured visible jitter starting at 1m! I expect you can multiply these numbers by 1.7/1.4 for 2D then by, say, 10 to account for less error propagation due to equations only using 2D terms instead of 3D vectors.

Lastly, note that floating origin does not solve distant relative jitter.