Monster asteroid data file

[bruckner]

Hello everybody!

Trying to push the limits of Celestia, I tried to implement a suggestion Fridger gave a while back. My original asteroid add-on only contained orbits for 50 big asteroids... Now, I've polished my Perl skills to produce a ssc file for all 7309 orbits on the IRAS Minor Planet Survey (you can find it on the usual place: http://bruckner.homelinux.net/addons.html). I don't recommend using this file with Celestia, as the framerate drops to unacceptable levels (9 fps on my system, Athlon 900 MHz, 256MB RAM, GeForce 3 64 MB), but I'll use it as a basis to extract trimmed down asteroid data files.

The only data item the file is lacking (setting apart appropriate shape models) is rotation periods. Any suggestions for data sources carrying them? Also I heard somewhere in the forum there were implemented ssc parameters for adding controlled noise to body shapes (that was an old suggestion of mine for future Celestia development). Was it just a dream, or it's true?

Tell me your comments and which criteria would you like to apply to trim down the data for acceptable quality levels (minimum asteroid diameter limit, for example...)

Best regards.

Bruckner

[chris]

That's completely out of hand . . . I love it! :>

I get 11-12fps with a GeForce4 Ti 4600 and an Athlon 1.33GHz . . . Turning on labels drops the frame rate to 7.5fps. That it runs in anything like an interactive rate is really a testament to the power of today's processors and graphics chipsets.

It's spectacular to run at a high resolution with the labels turned on and then zoom around between the orbits of Mars and Jupiter.

The controlled noise for modifying asteroid shapes is still not done, I'm afraid. It'll probably have to wait until 1.2.6, as I think 1.2.5 will be thescripting, UI, and comets release.

--Chris

[Matt McIrvin]

Sounds like an ideal opportunity for hardware braggarts! I wonder how fast this baby can chew on them...

[Matt McIrvin]

With a more or less full-screen window at 1024x768, I only get about 4-5 fps with names turned off, 2-3 with them on. It's still impressive that I even get more than 1 fps.

(It's a dual 1Ghz G4 Mac, with a less-than-avant-garde Radeon 7500. I suspect that, unlike some of the stuff written specifically for modern Macs, Celestia doesn't get much extra bang out of symmetric multiprocessing; the load meter seems to ping-pong sporadically between the two CPUs, maxing out one at a time. When I'm not doing something egregiously silly like this, Celestia usually doesn't even peg the load meters at all. I suppose the video card's doing most of the work.)

It's pretty cool to see all those asteroid names, though. Jupiter's Trojan clouds stand out prominently.

[t00fri]

With a more or less full-screen window at 1024x768, I only get about 4-5 fps with names turned off, 2-3 with them on. It's still impressive that I even get more than 1 fps.

(It's a dual 1Ghz G4 Mac, with a less-than-avant-garde Radeon 7500. I suspect that, unlike some of the stuff written specifically for modern Macs, Celestia doesn't get much extra bang out of symmetric multiprocessing; the load meter seems to ping-pong sporadically between the two CPUs, maxing out one at a time. When I'm not doing something egregiously silly like this, Celestia usually doesn't even peg the load meters at all. I suppose the video card's doing most of the work.)

It's pretty cool to see all those asteroid names, though. Jupiter's Trojan clouds stand out prominently.

I also love those asteroids. I predicted it was going to be fun;-)
With the labels on, it makes an impressive sight.

With my PIII 1Ghz/512MB and GeForce 2 GTS/32MB and 1280x960@16bit I get 5-6 fps with the labels on.

Bye Fridger

[Sum0]

I get a decent framerate on my Athlon 1Ghz. It's mind-boggling... It really shows how huge the universe is that none of the asteroids is in sight of each other!
Also, it's fun to look through the names. Lennon, McCartney, Harrison, Starr, ASCII, TARDIS, Hoshi-no-ie (Hoshi's house)...
Although I can't find my personal favourite, Durrenmatt (or something like that) - my real name being Matt Durrant...

[chris]

Neat . . . there's an asteroid called Celestia!

--Chris

[Paul]

That it runs in anything like an interactive rate is really a testament to the power of today's processors and graphics chipsets.

I think it's also a glowing testament to OpenGL's text-rendering performance...

[Sum0]

Note that this file overrides (is that the right word?) the Hektor contact binary mesh ssc. Hektor's just a rough sphere with this.

[bruckner]

I'll publish shortly* the Perl script I used to generate the file... Right now it allows to extract subsets of the whole asteroid database, just by changing some constants in the source code. I'm adding some documentation to the source...

The available conditions are:
- Maximum body count (useful to get the first 100 asteroids of the database).
- Minimum radius (useful to get all bodies with radius greater than certain magnitude).
- Blacklisted names (to avoid generating definitions for asteroids that might be defined in another ssc file).

I plan to expand the script to allow for other databases. Right now it's perfect for extracting column-formatted data, as it only needs an array of starting bytes on the columns, and some info for data definition (if column 0 is "Name", you tell the script $name = $data[0]).

Greetings!

Bruckner

* by the way, I don't really know what I mean with "shortly". I'm just too busy now

[bruckner]

Sorry about replying to myself, but this is an unrelated matter...

I generated a trimmed-down version of the monster asteroid file with all asteroids greater than 50 km in radius. There were more than 400 of them, but Celestia performed quite well (in fact I didn't notice the difference)... That made me think about two suggestions:

1) What about being able to load different ssc files at run-time? Celestia is indeed able to do that (or it seems so), since travelling to another solar system with the monster asteroid file loaded eliminates all delays (as if it wasn't loaded). This would need a tiny dialog, and it might have two lists, side by side; one with available ssc files and other with currently displayed ssc files, and buttons to move the individual files from one list to the other.

2) It should be possible to have more object classes. When speaking of asteroids, there are plenty of groups: Jupiter trojans, Centaurs, Atens, Amors, Apollos, Kuiper Belt objects... It would be very nice to be able to toggle display of labels and orbits for all those object kinds in a list with toggle marks (the keyboard based interface would not be suited anymore for such a task). Ideally, object classes should be user configurable, either at run time, or just by reading the appropriate ssc label (Class) and adding its contents as the name for a new class of objects, dynamically.

Please tell me what do you think.

Best regards.

Bruckner

[t00fri]

I think the crucial issue is to profile and modify the code appropriately. And that's what I am at right now. What happens with the monster file is far from optimal:

After loading your original 7309 asteroids and displaying the sky from Sol out to Jupiter, say, not a single asteroid is visible (all too weak). Yet, the framerate is only around 5.5 or so! Now let us even be more extreme. Lower the star brightness ([) to the minimum such that only objects with apparent magnitude /smaller/ than 1 are displayed. This means you only see a pitch black sky with /nothing/ in it, except Sol. Still the framerate does not increase much above 6.5...

Bye Fridger

[chris]

Celestia is actually quite efficient at culling objects that aren't visible. The problem is that in order to compute whether or not an object will be visible means that you need to first know where it is, and the calculation of position involves solving Kepler's equation. Doing this for all 7309 asteroids taxes the CPU . . . So the problem is not that the asteroids aren't being culled--it's that the calcuations required for culling are somewhat complex.

The orbital calculation could certainly be made more efficient. An obvious thing to do is to precalculate the orientation of the orbital plane from the inclination, longitude of ascending node, and longitude of pericenter. A more idea is to track objects that weren't visible in the last frame rendered and use their velocities relative to the camera to determine efficiently whether or not they might be visible in the current frame. A single float could be stored with an orbit giving it's maximum speed. This multiplied with the inter-frame time gives the bounding sphere enclosing any possible updated position of the object.

In any case, Intel and AMD would certainly be happy to know that for Celestia users at least, 2 GHz is not enough . . .

--Chris

[t00fri]

Of course, the problem is not trivial and the obvious task is to find a much cheeper filter. The present one in 'Renderer::renderPlanetarySystem' is very expensive as you mention:

if (discSize > 1 || appMag < faintestPlanetMag)
{

"enter object into renderList"

}

Both the discSize and the appMag calculation means calculating at each tick of the simulation the positions of the observer and of the 7309 asteroids relative to the sun. The present calculation is far more expensive than the actual rendering of each object, which is the reason why the framerate is about insensitive to whether the 7309 asteroids are rendered or not...

But the asteroids, for example, have a number of special features
(including e.g. their small size and their location (the belt
structure)) that might be exploited. For the /filter/, we only need a rather qualitative type of information and the present high accuracy is sort of an 'overkill';-). I am quite optimistic that a significant
improvement is still possible. We shall see...In any case this asteroid file represents quite a generic challenge as to the possibilities for
future incorporation of further large sets of objects.

Bye Fridger

[mechano]

Chris!!! I've found a surprise for you: There is a little asteorid what is named as Laurel ... You can find it in the asteorid_IMPS.ssc file ... so your name is immortal

[Guest]

Of course, the problem is not trivial and the obvious task is to find a much cheeper filter.

A very crude heuristic, less sophisticated than Chris's ideas, would be to put bounds on the position (and, by extension, the apparent magnitude) based on a box surrounding the whole orbit. This wouldn't help much for viewers in the inner solar system, but it would at least help once you got out past Jupiter.

[Matt McIrvin]

To do better than that: Divide the ecliptic plane into (four? eight?) wedges and precompute passage times for wedge boundaries. Since these things are just Keplerian ellipses it's all periodic from there. Then at any given time you've got the asteroid boxed in a relatively small region, surrounding the part of the orbit within a given wedge. Of course all this takes more code...

[Potatoman]

Or use time based coherence:
if (not visible and far way) next update frame= current frame + 4

[Guest]

Celestia is actually quite efficient at culling objects that aren't visible. The problem is that in order to compute whether or not an object will be visible means that you need to first know where it is, and the calculation of position involves solving Kepler's equation. Doing this for all 7309 asteroids taxes the CPU . . . So the problem is not that the asteroids aren't being culled--it's that the calcuations required for culling are somewhat complex.

My ongoing experiments with making the culling much more efficient look very encouraging. The framerate with the 7309 asteroids has already risen by about a factor 3 generically and this is certainly not yet the end.

The crucial issue in my present method to cull the objects to be entered in the renderList is to /avoid the expensive solution of Kepler's equation/ in the majority of the cases. Moreover the method is supposed to be applicable for /any/ kind of objects not just asteroids.

Consider 2 subsequent frames at times t and t+dt. My filter exploits that for the majority of objects the /change/ of the observer's /angle of view/ from looking at the object at time t and at its new position at t+dt, remains very small. For very many objects, this allows to replace the object's new position at t+dt relative to the observer by a very simple (cheep) estimate which is sufficient for quickly approximating appMag and discSize that decide about who is "in" and who is "out". For the "in" objects I then use the /exact/ Kepler equations to fill the required entries in the renderList.
That number is usually small compared to the total number of objects.

Bye Fridger

[t00fri]

Celestia is actually quite efficient at culling objects that aren't visible. The problem is that in order to compute whether or not an object will be visible means that you need to first know where it is, and the calculation of position involves solving Kepler's equation. Doing this for all 7309 asteroids taxes the CPU . . . So the problem is not that the asteroids aren't being culled--it's that the calcuations required for culling are somewhat complex.

My ongoing experiments with making the culling much more efficient look very encouraging. The framerate with the 7309 asteroids has already risen by about a
factor of 3 generically and this is certainly not yet the end.

The crucial issue in my present method to cull the objects to be entered in the renderList is to /avoid the expensive solution of Kepler's equation/ in the majority of the cases. Moreover the method is supposed to be applicable for /any/ kind of objects not just asteroids.

Consider 2 subsequent frames at times t and t+dt. My filter exploits that for the
majority of objects the /change/ of the observer's /angle of view/ from looking at the object at time t and at its new position at t+dt, remains very small. For very many
objects, this allows to replace the object's new position at t+dt relative to the observer
by a very simple (cheep) estimate which is sufficient for quickly approximating /appMag/ and /discSize/ that decide about who is "in" and who is "out". For the "in"
objects I then use the /exact/ Kepler equations to fill the required entries in the
renderList. That number is usually small compared to the total
number of objects.

Bye Fridger