Double-Precision "Huge Worlds" In Unigine

[phoronix]

Phoronix: Double-Precision "Huge Worlds" In Unigine

Unigine Corp released an OilRush game update before the end of last week, but the developers from their Russian studio continue to be hard at work at improving the core engine itself for them and their clients. The latest revision of the Unigine Engine now supports huge worlds with a double-precision coordinate system...

http://www.phoronix.com/vr.php?view=OTcwNw

[cb88]

Actually I think this is probably just bad design... double precision is massivly slower than single precision however the advantage isn't that great usually the renderer bases its cordinate system around the player or camera so rendering things that are that far away is impractical...

However it might make things like accurately rendering something thought a telescope in a realistic manner ... since it wouldn't have to be mapped in 2 coordinate spaces and then linked together it could just be in the same space.

[mirv]

I think the extra precision has more to do with calculations other than rendering, as in with the base data set - google around a bit and you'll find some of the other folks who have dealt with precision problems (e.g NASA's WorldWind).
As the unigine developer log noted, useful for VR or flight sims, things which require the original data sets to be in double precision.

[elanthis]

Actually I think this is probably just bad design...

For a consumer game? Yes. For an industrial/academic/military simulation? Not at all.

A good "game" engine can handle both. I still know next to nothing about Ungine's architecture since their public documentation is lacking and what's there is poorly written, but this gives reason to believe that they're focusing pretty heavily on serving a wide range of needs. Which means that the engine likely has fantastically good design.

[allquixotic]

The thing to keep in mind is that double-precision coordinates are optional. Each Unigine licensee can choose whether to use SP or DP. And, developers being the smart cookies that they are, you can be pretty sure that they'll make the right choice for their application. It's good to provide the choice, even if most games will never need coordinates on this scale.

[kayosiii]

Actually I think this is probably just bad design... double precision is massivly slower than single precision however the advantage isn't that great usually the renderer bases its cordinate system around the player or camera so rendering things that are that far away is impractical...

However it might make things like accurately rendering something thought a telescope in a realistic manner ... since it wouldn't have to be mapped in 2 coordinate spaces and then linked together it could just be in the same space.

Using double precision is only part of the design and is optional. The world now moves around the camera rather than the other way around This means the player is always in the sweet spot for accurate calculations, objects streamed in and out depending on what is supposed to be visible to the player. Double coordinates represents the limit the total world size.

So far one person has done testing using the Heaven Demo and there was a small decrease in framerate using the double version of the engine Memory usage was higher however.

We haven't gotten around to really testing the new version of the engine. At my work we are very happy to have this feature finally (arch viz).

[ssam]

coordinates in floating point always seems a bit weird to me. It means that you absolute accuracy depends on your location.

suppose that you need millimetre accuracy. with a 32 bit float you get ~7 significant figures. 1 metre from your zero coordinate you have accuracy to better than a micrometre. 10 km from the origin you accuracy drops to 1 mm.
do the same with a 32bit integer and you have the same accuracy throughout your space, so you have 4 billion millimetre divisions, or 4000 km.

64 bits gives you much more space in either system.

i guess floats is much easier to program in, because you can use any units (most sane to use metres). to effectively use ints you need to use you resolution tolerance as the unit. kind you like how when doing money its best to use an int to hold pence/cents rather than a float to hold pounds/euros.

[mirv]

coordinates in floating point always seems a bit weird to me. It means that you absolute accuracy depends on your location.

suppose that you need millimetre accuracy. with a 32 bit float you get ~7 significant figures. 1 metre from your zero coordinate you have accuracy to better than a micrometre. 10 km from the origin you accuracy drops to 1 mm.
do the same with a 32bit integer and you have the same accuracy throughout your space, so you have 4 billion millimetre divisions, or 4000 km.

64 bits gives you much more space in either system.

i guess floats is much easier to program in, because you can use any units (most sane to use metres). to effectively use ints you need to use you resolution tolerance as the unit. kind you like how when doing money its best to use an int to hold pence/cents rather than a float to hold pounds/euros.

I suggest going into some OpenGL programming - you'll see the need for floating point the first time you do a divide. Projection matrices alone using FOV setup will need it for the math. It's just one of those things; integer math won't cut it.
The selection of units is completely arbitrary and dependent upon what you're doing. Chemical compound modelling will have a different scale to star chart viewing for example - and neither one would be based upon metres. It's better to think of them as relative numbering scales for the dimensions that you're working with.
As for integer based numbering by shifting the decimal point, I have seen that being done (I think the original UnrealScript might have done it actually - all "floats" were limited to 4 decimal places, which suggests that's what they did), but on-screen jitter will occur if you use it for absolute co-ordinates of underlying data. Floating point gives you the better precision, and the hardware FPU is fast enough (particularly on GPUs), so there's no reason not to use it.

[ssam]

I suggest going into some OpenGL programming - you'll see the need for floating point the first time you do a divide. Projection matrices alone using FOV setup will need it for the math. It's just one of those things; integer math won't cut it.
The selection of units is completely arbitrary and dependent upon what you're doing. Chemical compound modelling will have a different scale to star chart viewing for example - and neither one would be based upon metres. It's better to think of them as relative numbering scales for the dimensions that you're working with.
As for integer based numbering by shifting the decimal point, I have seen that being done (I think the original UnrealScript might have done it actually - all "floats" were limited to 4 decimal places, which suggests that's what they did), but on-screen jitter will occur if you use it for absolute co-ordinates of underlying data. Floating point gives you the better precision, and the hardware FPU is fast enough (particularly on GPUs), so there's no reason not to use it.

fair enough on most of that. you can't do much if your libraries need floats.

but floating point does not give you better precision everywhere. your precision scales with how far from the origin you are. so if you want a guaranteed absolute accuracy (say 1mm or microm), you will get it for a larger range with the same number of bits of int (4000km vs 10km for 32bit).

for locations in a game you really dont want to have nanometre accuracy at the center of the map, at the expense of meter accuracy out near the edge. where you could have millimetre across the whole space.

for a physics simulation its quite handy that if you work in meters you still have N significant figures at scales from atoms to galaxies (though you might want to work in angstroms or parsecs if thats what your equations are in).

[mirv]

fair enough on most of that. you can't do much if your libraries need floats.

but floating point does not give you better precision everywhere. your precision scales with how far from the origin you are. so if you want a guaranteed absolute accuracy (say 1mm or microm), you will get it for a larger range with the same number of bits of int (4000km vs 10km for 32bit).

for locations in a game you really dont want to have nanometre accuracy at the center of the map, at the expense of meter accuracy out near the edge. where you could have millimetre across the whole space.

for a physics simulation its quite handy that if you work in meters you still have N significant figures at scales from atoms to galaxies (though you might want to work in angstroms or parsecs if thats what your equations are in).

It's the dynamic range of number handling that makes floating point so attractive actually - though yes, there are distance scaling effects to take into account (hence the thread topic of double-precision), it's rare that they're a problem. The most common problem is actually testing for zero.
Problem with fixed-point arithmetic is the discrete nature of the results - what if your physics moves an object sub-millimetre, or sub-metre, or whatever your scaling system is? So you'll need extra fixed point places to handle that. And then some more for object to screen space conversion, and suddenly your range isn't as large as it was before, and if your data set is within floating point tolerance, you may as well use floats anyway.
Interesting point though, OpenGL ES supports fixed-point, or at least used to (I don't use OpenGL ES, so don't keep up to date on it much), precisely because of the lack of FPUs on embedded devices.
I'm not saying floating point is always better - because it's not - but for the majority of cases it does offer greater benefits compared to fixed-point numbering. Best tools for the job, and all that.