## Units, coordinates and scales

About the actual programming of the game.

### Re: Units, coordinates and scales

catageek wrote:Minecraft coordinates are double values, and minecraft does not have y coordinates, only (x, z). Secondly, it is roughly voxelized in blocks for the world model. We can't compare.
Exactly! We have the advantage over Minecraft, that we're using true polygons, not polygon renderings of a bunch of cuboids. We can render 10 times more features at once than minecraft will ever be able to. Also, other voxel projects have shown us that there are none problems at all with implementing practically infinite height voxel worlds.

Pseudonym wrote:Most GPUs don't support 128-bit numbers, either integer or floating-point.
Finally a real issue! I honestly hadn't thought about this one... Perhaps we could let the GPU handle an octet of the world at once, ot modulate the 128-bit integers in some way?

$\dpi{120} \large (2^{128}-1)\mod2^{64} = 2^{64}-1$

So we could feed the GPU with the last 64 bits of the coordinate integers, and use the first 64 ones as a form of secondary coordinate system, like minecraft chunks. That would be the same as using two integers per axis... which minecraft already does in the form of doubles... so no problems here?

Posts: 95
Joined: Fri Nov 01, 2013 8:31 pm

### Re: Units, coordinates and scales

Positions are sent to the gpu in floats relative to the position of the camera. Iirc gpus handle floats better than integers.
croxis

Posts: 282
Joined: Tue Aug 13, 2013 1:37 am

### Re: Units, coordinates and scales

croxis wrote:Positions are sent to the gpu in floats relative to the position of the camera. Iirc gpus handle floats better than integers.

The official CUDA programming manual explicitly says that integer artihmetic has just as good performance as floating point arithmetic. http://docs.nvidia.com/cuda/cuda-c-prog ... structions

Also, OpenGL has built-in native functions for working with integer coordinate systems insteqad of the usual floating-point ones. http://msdn.microsoft.com/en-us/library/windows/desktop/dd374180(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/dd373965(v=vs.85).aspx

Posts: 95
Joined: Fri Nov 01, 2013 8:31 pm

### Re: Units, coordinates and scales

croxis wrote:Positions are sent to the gpu in floats relative to the position of the camera. Iirc gpus handle floats better than integers.

This is almost true, but not in the way you might think. There are GPUs in common use today which require multiple instructions to handle 64-bit floats. (I'm not sure why; I think it might have to do with the widths of internal data paths.)

VladVP wrote:Also, OpenGL has built-in native functions for working with integer coordinate systems insteqad of the usual floating-point ones. http://msdn.microsoft.com/en-us/library/windows/desktop/dd374180(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/dd373965(v=vs.85).aspx

You will note that they are all 32-bit integers. OpenCL has support for 64-bit integers, but GLSL doesn't as of 4.2, and I don't believe that anything has changed in this regard as of 4.4.

I want to reiterate my position that I think 128 bit numbers are a solution in search of a problem. We don't need a single number that measures a galaxy to the resolution of a millimetre.
Pseudonym

Posts: 129
Joined: Tue Aug 13, 2013 3:54 am

### Re: Units, coordinates and scales

Pseudonym wrote:I want to reiterate my position that I think 128 bit numbers are a solution in search of a problem. We don't need a single number that measures a galaxy to the resolution of a millimetre.

I would have to agree with this. We don't need more than a few hundred (and no more than a thousand) light-years regardless of what's going on at any degree of precision. Even if you built a 3D array of blocks this size, you could cover our galaxy in no time flat. If someone aftermarket wants to do that, fine.

For the "core" version, there will be a limit of 256ly. That's a huge cube 256LY on a side. That's big enough for most everyone to be *years* digging through all the possible content, and if they want to be alone, armed, and dangerous, there's lots of places to go lurking. It's also small enough to be at least mostly manageable in terms of resources. 256LY as an effective maximum can be accomplished in less than 32 bits, and that's something all the hardware can handle without a huge problem.
DarkSpartan

Posts: 100
Joined: Mon Aug 12, 2013 10:45 pm

### Re: Units, coordinates and scales

How exactly is the data stored? Because 256 = 2^8, so if we use 32-bits totally, then we would would use 24 bits on everything inbetween each lightyear-mark.
Code: Select all
9460730472580800 metres / (2^24 - 1) = 563903513 metres

I don't know if you accidentally miscalculated something, but it would kind of kill the gameplay if a ship moved 5 million kilometres at once.

Posts: 95
Joined: Fri Nov 01, 2013 8:31 pm

### Re: Units, coordinates and scales

I applaud Pseudonym on his much more professional response.
croxis

Posts: 282
Joined: Tue Aug 13, 2013 1:37 am

### Re: Units, coordinates and scales

VladVP wrote:How exactly is the data stored?

Hierarchically. That's what the "graph" part of "scene graph" means.
Pseudonym

Posts: 129
Joined: Tue Aug 13, 2013 3:54 am

### Re: Units, coordinates and scales

Ok,
i think VladVP is right, there is a big Pile.

1. The whole 128 Bit Coordinates are there to get the Position of an Object in Space.
With 128 Bit there is no need of Overflow Check.
Operations on 128 Bit are Extreme fast.
The slow part on Coordinate Operation will be the Memory Transfer. And the Memory transfer works with 64 Byte! (DDR3 RAM).

2. For objects in the Ship there is only a need of a relative Position.
a 32 Bit Int will be enough vor relative Positions (~ 4,2 Km)

3. The Polygonpositions transfered to the Graphic are relative Positions from the coordinate of the viewer.
those coordinates are with a 32Bit Float precise enough.

4. µm Precision for Simulating to minimize glitches
simple float precision for Graphics to draw

5.
So we could feed the GPU with the last 64 bits of the coordinate integers, and use the first 64 ones as a form of secondary coordinate system, like minecraft chunks. That would be the same as using two integers per axis... which minecraft already does in the form of doubles... so no problems here?

this is a bad idea, because we have to deal with a very complexe Coordinate system. 128 bit <vs> [64 Chunk][64 Offset]
a 128 bit can be used as a simple Integer where all Coordinate relevant Operations (Add and Sub) are VERY fast.
Even multiplication can be done in a few Machnie Cycles.
(Just Dividing would be horrible)
even GPU's can (with the right Code) work on 128 Bit Very fast.

6.
Use GPU as a CoProzessor is a quite bad Idea,
The Simulation engine is very complex and the shaders of a GPU are usualy quite small.
some parts can be implemented very good for GPU's, but then you have to think of the Overhead for Copy the results back and forth.
And especially Servers don't usually have good GPU's

7.
Excuse me, but have you ever heard of MMX and SSE?

SSE has 128 Bit but that's just the register size. Internal it works with 2x 64 Bit or 4x 32Bit.
MMX is deprecated. It was for Multimedia Operations (like saturated MAC or saturated ADD).
and works with 64 Bit. Today every CPU works with 64 Bit. (even smartphones will in 2 or 3 years have 64 bit CPU's)

8.spherical coordinates

spherical coordinates use COS,SIN andy maybe TAN.
for that you have to use the FPU.
No SSE
No MMX
but lame old FPU
and besides that, it would be the worst Nightmare to code.

edit:
9.
Use 80 or 96 bit Coordinates
As mentioned before,
we would safe in the best case at total ~720 Kbyte for 40.000 Objects(which is nothing)
in worst case (and i think the case that is happening) we would save nothing
but in every case we would add a lot of Code Complexity and maybe decrease Performance with 2 non uniform integers.
chaoscode

Posts: 14
Joined: Wed Oct 09, 2013 3:02 pm

### Re: Units, coordinates and scales

So you suggest that we should basically just do all the heavy calculations on the CPU, and merely let the GPU render the stuff? You also have to remember that not all CPUs are 3.7 GHz beasts.