This question may or may not be answerable by anyone but chris but I was wondering if this happened in celestia in the early days of development...I know that you find the radius of a sphere to do simple bounding sphere collision...using x^2+y^2+z^2^1/2 but lets just say that is isnt accurate in this scenerio....Would float or double precision play a role in this using the observer and the center of the sphere as the 2 units to find this distance? I currently use double....
To make a long story short I fly into a planet like I would celestia and in some places I read I am 100 km from the surface and am passing into the planet and in other places I am 1 km from the surface and am obviously far away....which leads me to believe the center of the sphere is not accurately being plotted....It must change drastically from one side of the sphere to the next....which leads me to believe its a problem with precision.....
In the program I am doing this all in I plot the observer always to be 0,0,0...I set up a global world coordinate as my location in space (the camera never moves) and move everything around me by subtracting world coordinates from the objects true coordinates....I do not see a jittering effect which happens when you loose precision (like when you use float) Not even up close....so my absolute question here is would anyone know what would cause this innacuracy other than precision?
If it is precision then what does celestia do to accurately plot the distance from the observer to the planet?
SPhere collision detection....
SPhere collision detection....
I'm trying to teach the cavemen how to play scrabble, its uphill work. The only word they know is Uhh and they dont know how to spell it!
That sort of variation would be uniform...At the high points I would pass through the model....My situation is at one side I pass through and on the opposite side I come almost close to it as some offset is present....
Although your thought did bring up another possible situation...The model when transferred from ms3d...the format I use to opengl could have some variation causing this effect OR I could have misplotted the model originally in the 3d program before export....
I sort of remember placing it at 0,0,0 but Ill double check....
I am however still wondering how Celestia calculates the RAW distance from observer to mesh center....
Although your thought did bring up another possible situation...The model when transferred from ms3d...the format I use to opengl could have some variation causing this effect OR I could have misplotted the model originally in the 3d program before export....
I sort of remember placing it at 0,0,0 but Ill double check....
I am however still wondering how Celestia calculates the RAW distance from observer to mesh center....
I'm trying to teach the cavemen how to play scrabble, its uphill work. The only word they know is Uhh and they dont know how to spell it!
Well I ran all the tests...precision, plotting and even used different rendering code for my spheres namely celestia's sphere mesh....exactly the same scenerio....one side Im -80km is near the other side +80km im near....The distance math is right the plotting is at 0,0,0...It has to be the crappy m$ math processing...and probably why no one uses bounding spheres because they ARENT accurate....so again I probably need to know how celestia calculates distances from meshes....When I land on a planet in Celestia no matter where I am its always the same distance....
So what is the formula?
So what is the formula?
I'm trying to teach the cavemen how to play scrabble, its uphill work. The only word they know is Uhh and they dont know how to spell it!
btw I figure Id mention I found the problem was indeed precision....and I fixed this by swiching the observer to move at close distances to any object keeping objects stationary...and at far distances the observer will remain fixed while all objects move around it.....
Also for those who werent aware of why this was a problem is because all numbers are stored as hex or binary obviously in a 8, 16, 32 or 64 (rare) bit register....double numbers are the same as long numbers except the first few bits are used for sign value and precision...in essence a long number will ave one place more than a double due to the fact one bit is required for the decimal....With double numbers you also will have a total of 18 bits that inhabit 0-9 in binary or hex....so if you have a number like 0.000001 and add say 1000000000000 you will get 1000000000000....
Maybe some day I will try to come up with a way to produce numbers of higher precision with the use of buffers...Until now this is the only workaround I know....fool the observer into thinking nothing has changed....
Also for those who werent aware of why this was a problem is because all numbers are stored as hex or binary obviously in a 8, 16, 32 or 64 (rare) bit register....double numbers are the same as long numbers except the first few bits are used for sign value and precision...in essence a long number will ave one place more than a double due to the fact one bit is required for the decimal....With double numbers you also will have a total of 18 bits that inhabit 0-9 in binary or hex....so if you have a number like 0.000001 and add say 1000000000000 you will get 1000000000000....
Maybe some day I will try to come up with a way to produce numbers of higher precision with the use of buffers...Until now this is the only workaround I know....fool the observer into thinking nothing has changed....
I'm trying to teach the cavemen how to play scrabble, its uphill work. The only word they know is Uhh and they dont know how to spell it!