Incidentally I thought about the same question for the last few days. The following answer is what I came up with:
2 hours ago, fleabay said:
OpenGL only knows values between -1 and 1 in coordinate space so that gives you 3 ints to work with.
While it is true that there are only 3 integer values between -1 and 1 it is still possible to get a much higher resolution. Just think of UNORM and SNORM. UNORM means integers are normalized values in the range [0,1] and SNORM in the range [-1, 1]. e.g.: Using this you can subdivide the range into 2^32 parts with a 32-bit integer and not just 3.
The big problem is that with this you can not represent values outside of the range. Therefore representing positions with U/SNORM integers does not make much sense. As you are restricted to a very narrow range.
Another more sensible way would be to split one distance unit into smaller ones. For example, you can split one meter into 1 million parts. That will create a very fine-grained grid of possible positions. Snapping to the grid will not really be noticeable. With 32-bit numbers, you get a very big grid(40km x 40km) and with 64-bit integers it is quite enormous(10^10km x 10^10km). At first glance that sounds fine.
The problems with integers are that you want it to be fine-grained, but you still want to be able to calculate with them. The bigger the numbers the bigger the problems. Take floating-point numbers as an example: Adding a very low number to a very large number may lead to no change at all to the large number. Nonetheless, floating-point numbers work well if you are careful.
While floating-point numbers get inaccurate if there is a large discrepancy between the 2 numbers, integers freak out completely if you multiply 2 large numbers.
Let's explain with a little example: With the previously defined grid let us calculate the distance between 2 points. The difference vector is (1*10^6, 2*10^6, 0) which corresponds to (1 meter, 2 meters, 0 meters). We now have to calculate the square root of 10^6^2 + 2*10^6^2 + 0. This results in the square root of 3*10^12. 10^12 is approximately 2^40 which cannot be represented in a 32-bit number and therefore gets cut of after 32-bits and the resulting square root gets some completely unpredictable value. This effectively limits us to 16-bit values which are not very accurate. If there is ever the need to multiply 3 numbers of that scale then we already need 60-bits to represent it which already nearly overflows in a 64-bit integer and our points are just a few meters apart nearly at the center of the world. With bigger numbers the problem gets only worse. A 1km distance means a squared value of approximately 2^60. 10km means 2^66.
Switching to 64-bit values helps a bit but that only gives us safe values up to 32-bit. Another possibility is to cast up to 128-bit numbers for each calculation and cast back down to 64-bit at the end. This could work but 64-bit multiplication is already not easy(is there a 64-bit multiplication instruction on x86-64? I have not found any. Not even in the SSE instructions) and 128-bit calculations are even more complicated. Especially on 32-bit systems. 128-bit multiplication is probably still faster than a double precision floating point multiplication, but for every multiplication we might overflow our value which might spell disaster.
TLDR: I would say the problems in floating point calculations is the lack of precision which is not so bad.
Problems in integer calculations are completely wrong results because of overflows which is very bad.
