I have to wonder if this is expected behavior. I mean... sure it's far away from the world map, but why should that affect the render of the current area? Is everything literally based on distance from world center? If so, maybe that could explain some glitches?? I don't know. I know other games get weird way far out, but I think it's usually in relation to how you, being way far out, interact with distances and coordinates based on the center? (I'm talking out of my ass if you can't tell.)
I have to wonder if this is expected behavior. I mean... sure it's far away from the world map, but why should that affect the render of the current area? Is everything literally based on distance from world center? If so, maybe that could explain some glitches?? I don't know. I know other games get weird way far out, but I think it's usually in relation to how you, being way far out, interact with distances and coordinates based on the center? (I'm talking out of my ass if you can't tell.)
TL;DR:
Pretty sure it's from floating point precision errors.
Computer Science Wizard Fun-Ruining Talk:
A float is a 4-byte(usually) datatype used to store numbers. However, the bits in a float are used very differently than other number storing types. A 4-byte integer, for example, can store over 4.2 billion unique values (2 ^ 32, 2 values per bit and 32 bits in 4 bytes). 1, 43, and 2,560,372 are all valid. You can even use the highest bit to give the integer a sign so that you can keep track of negative numbers (gives you range from +2.1 billion to -2.1 billion). However, despite all of those values it is still an integer. It has no way to represent 0.5, 0.000009, or -1,205.7625. Floats can do this, and when you want character models to have their vertices in very precise locations they are excellent for this purpose. In addition, a float can range from well over 4 billion to extremely small values like 0.000009. However, floats are not magic. They are still limited by their size of 4 bytes. If you look at how floats use their bits you'll begin to understand the aforementioned precision errors. Like a signed integer the highest bit is used to keep track of the sign of the value. 0 or off for positive, 1 or on for negative. After this first bit though, things get crazy.
-Now it's worth mentioning I'm not a complete expert on this next part so take it with a grain of salt.-
The rest of the bits are used to store two pieces of data that are used in a formula to produce the value the float represents (that 3.14 you want to see, for example). The first group of bits is smaller and represents an exponent, and the second group of bits represents a fraction. The fraction is raised by the exponent to get your value. Another way of putting it is that the fraction represents your numerical value and the exponent controls where to put the decimal point. 3.14 could be 0.000314 or 3,140,000 depending upon the exponent, but for each of those the fraction would be the same. The flaw in this logic that is caused by the 4-byte limit is that when you get to the really big numbers or the really small numbers you lose control over how precise those values can be. As an example, if you take 3.14 it's very easy to precisely make it 4.14 or 3.15. But if you scale it up to a crazy large number like 3,140,000,000,000 you cannot make it be exactly 3,140,000,000,001 or 3,139,999,999,999. For very small numbers, you lose control after around six digits past 0. E.g. 0.000314 divided by 10 would give you something like 0.00003139. What this means for the above shown glitch is that the models are so far away from origin the floats that define their coordinates cannot represent the location they're supposed to, and so constantly jump between the two nearest values they can represent.
Bonus Trivia:
You will see this behavior anywhere floats are used, which means not only vertices in models, but even things like the position of an object, its velocity, or its direction. The further the decimal point is from 0, the less precision it will have. A fix to this is to replace floats with doubles. A double is the same as a float but it gets to use 8 bytes instead of 4, so it is able to be much more precise. The problem is that you need a lot of floats in games these days and doubling their size would greatly increase the amount of memory the game uses as well.
Edit:
Just watched the video. Makes me realize the next creature we need implemented;
Comments
Their eyes are pushed outwards and pressed back in seventy thousand times every second.
TL;DR:
Pretty sure it's from floating point precision errors.
Computer Science Wizard Fun-Ruining Talk:
A float is a 4-byte(usually) datatype used to store numbers. However, the bits in a float are used very differently than other number storing types. A 4-byte integer, for example, can store over 4.2 billion unique values (2 ^ 32, 2 values per bit and 32 bits in 4 bytes). 1, 43, and 2,560,372 are all valid. You can even use the highest bit to give the integer a sign so that you can keep track of negative numbers (gives you range from +2.1 billion to -2.1 billion). However, despite all of those values it is still an integer. It has no way to represent 0.5, 0.000009, or -1,205.7625. Floats can do this, and when you want character models to have their vertices in very precise locations they are excellent for this purpose. In addition, a float can range from well over 4 billion to extremely small values like 0.000009. However, floats are not magic. They are still limited by their size of 4 bytes. If you look at how floats use their bits you'll begin to understand the aforementioned precision errors. Like a signed integer the highest bit is used to keep track of the sign of the value. 0 or off for positive, 1 or on for negative. After this first bit though, things get crazy.
-Now it's worth mentioning I'm not a complete expert on this next part so take it with a grain of salt.-
The rest of the bits are used to store two pieces of data that are used in a formula to produce the value the float represents (that 3.14 you want to see, for example). The first group of bits is smaller and represents an exponent, and the second group of bits represents a fraction. The fraction is raised by the exponent to get your value. Another way of putting it is that the fraction represents your numerical value and the exponent controls where to put the decimal point. 3.14 could be 0.000314 or 3,140,000 depending upon the exponent, but for each of those the fraction would be the same. The flaw in this logic that is caused by the 4-byte limit is that when you get to the really big numbers or the really small numbers you lose control over how precise those values can be. As an example, if you take 3.14 it's very easy to precisely make it 4.14 or 3.15. But if you scale it up to a crazy large number like 3,140,000,000,000 you cannot make it be exactly 3,140,000,000,001 or 3,139,999,999,999. For very small numbers, you lose control after around six digits past 0. E.g. 0.000314 divided by 10 would give you something like 0.00003139. What this means for the above shown glitch is that the models are so far away from origin the floats that define their coordinates cannot represent the location they're supposed to, and so constantly jump between the two nearest values they can represent.
Bonus Trivia:
You will see this behavior anywhere floats are used, which means not only vertices in models, but even things like the position of an object, its velocity, or its direction. The further the decimal point is from 0, the less precision it will have. A fix to this is to replace floats with doubles. A double is the same as a float but it gets to use 8 bytes instead of 4, so it is able to be much more precise. The problem is that you need a lot of floats in games these days and doubling their size would greatly increase the amount of memory the game uses as well.
Edit:
Just watched the video. Makes me realize the next creature we need implemented;