a way to increase star distance (re-visited)...

Rassilon · Post #1by **Rassilon** » 02.03.2007, 02:51

Tonight I was thinking of how I could make the ultimate contribution to Celestia and I think I might know what it is but I think that since this might be an attempt to ask for an improvement to the latest Celestia I placed my post here...

If I were manually able to increase the 16kly barrier I would in my brief experience with OpenGL come to the conclusion that if I get clipping and positioning errors past a certain distance why not fool the program into thinking those distances havent been reached yet by scaling everything down... That means the star database and all script files... Addons from the past would also have to be scaled... Unfortunately to get more than our own galaxy would mean sacrificing smaller objects since i believe radius and the like are floats with only a precision of 6... Cant remember offhand...

The other option would be to increase all precision calculations to double and shrink internally the rendering scale...

But in any event I think Ill tinker some more and see what I can come up with...

Hungry4info · Post #2by **Hungry4info** » 03.03.2007, 00:20

The 16k light year barrier should definatly be gotten rid of. I would very much like to put a few stars in the LMC for example, or that black hole in the centre of the Milky Way. More precision would be nice too.

Rassilon · Post #3by **Rassilon** » 03.03.2007, 16:03

The problem is also that clipping will happen when your close to small objects... This would be unacceptable... The only way is if the source code is manipulated...

Rassilon · Post #4by **Rassilon** » 14.10.2007, 17:55

Why not add an alternative coordinate system to Celestia that does not conflict with the current?

Today I was thinking again of my old attempts to create an infinite universe and the limitations of current hardware and something dawned on me... In OpenGL alot of times you have to fool the observer to get correct positioning of the camera... The camera should never move or only in increments in the universal coordinate system... This prevented objects from jumping around due to lack of precision... Now this is still limited since the computer can only see 18 digit numbers... Now what if you were to add a coordinate system for each level of display? You could have a planet coordinate system for the surface, solar system coordinate system for the planets, galaxy coordinate system for the solar systems and cosmic coordinate system for the galaxies? With the ability to add even higher levels...

Now the first thing you will think is how will this be displayed since it will all eventually have to convert into one coordinate system by OpenGL... And to avoid clipping and percision issues... Well I have to test the theroy first but I vaugly remember when I was coding the Doctor Who Universe the ability to set up more than one clipping plane so as to get close to smaller objects without them dissapearing... This would mean a several pass render and would be slow on old equipment... But this is how it is done in theroy...

Would this be the fourth dimension? :mrgreen:

I will keep you posted of my results...

MKruer · Post #5by **MKruer** » 14.10.2007, 19:21

The last time this was brought up, I think that the idea was to add additional reference points at the 16k barrier as you approach the 8k limit, the coordinate system would transfer to the closest 16k cell. This would be a superset of existing code. The 16k limit would still be there, but it would just shift.

phoenix · Post #6by **phoenix** » 14.10.2007, 19:26

I thought the 16k limit was not due to any graphical restrictions but because the coordinates are stored as 16 bit integers.

changing this would require more than a little "hack"

Post #7by **dirkpitt** » 15.10.2007, 00:49

Celestia already does multiple passes of rendering, each time with a different perspective transform (clipping planes) to try and avoid the worst depth precision issues.

This seems to work mostly, but not all graphic drivers are hokey-dokey - for example on my Radeon 9700, Cham's x800, and on an old Intel i845 I have access to, dancing holes in orbit paths can be seen. This is most likely due to an obscure clipping problem, and illustrates the difficulty involved with handling depth correctly.

ajtribick · Post #8by **ajtribick** » 16.10.2007, 13:41

phoenix wrote:I thought the 16k limit was not due to any graphical restrictions but because the coordinates are stored as 16 bit integers.

changing this would require more than a little "hack"

No, they aren't stored as 16-bit integers... from what I can tell the coordinates are Point3f types, which as far as I know use single-precision (32 bit) floating point numbers.

The 16kly limit is presumably imposed because of accuracy issues at large distances, rather than the maximum values that the format can represent.

Post #9by **selden** » 16.10.2007, 13:48

Chris posted a description of the causes of this limitation quite some time ago. Please read the thread at http://www.celestiaproject.net/forum/viewtopic.php?p=9424

A link to his description is included in the "Preliminary Users FAQ"

phoenix · Post #10by **phoenix** » 16.10.2007, 21:31

you're right but that posting is quite old.

I found this to be more conclusive and up to date:
http://www.celestiaproject.net/forum/viewtopic ... 4321#64321

maybe I'll give it a try to change the type from float to double just to see how it really affects the overall performance

Rassilon · Post #11by **Rassilon** » 20.10.2007, 23:25

double math is way slower than float...