bdm,
I am curious what the spread sheet actually creates and
what is new as compared to what we have since ~3 years:
I looked up in my data base the /complete professional/
asteroid data catalog:
ftp://ftp.lowell.edu/pub/elgb/astorb.dat.gz
These are the data of about
1950 asteroids brighter than
app. mag. 13 and
109000 (!) dimmer than
app.mag. 13.
Question: I would hope you used in your new
asteroid generator the above actually known orbits (and
names) rather than a collection of random orbits?
About three years ago we extracted with PERL the asteroid
orbits already into Celestia format. Here is a display I
made last year (in a different context) involving >
7000
known asteroids
In principle it would seem more elegant and in line with
Celestia's deep space object structure, to generate an
asteroid.ssc file with PERL from the above data with correct
coordinates, names, magnitudes, sizes, importance
weights [for non-overlapping labels (!)] and associate
randomly one of 20 template model files, say in that file.
That's a very easy and quick job. All we had to do is to
write a few lines in the code to parse the different template
model files and to upgrade my old PERL script a bit.
A most important point speaking for my suggestion is that
we may do a
MUCH more effective culling (via our general
octree class) within Celestia's core code compared to the
above ADD-ON solution that invokes very little culling and
should become forbiddingly slow for large asteroid
numbers!
Celestia is a multi-platform application, so EXEL based
spread sheets do not satisfy this design consideration,
except they run under OpenOffice. Did you check that your
spread sheet works with OpenOffice??
PERL exists in contrast for any OS.
Bye Fridger
[/url]
