✅ Watch my FREE C# Course! ua-cam.com/video/qZpMX8Re_2Q/v-deo.html 🌍 FREE Game Dev Report Newsletter cmonkey.co/gamedevreportnewsletter 💬 Do you know what is going on in this video? Such a strange bug where a normal looking Sphere suddenly becomes all jittery and messed up. The answer: Floating point precision. Floats have a limited number of digits, so if you position an object in a huge position, it won't have enough space for many digits after the decimal point, they will be forced to round up or down. Meaning all the vertices on the sphere won't be able to go to their exact position, so they start jumping up and down as the value is being rounded. One fix to this problem is a Floating Origin Point. This is where you can keep track of the player position, and if the player is too far from the origin you teleport them and the entire world back near the origin. As long as the relative offsets remain the same it won't have a visual difference but will help solve this issue. 🔴 RELATED VIDEOS 🔴 Learn C# FREE Tutorial Course Beginner to Advanced! [12 HOURS] ua-cam.com/video/qZpMX8Re_2Q/v-deo.html Can I make an OPEN WORLD Game in ONE WEEK? ua-cam.com/video/JeKaWX4m52I/v-deo.html Can I add MULTIPLAYER to my Open World Game in 4 HOURS? ua-cam.com/video/3nHcXQg0Brs/v-deo.html I also make MISTAKES! ua-cam.com/video/h3LCr7LDuUs/v-deo.html
Note that your algorithm changes the absolute position of the player, shifting it back to the origin periodically (when a threshold distance it reached). The real floating origin method was originally designed to never move the player. The World is relative moved about the player who stays at the origin. To avoid confusion, it would be good if you clarigy this difference.
So they guys developing Outer Wild, had to add some extra logic on the game to avoid this escenario. For the people that havent played, they implemented a scaled down solar system and when the player was reaching "exotic distances", everything was going to sh**. Their solution was always keep the user on the center of the Unity Scene and apply deltas to the environment.
Minecraft had this problem solved because it used 32 bit Integer instead of float in chunk generation. Thats why it has a huge world with 30 million blocks distance from origin to each end
My daughter showed me that episiode and I put the quote it into my PhD - from which the real floating origin algorithm came, not the one described here.
Great explanation. However, by fixing this issue by shifting the world to the origin comes with new/other problems. - How would you handle active NPC's their movement in a large world being shifted around? Possibly creating a spike due to recalculation of navigation paths. --> Probably by subscribing to a WorldShift event and recalculate their navigation path? - Isn't it very heavy to shift the entire world and all of its objects? You'd have to move every object to a certain offset. - How would you simulate NPC's movement in a section of the world without it being loaded in? This can be really far away in a massive world. This goes a bit into world simulation. For example, V Rising is doing to a lot of simulations in quite a large world. Not sure if that would hit the floating point issues or whether they're just inside the range as a technical limitation. Doing this for multiplayer raises even more questions. Such as how to simulate the NPC's server side when player A is in the far left side of the world and player B in the far right side of the world. Bringing both of those to the origin point and have them not interact with eachother? Unity doesn't have this kind of functionalities built-in afaik. Which is kind of sad. Nav Mesh is great but afaik it cannot be used with large worlds.
That's a good question. The answer is they each have their own origin-centric view into the same World data. Their relative position and relative motion is maintained correctly, and with high accuracy, by the (real) floating origin algorithm. E.g. two multiplayer examples: 2-player ua-cam.com/video/2hwAXdxFzHU/v-deo.html and 9-player: ua-cam.com/video/SvBpw92V2Lw/v-deo.html.
Every game is unique so there's a dozen possible solutions for all those possible problems. For NPCs, you can just disable their simulation when too far, or just store an offset and use smaller values for the simulation logic. Moving all objects is a super fast operation, unless you have millions upon millions of objects it won't really be noticeable, and if you do have such an insane scale then you can just move a few objects every frame. Usually in multiplayer you don't allow players to move far away from the host, that's the simplest solution. Or you can use distributed authority, or you can use the same thing I said for the NPCs, store an offset for each player and use smaller numbers
In the SciFi game Im creating (vids under channel) i use floating origin. Its necessary given the scale of the game im creating. There are some caveats to deal with but there are very easy workarounds for them. Using FO is basically mandatory for SciFi games.
I made a racecar game and one time my car fell off the edge of the world and I got up to use the bathroom. I ended up coming back to my PC hours later and the car became a twisted stretched out mess. I was soooooo confused until I read the warning.
I first learned about this from a behind the scenes with the Outer Wilds developers. They talked about keeping the player at the center of the coordinate system and moving planets to the player as you explore the solar system.
Isn't teleporting everything performance-intensive? And you can't move static items, right? So no baked lighting and you can't use Unity's default Occlusion Culling system?
Shifing the World by small differentials on one transform on top of the World is a matter of one additional transform out of thousands per frame. No measurable difference. Unless you use the for-loop approach instead. And, yes, static-based systems are not compatible.
Unless you have millions of objects then no it won't be noticeable. And yes static objects cannot move, in that case you can look into additive scene loading
Yeah, outer wilds have an achievement where you have to go reaaaaaaly far away before the sun explodes, and you can see that the planets(and the map) start to go crazy. I also encontered this when my friend was playing my game made for a gamejam, found a bug that led to infinity velocity, and got yeeted of the playable area 😅.
Too funny, about a week ago I had to implement an Origin reset script in my project to prevent this from happening. Not really Ideal but hey you do what you have to do lol,.
I find for most things floats are fine (just make sure you don't fall into the trap of errors in float comparison). When I something more accurate I switch to doubles. When I was doing scientific sims where accuracy is paramount we used doubles and decimals.
Hope unity will add camera relative rendering to urp soon. And a correction to the video that: most of the modern games do not use floating origin, they use camera-relative rendering, which the origin point on gpu move with camera by default. Also, Unreal does not use double to store position, they also use camera-relative rendering. Using floating origin nowadays is not a good approach compared to camera-relative rendering because it needs to move large amount of object and will cause high memory usage and fps drop.
So if making a game like minecraft with procedural generation, and you need a coordinate system to show your position in the world, how would you handle it when shifting the world origin? Do you just keep track of how much the world have shifted and add it to the coordinates? Similarly, if the world is generated using noise in world position, wouldn't it affect the world generation when changing the world origin?
Yes you can keep track of the current offset from the origin and store it in a simple int which will allow storing a giant world. So if the player moves to 1012.56f,0,0 and you snap everything back to 12.56f,0,0; you just store an int currentOffset = 1000; For the generation you just add the current offset to the current origin to get the total world position
I had enrolled two of your courses, it was free the code given by my dearest friend, For first one or two days i could watch properly now its asking for enroll again Can you please tell whats going on? I cant contact there thats why texting here, please help me out
That is exactly the real floating origin solution: the player is stationary at the origin and never moved. A recent example: ua-cam.com/video/ADKTh0Bh08A/v-deo.html
@@gabrielandraderosa8622 That is a common misconception. The main performance issues are from the usual suspects: scene complexity, bandwidth and coding complexity
Do it like I mentioned in the video, cycle through all your objects and move them all by a certain offset amount. So if the player goes past 1000,0,0 then cycle through all objects and move them all -1000,0,0
The main approach (originally anyway) is to leave the player alone. Put a transform above the rest of the World (not including the player) and move the World in reverse. This is good except it does not solve distant relative jitter, which needs an additional method.
Depends on how much precision you need. If you need 10 decimals of precision you can support a much smaller world than if you just need 5 decimals. But in general, you can probably get up to 100,000 units without issues in most cases
My measurements show that you will not commonly encounter an issue until after about 70km..For example, some slight visual jitter occurs at about 70km here: ua-cam.com/video/ZR-x0y_oHek/v-deo.html. But, as I said above, it depends a lot on the sensitivity of certain operations to error, and distance from camera
I wonder how feasible it would be to take the Transform component and make a version that uses doubles or decimals, given how integrated into the Unity workflow it is. You'd essentially have to recreate all the references, all the rendering, and all the Editors.
The problem with floating origin point and unity is that you can't use static objects, navmeshes and other unity solutions. I've read once that unreal doesn't use double, but it works with floating origin point out of the box, so the engine is already working with floating origin point and all their solutions are based on it.
That's because unreal use camera relative rendering, which the world origin on gpu move with the camera by defualt. That's how most of morden game do, and HDRP have this feature by defualt.
@@Misaki_eku That's just for the rendering, we still have a problem with the Transform coordinates still being floats with world coordinates. So the render will look very nice, the physics and all will still go to shit!
"I've read once that unreal doesn't use double, but it works with floating origin point out of the box," That's not what i have heard, do you have a link to the info?
The exact same. Multiplayer games aren’t really multiplayer. You’re playing by yourself. And the guy on the other computer is playing by himself. Essentially you both have chess boards and both chess boards have all the white and black pieces. And you yell across the room what your move was and that other person moves your piece on their board and you move yours on your board. And a referee runs back and forth making sure neither of you are cheating. Or the referee moves both boards pieces for you. So your point of origin being thousands of units away from the other persons doesn’t matter because they have a different chess board.
The same way, but this is also one reason why a lot of multiplayer games on large worlds don't let you get too far away from the host. If you want to support multiple players very far apart you need a different solution
from what i understood, it takes more than 500k units to start getting weird when starting from zero, right? thats already a great number, its seems a super specifiic thing for REALLY HUGE games since almost every time a unit is a meter, so getting 500km2 should be enough i guess
The issue doubles in intensity every power of two units away, so even when it's not very noticeable, it still has an effect, yes for most use-cases you'll never reach these coordinates. And while visual issues start becoming noticeable at those distances, other issues with movement, physics and much more start being noticeable well, well before, only a few thousand units from origin.
It depends on how much precision you need. If your smaller objects only need 5 decimals of precision then you can support a much larger world than if your smaller objects need 10 decimals of precision. But yes only super huge games will encounter this issue
You can get problems from less than one kilometer. Whether is is noticeable depends on the sensitivity of the operation and the distance of the problem from the camera. I found this the case with the shifty method (which codemonkey uses) here: ua-cam.com/video/vbIb9dh1f7o/v-deo.html.
Also note... floating point precision has also a lot of funny quirks... Like the number 3...... they lie to you. its not 3 Its also funny, that they did not fix the floating point precisiion issue in minecraft.... they .... can.... do... it.... Its just that... why fix smt, that 99.99999% of players wont ever see
Could be. But the most important distinction to make is that it could be any engine that uses floats as position values. So even if you had an in-house engine and decided on floats as position values, you’d get the same result, since that’s how computers actually represent floating point numbers.
@CodeMonkyUnity Congratulations on a great explanation of floating point and the increase in numerical instability with distance from the origin. It is the best I have seen, even better than mine :/
✅ Watch my FREE C# Course! ua-cam.com/video/qZpMX8Re_2Q/v-deo.html
🌍 FREE Game Dev Report Newsletter cmonkey.co/gamedevreportnewsletter
💬 Do you know what is going on in this video? Such a strange bug where a normal looking Sphere suddenly becomes all jittery and messed up.
The answer: Floating point precision.
Floats have a limited number of digits, so if you position an object in a huge position, it won't have enough space for many digits after the decimal point, they will be forced to round up or down. Meaning all the vertices on the sphere won't be able to go to their exact position, so they start jumping up and down as the value is being rounded.
One fix to this problem is a Floating Origin Point. This is where you can keep track of the player position, and if the player is too far from the origin you teleport them and the entire world back near the origin. As long as the relative offsets remain the same it won't have a visual difference but will help solve this issue.
🔴 RELATED VIDEOS 🔴
Learn C# FREE Tutorial Course Beginner to Advanced! [12 HOURS] ua-cam.com/video/qZpMX8Re_2Q/v-deo.html
Can I make an OPEN WORLD Game in ONE WEEK? ua-cam.com/video/JeKaWX4m52I/v-deo.html
Can I add MULTIPLAYER to my Open World Game in 4 HOURS? ua-cam.com/video/3nHcXQg0Brs/v-deo.html
I also make MISTAKES! ua-cam.com/video/h3LCr7LDuUs/v-deo.html
how's your life mate
Note that your algorithm changes the absolute position of the player, shifting it back to the origin periodically (when a threshold distance it reached). The real floating origin method was originally designed to never move the player. The World is relative moved about the player who stays at the origin. To avoid confusion, it would be good if you clarigy this difference.
Such an excellent video! Beautifully displayed and explained
Thanks! That means a lot coming from you since you always have excellent presentations!
So they guys developing Outer Wild, had to add some extra logic on the game to avoid this escenario. For the people that havent played, they implemented a scaled down solar system and when the player was reaching "exotic distances", everything was going to sh**. Their solution was always keep the user on the center of the Unity Scene and apply deltas to the environment.
Minecraft had this problem solved because it used 32 bit Integer instead of float in chunk generation. Thats why it has a huge world with 30 million blocks distance from origin to each end
Isn't it 30.000.000? (30 million)
@@beefy___ Oh yea i corrected it, missed one zero right there
Not true at all... Minecraft uses an integer for your "region" (a 32x32 chunk area) and a float for your local position within that region.
"The engines don't move the ship at all. The ship stays where it is, and the engines move the universe around it"
-- Cubert Farnsworth, Futurama
I remember seeing that episode as a kid and it blew my mind. The fact that he made an engine that moves the entire universe is insane.
My daughter showed me that episiode and I put the quote it into my PhD - from which the real floating origin algorithm came, not the one described here.
Great explanation. However, by fixing this issue by shifting the world to the origin comes with new/other problems.
- How would you handle active NPC's their movement in a large world being shifted around?
Possibly creating a spike due to recalculation of navigation paths.
--> Probably by subscribing to a WorldShift event and recalculate their navigation path?
- Isn't it very heavy to shift the entire world and all of its objects? You'd have to move every object to a certain offset.
- How would you simulate NPC's movement in a section of the world without it being loaded in?
This can be really far away in a massive world. This goes a bit into world simulation.
For example, V Rising is doing to a lot of simulations in quite a large world. Not sure if that would hit the floating point issues or whether they're just inside the range as a technical limitation.
Doing this for multiplayer raises even more questions. Such as how to simulate the NPC's server side when player A is in the far left side of the world and player B in the far right side of the world.
Bringing both of those to the origin point and have them not interact with eachother?
Unity doesn't have this kind of functionalities built-in afaik. Which is kind of sad. Nav Mesh is great but afaik it cannot be used with large worlds.
That's a good question. The answer is they each have their own origin-centric view into the same World data. Their relative position and relative motion is maintained correctly, and with high accuracy, by the (real) floating origin algorithm. E.g. two multiplayer examples: 2-player ua-cam.com/video/2hwAXdxFzHU/v-deo.html and 9-player: ua-cam.com/video/SvBpw92V2Lw/v-deo.html.
Every game is unique so there's a dozen possible solutions for all those possible problems.
For NPCs, you can just disable their simulation when too far, or just store an offset and use smaller values for the simulation logic.
Moving all objects is a super fast operation, unless you have millions upon millions of objects it won't really be noticeable, and if you do have such an insane scale then you can just move a few objects every frame.
Usually in multiplayer you don't allow players to move far away from the host, that's the simplest solution. Or you can use distributed authority, or you can use the same thing I said for the NPCs, store an offset for each player and use smaller numbers
In the SciFi game Im creating (vids under channel) i use floating origin.
Its necessary given the scale of the game im creating.
There are some caveats to deal with but there are very easy workarounds for them.
Using FO is basically mandatory for SciFi games.
I made a racecar game and one time my car fell off the edge of the world and I got up to use the bathroom. I ended up coming back to my PC hours later and the car became a twisted stretched out mess. I was soooooo confused until I read the warning.
heh that's funny!
I first learned about this from a behind the scenes with the Outer Wilds developers. They talked about keeping the player at the center of the coordinate system and moving planets to the player as you explore the solar system.
This is an issue I've had since starting out in game dev
even when creating art or models.
Its also a great reason for newer devs to start small :D
Isn't teleporting everything performance-intensive? And you can't move static items, right? So no baked lighting and you can't use Unity's default Occlusion Culling system?
Shifing the World by small differentials on one transform on top of the World is a matter of one additional transform out of thousands per frame. No measurable difference. Unless you use the for-loop approach instead. And, yes, static-based systems are not compatible.
Unless you have millions of objects then no it won't be noticeable. And yes static objects cannot move, in that case you can look into additive scene loading
Code Monkey's Consistency is all I want 🗿
Yeah, outer wilds have an achievement where you have to go reaaaaaaly far away before the sun explodes, and you can see that the planets(and the map) start to go crazy.
I also encontered this when my friend was playing my game made for a gamejam, found a bug that led to infinity velocity, and got yeeted of the playable area 😅.
Too funny, about a week ago I had to implement an Origin reset script in my project to prevent this from happening. Not really Ideal but hey you do what you have to do lol,.
I find for most things floats are fine (just make sure you don't fall into the trap of errors in float comparison). When I something more accurate I switch to doubles. When I was doing scientific sims where accuracy is paramount we used doubles and decimals.
Hope unity will add camera relative rendering to urp soon. And a correction to the video that: most of the modern games do not use floating origin, they use camera-relative rendering, which the origin point on gpu move with camera by default. Also, Unreal does not use double to store position, they also use camera-relative rendering. Using floating origin nowadays is not a good approach compared to camera-relative rendering because it needs to move large amount of object and will cause high memory usage and fps drop.
I did research on this because i ran into this issues with the physics of large objects falling extremely slow it also will mess with ui aswell.
So if making a game like minecraft with procedural generation, and you need a coordinate system to show your position in the world, how would you handle it when shifting the world origin? Do you just keep track of how much the world have shifted and add it to the coordinates?
Similarly, if the world is generated using noise in world position, wouldn't it affect the world generation when changing the world origin?
Yes you can keep track of the current offset from the origin and store it in a simple int which will allow storing a giant world.
So if the player moves to 1012.56f,0,0 and you snap everything back to 12.56f,0,0; you just store an int currentOffset = 1000;
For the generation you just add the current offset to the current origin to get the total world position
love your videos
is this what happens with vertex jitter in PSX/PS1?
Yes and no... ps1 games store vertex data as ints, not floats. This causes vertexes to snap in place.
So, if you do the invisible teleport... what happens with the light probes?
What language did you use to make your website? C#.Net framework?
Just normal PHP, HTML, JavaScript. Didn't use any frameworks (other than a bit of JQuery)
I had enrolled two of your courses, it was free the code given by my dearest friend, For first one or two days i could watch properly now its asking for enroll again
Can you please tell whats going on?
I cant contact there thats why texting here, please help me out
Can you use the contact form on my website to let me know your email, then I'll look in the backend unitycodemonkey.com/contact.php
Another option is to never move the player and just move everything around them in the first place.
I think this can lead to poor performance por large worlds
That is exactly the real floating origin solution: the player is stationary at the origin and never moved. A recent example: ua-cam.com/video/ADKTh0Bh08A/v-deo.html
@@gabrielandraderosa8622 That is a common misconception. The main performance issues are from the usual suspects: scene complexity, bandwidth and coding complexity
How to shift world origin ? I show that video. An asset did it but if i don't use that asset then?
Do it like I mentioned in the video, cycle through all your objects and move them all by a certain offset amount. So if the player goes past 1000,0,0 then cycle through all objects and move them all -1000,0,0
The main approach (originally anyway) is to leave the player alone. Put a transform above the rest of the World (not including the player) and move the World in reverse. This is good except it does not solve distant relative jitter, which needs an additional method.
what's the threshold on the size of the map after which we have to care about this?
Depends on how much precision you need. If you need 10 decimals of precision you can support a much smaller world than if you just need 5 decimals.
But in general, you can probably get up to 100,000 units without issues in most cases
My measurements show that you will not commonly encounter an issue until after about 70km..For example, some slight visual jitter occurs at about 70km here: ua-cam.com/video/ZR-x0y_oHek/v-deo.html. But, as I said above, it depends a lot on the sensitivity of certain operations to error, and distance from camera
I wonder how feasible it would be to take the Transform component and make a version that uses doubles or decimals, given how integrated into the Unity workflow it is. You'd essentially have to recreate all the references, all the rendering, and all the Editors.
The problem with floating origin point and unity is that you can't use static objects, navmeshes and other unity solutions. I've read once that unreal doesn't use double, but it works with floating origin point out of the box, so the engine is already working with floating origin point and all their solutions are based on it.
That's because unreal use camera relative rendering, which the world origin on gpu move with the camera by defualt. That's how most of morden game do, and HDRP have this feature by defualt.
@@Misaki_eku That's just for the rendering, we still have a problem with the Transform coordinates still being floats with world coordinates. So the render will look very nice, the physics and all will still go to shit!
@@raulzilla Physics in unity support world spliting by defualt. You just need to turn it on in project settings.
"I've read once that unreal doesn't use double, but it works with floating origin point out of the box," That's not what i have heard, do you have a link to the info?
@@floatingorigin It was years ago, I was looking for an engine to use and read a lot of forum discussions about the. It was back on unreal 4.
How would something like this be handled for a multiplayer game?
The exact same. Multiplayer games aren’t really multiplayer. You’re playing by yourself. And the guy on the other computer is playing by himself. Essentially you both have chess boards and both chess boards have all the white and black pieces. And you yell across the room what your move was and that other person moves your piece on their board and you move yours on your board. And a referee runs back and forth making sure neither of you are cheating. Or the referee moves both boards pieces for you. So your point of origin being thousands of units away from the other persons doesn’t matter because they have a different chess board.
The same way, but this is also one reason why a lot of multiplayer games on large worlds don't let you get too far away from the host. If you want to support multiple players very far apart you need a different solution
from what i understood, it takes more than 500k units to start getting weird when starting from zero, right? thats already a great number, its seems a super specifiic thing for REALLY HUGE games since almost every time a unit is a meter, so getting 500km2 should be enough i guess
Some people say they notice problems starting at 2000 units and up
The issue doubles in intensity every power of two units away, so even when it's not very noticeable, it still has an effect, yes for most use-cases you'll never reach these coordinates. And while visual issues start becoming noticeable at those distances, other issues with movement, physics and much more start being noticeable well, well before, only a few thousand units from origin.
It depends on how much precision you need. If your smaller objects only need 5 decimals of precision then you can support a much larger world than if your smaller objects need 10 decimals of precision.
But yes only super huge games will encounter this issue
You can get problems from less than one kilometer. Whether is is noticeable depends on the sensitivity of the operation and the distance of the problem from the camera. I found this the case with the shifty method (which codemonkey uses) here: ua-cam.com/video/vbIb9dh1f7o/v-deo.html.
❤
How to make playstation looking game without shader: start far the zero point 😂 ez
first comment
love your videos...
so early
Also note... floating point precision has also a lot of funny quirks... Like the number 3...... they lie to you. its not 3
Its also funny, that they did not fix the floating point precisiion issue in minecraft.... they .... can.... do... it.... Its just that... why fix smt, that 99.99999% of players wont ever see
Hmmmm...
Does this mean that super mario odyssey was made using Unity ?
Could be. But the most important distinction to make is that it could be any engine that uses floats as position values. So even if you had an in-house engine and decided on floats as position values, you’d get the same result, since that’s how computers actually represent floating point numbers.
Pretty sure Nintendo only uses their in-house engines for their games
@CodeMonkyUnity Congratulations on a great explanation of floating point and the increase in numerical instability with distance from the origin. It is the best I have seen, even better than mine :/