Units, coordinates and scales

About the actual programming of the game.

Units, coordinates and scales

Postby catageek » Fri Oct 25, 2013 1:49 pm

considering that all objects must have a position in the world, and that this position should be accurate at 1 millimeter (this is an hypothesis), here are some facts:

- float numbers have 7 digits in significand, meaning that a position with an accuracy of 1 mm can not be greater than 10^4 m (= 10 km)
- double numbers have 16 digits in significand, meaning that a position with an accuracy of 1 mm can not be greater than 10^13 m ( ~ solar system size)

Using only 3 values to give a position may be too short because we want a universe, not a solar system. it means that we must shift to a 2 level coordinate system in order to create a bigger world : (double / float) or (double / double).

Questions are:
- Is 1 millimeter a good choice for the smaller unit ?
- Do we really need a world greater than the solar system ?
- What would be the best coordinate structure that would fit our needs ?
catageek
 
Posts: 39
Joined: Tue Oct 15, 2013 2:23 pm

Re: Units, coordinates and scales

Postby adam » Fri Oct 25, 2013 3:32 pm

I'd say a cn would be enough. Also I believe we are going to use relative spaces. Imagine a bubble in space that your position is relative to. Now when you reach the edge of that bubble you change to the next relative space and get a new position relative to the center of that bubble.
adam
 
Posts: 113
Joined: Tue Aug 20, 2013 11:58 am

Re: Units, coordinates and scales

Postby Eximius » Tue Oct 29, 2013 6:04 am

cm should be enough. More than enough, really. Say you want to dock with a station or avoid an asteroid.... If you can calculate that in real-time on a crappy 16-bit computer (or whatever CPU we end up providing) within even like a foot's accuracy, I say that should be enough. lol So a cm? mm? that's just crazy precision.
Eximius
 
Posts: 266
Joined: Mon Aug 12, 2013 9:33 pm

Re: Units, coordinates and scales

Postby Zardoz » Tue Oct 29, 2013 6:52 am

adam wrote:I'd say a cn would be enough. Also I believe we are going to use relative spaces. Imagine a bubble in space that your position is relative to. Now when you reach the edge of that bubble you change to the next relative space and get a new position relative to the center of that bubble.


Sectors. Inside of each sector a double 3d vector should have enough precision to handle the coordinates of all inside.
Yep, I have a blog : http://zardoz.es
Emulator DCPU-16 VM
User avatar
Zardoz
 
Posts: 359
Joined: Mon Aug 12, 2013 8:54 pm
Location: Spain

Re: Units, coordinates and scales

Postby catageek » Tue Oct 29, 2013 10:27 am

so:
- main unit will be the meter
- smallest division of the unit will be the centimer
- all absolute coordinates will be stored in double format.

The internal coordinates range will be -1x10^13<= n < 1x10^13 in each dimension to maintain centimer precision.

A subdivision of the coordinate range should be set in place to represent coordinates in a user-friendly format, such as region a,b,c, sector d, e, f, position x, y, z where:
- region a, b, c will be 4 digits integer
- sector d, e, f will be 4 digits integer
- position x,y,z will be 5 digits + 2 digits after comma each and stored in 32-bit float.

Sigma should switch to double type in all its component, instead of float.

I am currently writing a math library that will provide functions to transform coordinates from model to view or screen, or screen to view or model, for example to know what is the projected box behind a pixel on the screen, if the player points his mouse somewhere. It can be used as input for collision detection in the model to find the entity pointed. It can also compute alternate coordinates relative to anything such as the player himself (to use as a tracker on any object) or another object (such as the center of a planet to express spherical coordinates), or cartesian coordinates relative to a fixed point.
catageek
 
Posts: 39
Joined: Tue Oct 15, 2013 2:23 pm

Re: Units, coordinates and scales

Postby adam » Tue Oct 29, 2013 2:46 pm

Sounds perfect.
adam
 
Posts: 113
Joined: Tue Aug 20, 2013 11:58 am

Re: Units, coordinates and scales

Postby croxis » Tue Oct 29, 2013 5:02 pm

Comp Sci question for my own education: I've read in some games integers values are used instead of floating point values if there is a minimum atomic value. What are the advantages to using integers instead of floating point in those situations?
croxis
 
Posts: 282
Joined: Tue Aug 13, 2013 1:37 am

Re: Units, coordinates and scales

Postby Tipaa » Tue Oct 29, 2013 6:04 pm

The advantages to using integers are that no matter where you are on the number line, you always have the same level of precision. Whether I am at 0 or at INT_MAX units away, I will always be exactly 1 unit away from the positions either side of me (namely INT_MAX-1 or overflowing to 0). With (here, 64 bit) floats, at location 0 my left and right positions are something like 2^-53 units away from each other, while at 2^53 units, I have eaten into my precision to that I can't be less than another entire unit away if I go right, while going left I can still travel half units.

Integers guarantee precision that doesn't vary depending on where you sit. Position is stored in the number, and precision is constantly 1. Floating point allows much more accuracy within reasonable bounds, but the further you are from zero, the less precision you have. To increase precision you must decrease position, and vice versa.

On the topic of minimum coordinate precision, I'd say that a centimetre is too big to have as the base unit. Although in terms of (D/R/whatever is chosen)CPU and Gravity calculations no more accuracy is needed than about a decimetre, for the base entity coordinates I would recommend going smaller, since this will also affect rendering, not just clunky 16-bit programs or rough physical approximations. 1cm intervals are noticeable to the player, as they create a very rough effect on rendering to the player if they move in 1cm intervals. Although the player speed may be 150 cm/s, inbetween ticks the render engine will have to interpolate position, and interpolating to 1cm is horribly noticeable and jumpy. This will also show up whenever a player walks at a nearly-axial direction, since the motion will be (cos theta, sin theta) or (sin theta, cos theta) depending on the coord system. This gives one dimension that is at nearly full speed, and one that is at very low speed. This low speed dimension will show the snap-to effect very clearly, creating nasty visual artifacts. Also, at this range, the velocity and momentum calculations become discrete rather than continuous in nature, since there is no opportunity to go smaller than the large minimum dimension. This would require the engine to choose the closest legal point to the actual value. creating an almost voxel-like entity positioning restriction. To find speed, you need to square your velocities together, for instance - this will increase the error in position, and decrease precision. So although the base unit size for the hidden-to-the-player stuff could more easily be made 1cm, the calculations involved with this can make the errors involved increase very quickly, which is why having a much lower initial error is preferable to += 5mm.

In place of 64-bit floating points (double) for positions within a 10^14 space, I would recommend that either a 64-bit fixed point number is used, or that a 128-bit float (quad/long double) is used. The fixed point would offer a guaranteed precision over the entire range (similar to how integers do), while still being able to go to the limits of the system on full precision and back. This precision would also be enough that rendering artifacts would not arise, as for a fixed-point of [12 significand, 51 exponent] would offer a range of 2.2x10^14 with a constant precision of 0.00024, which is better than 0.01. The fixed point has a few drawbacks, such as requiring a bit of extra engineering to work, but it will eliminate the issues that arise by limiting entity positions to a 1x1cm grid (which is a key issue in a first-person game). The floating point of 128 bits would be easier to engineer, but it depends upon compiler support for it, since VC++ doesn't seem to like long double, and gcc and clang have specific switches and types for it.
Tipaa
 
Posts: 6
Joined: Sun Aug 18, 2013 12:04 am

Re: Units, coordinates and scales

Postby adam » Tue Oct 29, 2013 11:25 pm

Using ints has an issue though. If you have 1int be lets say 1mm, you are limiting the largest distance you can go to max_int/1000 meters.

So doing the math that is 4294967 meters. So we have 7 digits of precision. float gives us 7 as well as 3 after the decimal by we can go to 9999999.999 meters. ints this is 4294967295 millimeters.
adam
 
Posts: 113
Joined: Tue Aug 20, 2013 11:58 am

Re: Units, coordinates and scales

Postby catageek » Wed Oct 30, 2013 4:51 am

adam wrote:So doing the math that is 4294967 meters. So we have 7 digits of precision. float gives us 7 as well as 3 after the decimal by we can go to 9999999.999 meters. ints this is 4294967295 millimeters.


32-bit float have 7digits of precision, not 10, so for float you will get 9999.999.
catageek
 
Posts: 39
Joined: Tue Oct 15, 2013 2:23 pm

Next

Return to Code

Who is online

Users browsing this forum: No registered users and 2 guests

cron