Planning for large vectors

When working with scenes set in outer space, vectors can get quite large (millions, billions of units)

now, I have not experienced any problems yet, however, I have read that using large vectors can causes errors/glitchy movement. How true is this? Is it a large problem?

I just want to plan for this ahead and build my game around a scene managment system that will fit within the framework of vectof3f and float.

supposedly floats cover a range from 1.40129846432481707e-45 to 3.40282346638528860e+38, so shouldnt this be able to  handle a solar system of lengths?

I am just curious how to work with or around this potential problem.


The solar system is not big, it's all relative.

Its only big if you need to represent people walking on the earth, the solar system, and then the entire galaxy, and the universe, up to scale.

If you just have planets and a spaceship flying around them, you do not need anything more than what you already have.

What if you did want to walk on the planets?

I am just curious, what is the breaking point for vectors when they start glitching?

Are we talking billions, millions, or even less?

The problem with floating point numbers is not the size of things they can represent.  While they can represent huge or tiny numbers, they cannot combine them very well… A big number added or subtracted from a small one would yield a very inaccurate value, the same as subtracting two numbers of similar magnitude.

So, for instance if you have two ships on very distant places in your world, and then need a vector from one to the other, you will have to do a subtraction of very large numbers and then be likely just noise.

Hope it helps

So, I would take it that if I am going to be working with a large scene, the optimal thing to do would be to keep the player as close to 0,0,0 as possible, even by means of shifting the scene?

Quite simple:

if you use 4000kx4000kx4000k as space on the outher edge the accuracy will be around 1/10meter (assuming the unit is one meter)

There are two ways around this, use spaceblocks, kinda like terranblocks work, or use unrealistic sizes (or use the engine Celestia open source engine, whiel being a programm to show starmaps/picutures it uses as far as I know biginteger classes or similar for caculating… (However there is a really hughe overhead in this, as normal cpus are best with 32bit numbers or 64 in case of a 64 machine)))

wow that is really sad that floats lose precision fast after 7 decimal places. What use are they? This only gives me +/-10,000km to work with that is pretty sad. there has to be a better way to manage this. how can i do big math and put it into vectors without losing precision and accuracy??

i would be happier if i could get my hands on 100,000km of accuracy. as it is some of my planets will be easily 15,000 km across…

i mean saturn is over 100,000 Km across alone!!!

You don't need to have all of the entities stored in the same scale, do you? You should be able to store the planets in one scale, perhaps using 1f = 1000km; and then when you want to go into the unit scale, you zoom in, and the units are stored at a different scale with 1f = 1km, with one 3d-array for each planet. It's a bit difficult to go into much detail with out more information.

Ok so here is my workaround (untested currently) tell me what you guys think (especially if there are any pitfalls)

so how this will work is… (Using phoenix's idea of a space grid)

there would be a grid system for the solar system. when a player is at, for example, (0,1,0) grid, this represents a global position of (0,100,000Km,0) which is applied to a node. attached to that node is the player which when he moves outside of this specific grid square, he is placed into the next one with the difference subtracted from his local location. in this way the main node holds 10^7 and up, while the players node holds the smaller precision (hence never losing accuracy or precision with math for when the math would lose accuracy, it is just applied to the node made to handle the larger math). The only downfall is that the math must be done by grabbing grid location and player local translation.

so, what do you guys think?

Subdivision is your friend here. I divided my universe into square parsecs; within parsecs there are square AU's, within AU's there are square miles, etc.


Prime said:

Subdivision is your friend here. I divided my universe into square parsecs; within parsecs there are square AU's, within AU's there are square miles, etc.


I encountered the same problem trying to create a scene where a ship circumnavigates the Sun, specifically my scene measures 100.000 units (0.08 units as 1 km), the ship glitches.

How can I implement a subdivision of the scene using sectors?  

And there is a way to translate dinamically and programmatically  the xyz zxis origin of the scene?

I mean something like a reset on the world coordinates  :?


inverse problem, I keep fixed the player node and I move only the scene node, all works well without glitching but when I reach big numbers I noticed a limit in my vector addition:

      Vector3f sceneLocation = sceneNode.getLocalTranslation();
      sceneLocation.addLocal(sceneNode.getLocalRotation().getRotationColumn(2, shipDirection).multLocal(speed));

when sceneposition coordinates assume values greats than 10.000.000 unit (or lower even if I didn't find the limit)  AND speed is lower than 0.5 unit, there is no movement at all..  :|  :| please can you help me to find some workaround?

Take a look at terrainblocks, you have to create something like SpaceBlocks then.

Empire Phoenix said:

Take a look at terrainblocks, you have to create something like SpaceBlocks then.

Thanks, with TerrainBlock it sounds like a real challenge, even if I would like to understand how and why this way increases math accuracy :P ...

Mumble mumble.... and what could be the minimal effort to obtain a decent implementation?

Map divided in blocks --> detection of every planetoid residing on player block --> creation and projection of "visible objects" like it was a streaming?

P.S. really I don't figure out  :P neither how to implement a spaceblock neither how can I avoid the problems encountered with my starting implementation, please could you give me some hint or some doc link to follow?  :)   :?

well basially: devide all into small blocks,

set player fixed at 0,0,0 , and load render only the blocks being x away from the player around him,

or store whre player is, render sourrunding bocks, but let player move, and ony when he reches the edge of the center block set him back and replace the loaded blocks.

Easy, well not really…

For all saller stuff not visible from long distance that works, for palnets you would need to create a scaled down version and render that as a skybox behind the rest.

Alternativly use unreallistic sizes, as freelancer, freespace or X-series does.