Huge world size

Started by
27 comments, last by RichardS 19 years, 1 month ago
Hi all, I currently use floats for my WorldPosn class, but have realised that I need a much larger world than I have now (probably want upwards of ~500k a side) and floats have nasty lumpy properties at these sort of distances from the origin :( Has anyone here implemented a huge size world in their engine, and what was your approach? I'm currently attempting a fixed-point approach using int64's, which is giving me headaches. I thought possibly using doubles, but this would be similar changes but without the predictable precision of the int approach..?
Advertisement
You could use int or int64 for positions, which is better than float or double as they are uniformly distributed. You probably want to know the position of anything with the same accuracy regardless of where it is.

For all kinds of calculations you could first transform all needed positions into local coordinates (origin at object x), calculate the result using floats and transform them back into (int or int64) global coordinates. No need for fixed-point arithmetic.
Check out the article "the continious world of dungeon seige".
Why not simply divide your world up into sectors and have distance measured relative to the current sector's origin.
[size="1"] [size="4"]:: SHMUP-DEV ::
@Motorherp: It's the word 'simply' that puts me off ;) There's a section in GPG4 describing this approach, and it looks horrendously complex, especially when e.g. measuring distances across sectors?

@Puppet: Yer... seems to be using a sector (node) and offset approach from what I can gather?

Quote:Original post by Trap
For all kinds of calculations you could first transform all needed positions into local coordinates (origin at object x), calculate the result using floats and transform them back into (int or int64) global coordinates. No need for fixed-point arithmetic.


I'm trying an int64 approach now, but as my float units are ~ 1.0 = 1 foot, how would I avoid the fixed point bit? I have an fp multiplier of 1024, giving about 0.29mm accuracy according to my calcs.

It all falls down a bit when for instance I want to draw the whole world map!
Lets fill in some numbers: Earth is around 40,000 km in circumference. Using a int64 to store the location gives you around 0.001 nm per value. I think thats a bit to accurate.
Using a 32-bit int gives you one point each 1 cm. Which should be good enough for most purposes.

Using floats only makes a difference if you zoom in very far. If you use floats in locale coordinates for every object the error will be very small, way smaller than 1mm. If you use floats in global coordinates the error can be huge, at least 1 m. But that doesn't make any differece if you draw the whole world.
Well, some of the movement constants for my vehicles are down to very small fractions. For instance the acceleration on my large vehicles is 0.00006 ft per ms. Admittedly my physics ticks are set to 20 ms, but any smaller and I'd get quantisation or truncation to zero? In fact looking at this I may need to increase my 1024 FP multiplier!
You only need ints for positions, anything else can be floats.
Hmmm I must be approaching this the wrong way then.
How would you apply acceleration to a vehicle (and hence change its position)?
doubles would be good enough too. They essentially are 53 bit integers, while floats are only 24 bit integers. The remaining bits are used for automatic scaling which is of no use in storing absolute positions.

If your world is small enough that worldsize/(2^32) is tiny in comparison to anything you calculate you can use int for position like this:
//Euler
float a = stuff()
float v = v + a*dt;
int pos = pos + (int)(v*dt);

For drawing you would use locale coordinates of the camera. float drawpos = (float)(pos-camerapos);
For doubles it would be the same thing. You need to send locale coordinates to the graphics hardware. Else the additional precision will be thrown away before rendering.

I don't know if doubles or ints are faster if used this way.

This topic is closed to new replies.

Advertisement