16,000 light year limit with 128 bit integers

[GlobeMaker]

Celestia Coordinate Calculation Attempts Using 128 Bit Integers
Written by a GlobeMaker, not a developer, November 30, 2005
Boulder Creek, California, USA

Goal
Calculate the possible size of the Celestia Universe when a 128 bit integer defines a coordinate in one dimension.

Assumption
Assume that the smallest location coordinate increment is 10 nanometers. This feature size was estimated during a past experiment observing a .3ds molecule in Celestia. The simulated molecule had a 10nm radius. The jittering of its position appeared to be over a distance of 10nm to 1000 nanometers. The cause of this jitter is believed to be due to the quantization of the position coordinates. This implies that the least significant bit is changing to represent two adjacent positions. This 10nm feature size assumption can be changed to a different size, someday.

Find how many meters in a light year.
c = 3 x 10^8 meters per sec
n = Number of seconds per year 365*24*60*60 = 3.2 x 10^7 sec/year
1 light year in meters = c x n = 3 x 3.2 x 10 ^ ( 8+7) = 10^16 meters per light year
so 1 light year is 10 trillion kilometers.
This result matches values I have memorized in the past.

The Celestia 16,000 light year limit calculation.

Why is there a 16,000 light year limit in Celestia for star positions?
The radius is 16,000, the Diameter is 32,000 light years
How many bits are needed to represent 32,000 light years, using a 10 nanometer feature size?
Maybe the numeric representation is not in simple binary. Maybe it is binary coded decimal integers (BCD).

Goal
Find how many bits of BCD encoded integers are needed for 16,000 light year radius

Each decimal digit uses 4 bits.
A unit length is assumed to be 10nm.
The maximum count M of unit lengths will be
32,000 light years / 10 nanometers = M
M = (3.2 x 10 ^ 4 light years) x ( 10^16 meters per light year ) / ( 10 ^ -8 meters )
M = 3.2 x 10 ^28 (no units)

This count needs 29 digits, each digit is 4 bits.
4bits per digit x 29 digits = 116 bits
116 bits in BCD.
This is close to the 128 bits used to meet the goal of 16,000 light years radius.

If a simple binary encoding were used instead of BCD, the 16,000 light year limit would be increased to 340 trillion lightyears.

[Malenfant]

Well first you're assuming that going down to 10 nm resolution is necessary in Celestia. I strongly doubt that any of the developers feel that this is the case - as I said elsewhere, if you want to view atoms and molecules, use some other molecule viewing software. I'd say the smallest practical scale in Celestia is probably going to be the metre-scale.

If 1 metre is the smallest practical scale then your M will be 3.2e20, your count would need 21 digits, which would be 84 bits per BCD. You'd be saving 32 bits per BCD there by ignoring distances that are too small to be relevant to Celestia.

That said, I'm not sure I really understand what you're getting at with this post - I'm guessing you're suggesting that some other numerical storage method should be used to determine locations in Celestia to increase the 16k ly limit?

[chris]

The 16,000 light year limitation has nothing to do with Celestia's 128-bit fixed point integers. Star positions are stored as 32-bit single precision floating point values. Using 128-bit numbers would bloat the size of the star database and more importantly, kill Celestia's performance. 64-bit double precision arithmetic is a more reasonable alternative, since CPUs have direct support for double precision floating point arithmetic. However, it would still slow Celestia down to move from single to double precision positions for stars. To be honest, I haven't actually investigated how serious the performance impact would be--my guess is that it would be significant, especially with a large star database.

--Chris

[GlobeMaker]

Hi Chris,

In another forum about star coordinates you said,

"Orientations are recorded as floating point numbers, but positions are not. Neither of the standard IEEE 754 floating point types--32-bit single precision and 64-bit double precision--are sufficient to represent positions throughout the universe to the precision required by Celestia. Instead, Celestia uses it's own 128-bit fixed point numbers for coordinates. In a cel:// URL, the bits appear in the standard base64 encoding where the characters A-Z are digits 0-25, a-f are digits 26-51, 0-9 are digits 52-61, + is 62, and / is 63".

That is why I started this discussion of 128 bit fixed point numbers. Maybe I have misunderstood your meaning. If there are trade secrets you do not want to spell out, then no problem. (Like whether the unit length is 1 micrometer for minimal position changes of objects).

The purpose of this discussion was to have knowledgeable people describe the relationship of the numeric representation type and the 16,000 light year limit for stars' positions. I am not a developer. I am not well informed. But I can multiply large numbers.

Thank you, Chris for your well-informed response. And let me take this opportunity to heap praises upon you for your magnificent achievement : Celestia!

[Rassilon]

The problem lies in the engine. Celestia relies on a central point of reference. When the engine reads from stars.dat and all the ssc files it plots the position relitive to sol...or earth as the case may be. So the further out the star the increased precision error you will have, thus the jittering effect.

switching to double precision will increase the radius of the star boundry possibly past our galaxy and to andromeda...maybe but all in all would still restrict you to a zone in the universe thats rather small and present still the same dilemma.

There is a solution to the problem. That is whenever the camera or observer is positioned that coordinate is always zero. Objects at a far distance seem less likely to present the jitter than when they are up close. The jitter still happens but the eye is unable to precieve this due to the fact its at a relitively far distance from the camera. This presents a new problem however. you will have to move all other objects other than the camera. This will also slow down Celestia. However if this movement is done in increments of say 1 million units, the update would cause a slight pause almost unnoticed by the user. you would at some point still have a moving camera bound to a moving area of 1 million units or more. Once this area is passed the engine moves all objects and resets the camera to zero.

Ive had pretty good success with this, and have rendered an infinate amount of stars and planets using random numbers and perlin noise. Once I have a demo ready to show it will give you an idea of how it works.

[MKruer]

Rassilon

Can I know the status of your implementation? I would like to start working on Sagittarius A* but right now I have had to resort to cheating by placing it close to Sol.

Code: Select all

Barycenter "Galactic Core"
{
   RA 17.75
   Dec -28.93
   Distance 28000
   Axis [ 0.866 0.491 0.091 ]


}


http://chview.nova.org/solcom/x-objects/s2.htm

[Rassilon]

Rassilon

Can I know the status of your implementation? I would like to start working on Sagittarius A* but right now I have had to resort to cheating by placing it close to Sol.

Code: Select all

Barycenter "Galactic Core"
{
   RA 17.75
   Dec -28.93
   Distance 28000
   Axis [ 0.866 0.491 0.091 ]


}


http://chview.nova.org/solcom/x-objects/s2.htm

I probably should have clarified what the demo entailed...Right now I have no way of compiling Celestia so the demo would be stand alone example of this possibility...I am thinking that it might be possible to either use Dev C++ or build my own GUI to wrap around the .Net toolkit...The latter seems more attractive since it will be geared to compile Celestia simple...