1.3.1 p6 - UI - Object Info Display

[don]

.
Regarding: The user interface, object information display, in version 1.3.1 pre6 . . . Here are 5 bugs I just found.

Bug #1
* goto Earth
* zoom in to an Altitude of less than 25512 km (4x the object's radius)
* (edited) Note that the object info display shows Altitude in km, which is measured from the surface of the object.

* zoom out to an Altitude of more than 25512 km (4x the object's radius).
* (edited) Note that the object info display now shows Distance, with a value that is measured from the center of the object, instead of from the surface.

Two different titles and two different measurement systems, in the same exact place on the display. Very confusing.


Bug #2
* Open the Go To Object dialog box (Navigation / Goto Object ..."), yes the labels are different (Go To and Goto).
* (edited) Note that it does not reflect these two different measurement titles and systems. Rather, it provides a third one. It contains a text box with a title of Distance (which above means distance to the center), but displays a value for Altitude (which above means distance to the surface)!


Bug #3
To make it even more confusing, beyond 4x the object's radius, the UI object info display shows "Distance" and the Go To Object dialog box shows "Distance", but the two are displaying different values.

When altitude is less than 4x the object's radius, the info display shows Altitude, the dialog box shows Distance, but both values are the same.


Bug #4
Use the following gotoloc command in a .cel script to set the position (Altitude/Distance) to exactly 25512 and the object info display "quivers" between displaying "Altitude <value> km" and "Distance <value> km", so that you cannot see either one.

Code: Select all

select { object "Sol/Earth" }
synchronous {}
gotoloc { time 1.0  position [ 0 0 25512 ] }
wait { duration 1.0 }


Bug #5
Using the gotoloc position code below (on Earth) results in an error code of some kind being reported for Latitude, in Celestia's "Go To Object" dialog box:

Code: Select all

select { object "Sol/Earth" }
synchronous {}
gotoloc { time 1.0  position [ 0 0 0 ] }
wait { duration 1.0 }


* Distance = -6378.0 (center of core)
* Latitude = -1.#IND0 <-- obviously an error code of some sort
* Longitude = 180.00000

[selden]

Don,

I think your "bug #1" and "bug #2" come from a misunderstanding.

Celestia's Distance is measured to the center of the selected object. Celestia's Altitude is calculated as

Code: Select all

Altitude = Distance - Radius

using the Radius value specified in the object's definition in the SSC file.

When you're closer to an object than a certain Distance (4x Radius?) Celestia switches from displaying Distance to displaying Altitude: showing the distance to the nominal surface. When your viewpoint is at the surface of the object, Celestia shows an Altitude of 0.

Note that as you approach the Earth, when the Distance becomes less than about 25500 km, the next Altitude value is about 6378 km less than the previous Distance value: the radius of the Earth has been subtracted. The Earth's surface is 6378 km closer to your viewpoint than the center of the Earth is.

Since Celestia currently seems to be doing the simple calculation I indicate above, it does get the altitudes wrong when you approach the surfaces of non-spherical objects. I have the impression that this could improve in the not too distant future, since most of the appropriate calculations have to be done to place surface location names correctly on irregular object models.

[chris]

It does seem unnecessary to switch from distance to altitude when close to an object. I think that it would be simpler to always use distance and just let it be understood that displayed value is the distance to the surface of the object, not the center. This would eliminate issues 1 through 4. Any good reasons against making this simplification?

As for bug 5 . . . well, Celestia needs to be smarter about avoiding divide-by-zeroes when right at the center of an object.

--Chris

[selden]

Chris,

I think there are times when the user would prefer to be able to have Celestia display an accurate altitude (the actual distance to the closest point on a surface, I mean). While trying to create an altazimuthal display from a planet's surface, for example, or watching how the atmosphere's effects on visibility change with altitude (although Celestia's atmospheric model is currently somewhat limited in this regard).

I do agree that having the display switch automatically between the two measurements can be undesirable. Having it happen when one is trying to determine the accuracy of an asteroid flyby trajectory can cause difficulties.

[chris]

Chris,
I think there are times when the user would prefer to be able to have Celestia display an accurate altitude (the actual distance to the closest point on a surface, I mean). While trying to create an altazimuthal display from a planet's surface, for example, or watching how the atmosphere's effects on visibility change with altitude (although Celestia's atmospheric model is currently somewhat limited in this regard).

My suggestion was that Celestia should always display the altitude. The text would read distance, but that should be read as 'distance to surface' i.e. altitude.

Displaying accurate distances to irregular objects is somewhat problematic. Calculating the distance from a point to an arbitrary mesh of triangles requires computing the distance to each triangle in the mesh and finding the minimum. There are optimizations, but none that don't require either significant preprocessing or iterating over every triangle. The overhead of computing the distance to a complex mesh is significant.

Incidentally, calculating the distance between a point and an ellipsoid requires finding the root of a sextic. That's not really so bad--solving one sextic per frame rendered wouldn't make a difference for even the most modest home PC.

--Chris

[don]

Don,

I think your "bug #1" and "bug #2" come from a misunderstanding.

Geeeeez, been spending so much time on gotoloc today that my brain must have turned to mush <sigh>.

No, there is no misunderstanding. What I wrote is not what I observed, and has now been edit-corrected.

It does seem unnecessary to switch from distance to altitude when close to an object. I think that it would be simpler to always use distance and just let it be understood that displayed value is the distance to the surface of the object, not the center. This would eliminate issues 1 through 4.

I'm all for it! Consistency is the keyword here. I'd use one or the other, or display both at the same time, instead of switching between them. But why would a user want to know the current distance to the center of an object anyway? If they *really* wanted to know, they could simply add the radius of the object to their current Altitude/Distance.

As for bug 5 . . . well, Celestia needs to be smarter about avoiding divide-by-zeroes when right at the center of an object.

Currently, the Celestia camera can actually travel through solid objects to get to the center, but it serves no purpose, does it? This is one reason why I suggested some kind of "collision detection" routine in another topic. Personally, I think the camera should stop at the surface (Altitude/Distance of 0).

[granthutchison]

I very much like the ability to travel to the centre of an object which then becomes invisible. It allows you to observe satellites or primaries throughout an entire rotation/revolution without the horizon interfering, and it eliminates geometrical libration effects.

Grant

[don]

I very much like the ability to travel to the centre of an object which then becomes invisible. It allows you to observe satellites or primaries throughout an entire rotation/revolution without the horizon interfering, and it eliminates geometrical libration effects.

Grant

That's a good reason <smile>.