Mixing numbers like that is going to be a problem when you try to convert between the two.

A float has 24 bits, or about six decimal digits of precision. Your representation has 32 significant bits, with 16 of them below the decimal point. If your first half goes above eight bits you will be unable to accurately convert between a float and back.

I'm not aware of any space game that uses real life scales for planets, stars, and other objects. Space is mind-boggling huge.

Space games often use a 64 bit integer for positions. Or even more.

Have a look for a library called vmath, (I'm working from memory here so I may be wrong. I apologise in advance if I am)

I seem to remember it used doubles for positions within a solar system them had 3 more coordinates (int's I think) for the rest of the coordinate system.

One simulator that used a similar system is Celestia.

http://sourceforge.net/projects/celestia/files/Celestia-source/1.6.1/

Hope this helps

Thank you all for your answers !

Frob, you talk about mixing numbers. It's one of my doubts, do I need to convert the fixed point back to float ? Float to Integer => no loss.

If don't need to convert back, how will work the shaders, as the numbers will be to much big...

I read, a lot of engine are using fixed points, there must be a solution..

Stainless, thank you for the links, I will read them now.

Vortez, I read that it's a bad solution to use double, I tried to get my idea about. There was too much loss of performances.

Frob, you talk about mixing numbers. It's one of my doubts, do I need to convert the fixed point back to float ? Float to Integer => no loss.
If don't need to convert back, how will work the shaders, as the numbers will be to much big...
I read, a lot of engine are using fixed points, there must be a solution..

There are many problems with it, not just conversion back and forth.

Lets say you are dealing with numbers in a region that is, just for sake of argument, all taking place around 60,000 units from the origin. That's nice that you can be there, but it means you only can go to about 0.1 units for anything before you run out of bits. Translating your models to the scale means any detail beyond 10 cm is at risk. You are guaranteed to be out of bits by the centimeter resolution, so your models are going to render like trash. Your camera's smallest step is also going to be several centimeters as you are out of bits, so don't expect anything to render well.

Or lets say a planet is 3 million units away. Your finest measure of unit will be about ten meter increments, since you have floated up to a higher magnitude. Anything less than ten meters is going to round to zero.

Then there is also the conversion problem. One has 32 significant digits, the other has 24. Your 16:16 fixed format means you will always have at least 16 bits of significant numbers, so the highest integer you can reach is 255. If your units are meters, a limit of 255 meters is not going to work out for you.

There are techniques to constantly re-center the world around the player, giving you lots of precision to work with, but it comes with significant complexity. It is one of those "if you have to ask how to do it, you probably aren't skilled enough to do it" scenarios.

It is certainly possible to have simulations with very large worlds and massive data sets. It just doesn't work well in "For Beginners". What you describe is a massive undertaking, not for someone who is just learning.


Now, fixed point all by itself, that is something you can learn. On hardware like the Nintendo DS, there were three main fixed-point numbers. There were two 16-bit formats (1.3.12 and 1.11.4 layouts), and the 32-bit 1.19.12 format. The choice on which one you used was based on the system you were using and the number of bits you need. These can be learned if you want, but if you aren't developing for fixed point hardware it is a lot of effort for little reward. Ultimately you will end up wrapping the fixed point numbers in a class, overloading all the operators, and then doing all your operations on them like you would with any other number system.

First of all, you do not use fixed-point as optimization, but for correctness.

Using floating point for simulation (or procedural content) at planet scale is problematic for several reasons. First of all, floats are most densely packed around zero, with an exponential falloff the farther away from zero you are. Which, on a planet's surface, where all coordinates are pretty far away from the center, sucks big time. Your stuff isn't located where your precision lies.

But more, adding floats of different magnitudes will lose you some bits. Though, what makes them insidious, not always. It looks like it works just fine, but then it bites you when you don't expect it. 0.5 + 0.5 works just fine (since they're the same range), and even 2500.5 + 0.5 works fine (by coincidence, since they don't consume all digits), but 2500.125 + 0.0625 does not. Errors sum up the more operations you do, and they are not the same at different locations in your world. What looks fine and works fine at one end may not work (quite possibly will not work) at the other end.

Sometimes this just doesn't matter and you get away with it, but sometimes it will give you unacceptable artefacts. Emil Persson gives a better and more detailled explanation in his 2012 Siggraph presentation as well as in his Just Cause 2 chapter in the GPU Pro book (keywords: vertex snapping, jerky animations, shadow map jumping, jitter bug).

Fixed-point numbers are just integers, they are evenly distributed and don't lose bits. But on the downside, they have a very finite maximum range. You can do something like 16.16 but that isn't strictly necessary. You can just as well use any number of bits, or even any scale. The only thing that matters is that you must decide ahead of time what will be the biggest thing and the smallest thing that you wish to represent. For example, if you wish to represent detail up to 1mm, and you have 32bit integers, then that means the distance (or size) you can represent is about 4294 kilometers. If you want a planet 5629 kilometers 194 meters 29 centimeters, then you either must choose a coarser resolution, or use more bits, or you are out of luck. Floating point would "just work" if the planet is a little bigger, although unprecise, but fixed point simply won't.

With that in mind, and given "planetary scale", you should most definitively consider using 64-bit integers. These will give you a large enough range to represent an entire solar system at micrometer precision. Which basically means you can stop thinking/worrying about what's the right scale right now. On the other hand, this:

What about doubles instead of floats?

is not something I would recommend, since it does not address the issues of floating point, it only masquerades the problem so it occurs a bit later.

Where to start using them and.. when to stop ?

From the very beginning until... until... until then. Eventually, when passing vertices to a graphics API or at the very least in your shaders, you will have to convert to floats, one way or another (simply because the GPU works that way). Do that when you have no more distances to add/subtract. But start off with thinking of something that is 1.5 meters not in terms of 1.5 but in terms of 1500 (or e.g. 1536 if you prefer power-of-two scales, or any different scale, whatever you like).

If the coordinates of point.x is 368914876

It is not. It may be 368914876, but relative to an origin which is, say, 369000000, so it is really only 85124. You do translations relative to a local origin (close to your eye) in fixed-point, which is just adding/subtracting plain normal integers.

I imagine I must choose a power of 2 radius for quadtree divisions

As long as the boundary between halves is always the same (i.e. you are consistently truncating or rounding the same way), it doesn't really matter if one half if a little bigger than the other. We're talking about a millimeter or so here (or a micrometer even).

space is truly huge. a light year is 9.46 quadrillion meters. a parsec is 3.2616 light years. and astronomers use units of kilo parsecs and mega parsecs for measuring the most distant heavenly bodies.

Luckily, these huge distances don't matter much.

If you look at a nearby stellar object (let's say Proxima Centauri, which is a mere 4.2 lightyears), it doesn't matter whether you measure the distance with micrometer or kilometer precision because you can't tell the difference. If you travel at "normal" speeds, then travelling for the entire duration of your life will bring you none closer to Proxima Centauri than about 4.2 light years. It is exactly the same in every respect.

On the other hand, if you have some form of "hyperdrive" (or any other fictional faster-than-light travel. wormholes or whatever) then you can reach Proxima Centauri no problem, but you still cannot tell the difference between a micrometer or a hundred thousand kilometers. There's no way you could hit the "stop starship" button fast enough to travel less than a hundred thousand kilometers, and there is nothing interesting but ... empty space... anyway. There is also no way of telling, after travelling 4.2 lightyears, whether that was really 4.2 lightyears or 4.2 lightyears, 33.7 kilometers and 20.0052 meters. Our sun is the same tiny spot when looked at from over 4 lightyears away whether or not it's a few kilometers off or not.

In other words, you can conveniently use a coarse coordinate system with a resolution of thousands (ten thousands, if you will) of kilometers to model the huge empty space between interesting things, which is convenient for modelling entire galaxies. And then again, use a different coordinate system at planet or solar-system scale (say, 64bit integers, micrometer precision) to model the "interesting stuff". Switch between them whenever you swich hyperdrive on/off.