Available for download - Asteroid Maker 1.6

Post requests, images, descriptions and reports about work in progress here.
Topic author
bdm
Posts: 461
Joined: 22.07.2005
With us: 14 years
Location: Australia

Available for download - Asteroid Maker 1.6

Post #1by bdm » 08.10.2005, 09:00

The Asteroid Maker is a spreadsheet that creates asteroid belts for fictional star systems.

These are the download links. The Motherlode link is recommended and should be tried first, but it won't be available until the Motherlode is updated. After version 1.6 becomes available at the Motherlode, all future version updates will be released through the Motherlode only.
Download links for version 1.6:
Asteroid Maker 1.6 - Motherlode (1068k)

Some features:
  • Up to 400 asteroids can be created at a time
  • Trojan and Hilda asteroids
  • Exclusion around Kirkwood gaps
  • Binary asteroids
  • Asteroid moons (up to 2 per asteroid)
  • Up to 25 random textures
  • Up to 20 random models

Sample screenshots:

Star system showing asteroid orbits
Image

A typical asteroid.
Image

An asteroid with two moons.
Image

A binary asteroid.
Image[/url]
Last edited by bdm on 23.10.2005, 00:40, edited 11 times in total.

Malenfant
Posts: 1412
Joined: 24.08.2005
With us: 13 years 11 months

Post #2by Malenfant » 08.10.2005, 10:19

That looks pretty nifty...!

Spaceman Spiff
Posts: 420
Joined: 21.02.2002
With us: 17 years 6 months
Location: Darmstadt, Germany.

Post #3by Spaceman Spiff » 08.10.2005, 11:26

Excellent! That'll save me doing one by hand for Don Edwards' HD 28185 system now! Phew!

And it includes almost all the features I was planning to have - the additional feature I was also going to do was Hilda families - which relates to an outer gas giant near the asteroid belt.

Well done!

Spiff.

ElChristou
Developer
Posts: 3776
Joined: 04.02.2005
With us: 14 years 6 months

Post #4by ElChristou » 08.10.2005, 13:09

Very nice work indeed.
Tx for this very usefull work.
Bye.
Image

Avatar
Cham M
Posts: 4325
Joined: 14.01.2004
Age: 54
With us: 15 years 7 months
Location: Montreal

Post #5by Cham » 08.10.2005, 15:07

:evil: :evil: The *&%$#@ Motherlode is so slow to update, I think it's better to give a link here, in the forum. I have uploaded several stuff to the Motherlode in the last weeks, and they NEVER shows off on their web page. I know the guys at the Motherlode are busy, but WHAT GIVES !?! :evil: :evil:
"Well! I've often seen a cat without a grin", thought Alice; "but a grin without a cat! It's the most curious thing I ever saw in all my life!"

Avatar
t00fri
Developer
Posts: 8772
Joined: 29.03.2002
Age: 17
With us: 17 years 4 months
Location: Hamburg, Germany

Post #6by t00fri » 08.10.2005, 16:10

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

Image

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

Malenfant
Posts: 1412
Joined: 24.08.2005
With us: 13 years 11 months

Post #7by Malenfant » 08.10.2005, 17:18

t00fri wrote: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?

Isn't it obvious that this creates asteroid belts for fictional systems? It's nothing to do with our own solar system.

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??


While it may be more 'polite' for them to do so, I'm not sure anybody has any obligation to create addons that work for all possible OSes, do they?

Avatar
t00fri
Developer
Posts: 8772
Joined: 29.03.2002
Age: 17
With us: 17 years 4 months
Location: Hamburg, Germany

Post #8by t00fri » 08.10.2005, 17:44

Malenfant wrote:
t00fri wrote: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?

Isn't it obvious that this creates asteroid belts for fictional systems? It's nothing to do with our own solar system.


Well I just wanted to make sure that bdm's Asteroid Generator is ficticional ONLY. Since bdm struggled so much to correctly transform his (random?) orbits to the Celestia ecliptical frame, I thought it might apply to real orbits...
Otherwise I'd use a simpler procedure ;-)

malenfant wrote:
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??

While it may be more 'polite' for them to do so, I'm not sure anybody has any obligation to create addons that work for all possible OSes, do they?


Certainly, at the ADD-ON level everyone is completely free.

We have seen plenty of "splendid" examples of this "liberty" in the past: many add-on creators used ignorantly and unnecessarily filename conventions that would NOT work in Linux (e.g. blank separated file names etc.) . "NICE"! that's all I can comment about this...

I have only posted here, since I think it is long overdue to realize a clean, realistic and fast asteroid belt implementation in Celestia.

At least when I am involved, EVERYTHING will be cross-platform compatible. Since Toti and I have now set up some very general code foundations for a highly effective octree culling mechanism, we could really address asteroids in very general and most effective terms.

If such arguments are irrelevant to the people in this board, then indeed my above post was superfluous.

Since our implementation will be enormously faster because of the culling, I thought it's at least useful to make this option known. Since my PERL script has all the transformations from the sky-plane to the Celestia ecliptic frame already built in, the same framework that produces the realistic asteroid belt could be elegantly used for generating ficticious asteroid belts as well.

I guess this should have been obvious from my above mail and was another reason for my posting.

Bye Fridger

Avatar
Cham M
Posts: 4325
Joined: 14.01.2004
Age: 54
With us: 15 years 7 months
Location: Montreal

Post #9by Cham » 08.10.2005, 18:02

bdm,

I just tried several times your spreadsheet. Someone found it and gave it to me by email so I could try it with NeoOffice J (a version of OpenOffice for OS X). Well, it doesn't appear to work correctly ! :-(

I'm asking the spreadsheet to do a simple file of 15 asteroids and it gives me a bunch of 350 asteroids instead ! Also, the exported file is very messy without well placed tabulations and carriage returns so it's not obvious how to edit the file. And, there are some missing " scatered in the exported file which makes it almost unusable. And lastly, I'm getting "," in all the numbers instead of the ".", which is appparently related to the fact I'm using a French system.

So until now, this spreadsheet is very cumbersome to use and almost useless.
Last edited by Cham on 08.10.2005, 18:42, edited 1 time in total.
"Well! I've often seen a cat without a grin", thought Alice; "but a grin without a cat! It's the most curious thing I ever saw in all my life!"

Dollan
Posts: 1150
Joined: 18.12.2003
Age: 49
With us: 15 years 8 months
Location: Havre, Montana

Post #10by Dollan » 08.10.2005, 18:35

Cham wrote::evil: :evil: The *&%$#@ Motherlode is so slow to update, I think it's better to give a link here, in the forum. I have uploaded several stuff to the Motherlode in the last weeks, and they NEVER shows off on their web page. I know the guys at the Motherlode are busy, but WHAT GIVES !?! :evil: :evil:


With all respect, I don't think that is very fair. These guys are volunteering for the Motherlode project, and what they've put into it thus far, as far as I'm concerned, is so far above and beyond the call of duty that I don't think anyone has the right to criticise them, at least not on their timeliness. They don't have to be doing this, and they do have jobs, school, and families. Frankly, I'm amazed that they can find the time to get done what they have!

I myself have been waiting for about a month for my latest add-on to be posted, but considering that without them there would be NO chance of me offering it out to those who are interested (and I am still amazed that there ARE those that are interested, considering the sheer quality of stuff that you, D. Edwards, and a host of others put out!), I simply can't complain.

...John...
"To make an apple pie from scratch, you must first create the universe..."
--Carl Sagan

Avatar
selden
Developer
Posts: 10064
Joined: 04.09.2002
With us: 16 years 11 months
Location: NY, USA

Post #11by selden » 08.10.2005, 18:35

Fridger,

I think an octree culling algorithm for asteroids would be quite helpful. The AstOrb database that you mention is updated regularly from the Minor Planet Circulars. It currently contains orbital elements for almost 250,000 asteroids.
Selden

Avatar
t00fri
Developer
Posts: 8772
Joined: 29.03.2002
Age: 17
With us: 17 years 4 months
Location: Hamburg, Germany

Post #12by t00fri » 08.10.2005, 18:47

selden wrote:Fridger,

I think an octree culling algorithm for asteroids would be quite helpful. The AstOrb database that you mention is updated regularly from the Minor Planet Circulars. It currently contains orbital elements for almost 250,000 asteroids.


Selden,

certainly! With our new FT octree template framework, it's not even complicated to do. We would just add a certain number of model files to be picked randomly or in custom manner, just like with DSO's. in FT1.1. Another nice feature that is also in line with what we are presently realizing for DSO's (and I have realized in the past for all affected location labels), is importance weighting. This means if one is traversing the asteroid belt only a limited, non-overlapping number of labels will be visible at a time. New ones will be popping up upon zooming (decreasing the FoV).

The astorb data base you pointed at is the same I quoted above. Just the number of asteroids has apparently increased during the last couple of years.

Bye Fridger

Topic author
bdm
Posts: 461
Joined: 22.07.2005
With us: 14 years
Location: Australia

Post #13by bdm » 09.10.2005, 03:48

Spaceman Spiff wrote:Excellent! That'll save me doing one by hand for Don Edwards' HD 28185 system now! Phew!

And it includes almost all the features I was planning to have - the additional feature I was also going to do was Hilda families - which relates to an outer gas giant near the asteroid belt.

Well done!

Spiff.
Hilda family asteroids (3:4 resonance) will be included in version 1.1. I have already reserved space for them but I neglected to include them. In any case, adding them should be fairly simple. The advantage of a spreadsheet solution rather than an application is that anyone can freely modify the spreadsheet to suit their needs.

t00fri wrote: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?

Bye Fridger

The spreadsheet does use random orbits, but I have made some effort to introduce realism.
  • The semimajor axes are a flat distribution, minus exclusions at the Kirkwood gaps. There are configurable forbidden zones at the orbits of the inner and outer planets. This is a little unrealistic, but it will do for most people.
  • The eccentricities of the orbits are distributed using a Rayleigh distribution with a peak at 0.14. This closely matches the eccentricity distribution of actual asteroids. However, there is no adjustment for eccentricity vs inclination and eccentricity vs semimajor axis to make them more realistic.
  • Inclinations are distributed randomly with a preference for low inclinations. Purists will find this unrealistic, but as already stated, this is why it is distributed as a spreadsheet rather than an application.
Overall, the asteroid belts as generated will be good enough for the average user. Purists will find issues with the orbit distributions, but should have little fault with the orbit of a single asteroid (except for a known issue with Trojan asteroids). Even the orbits of the asteroid moons are calculated with a reasonable degree of precision using Newtonian physics.

t00fri wrote:bdm,
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


OpenOffice 1.1.5 and Excel 97 were both used for creating the spreadsheet. The final work was done entirely with OpenOffice. Indeed, I have found that it works better with OpenOffice, because it is possible to save the "Celestia" sheet of the spreadsheet as a text file, and then run the file in Celestia with no modification to the contents of the file. Excel exports are somewhat clumsy.

You have valid concerns about a cross-platform implementation. That is why I chose to create a spreadsheet rather than an application, and use OpenOffice for most of the development work. I didn't use Perl because regrettably I have not learnt that language.

One final note - yes, this is for fictional star systems. Such fictional systems will usually have reference planes that are inclined to the ecliptic, so it is necessary to create the orbits for that reference plane and then rotate them into the ecliptic plane. This will be a useful tool for people who are creating such systems.

Topic author
bdm
Posts: 461
Joined: 22.07.2005
With us: 14 years
Location: Australia

Post #14by bdm » 09.10.2005, 04:19

Cham wrote:bdm,

I just tried several times your spreadsheet. Someone found it and gave it to me by email so I could try it with NeoOffice J (a version of OpenOffice for OS X). Well, it doesn't appear to work correctly ! :-(
Then it will need to be remedied somehow. I am not familiar with NeoOffice J, nor Mac's OS X, nor French localisation, so it is good of you to mention these issues so they can be addressed. The spreadsheet should currently be viewed as a beta.

I'm asking the spreadsheet to do a simple file of 15 asteroids and it gives me a bunch of 350 asteroids instead !
This is a known issue. The limiting of exported asteroids is currently done by commenting out the excess lines, which I admit is not satisfactory. In the next version the excess asteroids will not be exported at all, which is what you want. I will also group the moons with the asteroids to make it easier to export them together.

Cham wrote: Also, the exported file is very messy without well placed tabulations and carriage returns so it's not obvious how to edit the file.
If you're referring to the placement of all orbital elements on one line, this can be fixed fairly easily. Celestia doesn't care if the elements are on one line or not, but because people do care, I will see what can be done. I have somewhat less control over tabulation, but I will address this issue as well if I can do so.

Cham wrote: And, there are some missing " scatered in the exported file which makes it almost unusable.
(1) How are you exporting the file? Exporting can do things like placing commas (,) and double quotes (") around field elements and regrettably there's little I can do about how applications choose to do their exports. If you're experiencing export issues, copy to clipboard and paste to text editor can work around most export problems. (I don't know how Macs do copy and paste; someone may need to correct me here.) For OpenOffice, exports must be done as a fixed-width file.
(2) File names for textures and models MUST include double quotes around the filenames.
(3) Can you post a sample?

Cham wrote: And lastly, I'm getting "," in all the numbers instead of the ".", which is appparently related to the fact I'm using a French system.
Thank you for mentioning this particular localisation issue. I should be able to fix it for the next version. Evidently the French localisation is interpreting format strings like "000.0000" as "000,0000". This is usually correct, but for Celestia which requires a particular format, I must postprocess the strings to change any "," to ".".
Cham wrote:So until now, this spreadsheet is very cumbersome to use and almost useless.

Your feedback is appreciated. I will be able to rectify most of these issues so the next version is easier to use.

Avatar
t00fri
Developer
Posts: 8772
Joined: 29.03.2002
Age: 17
With us: 17 years 4 months
Location: Hamburg, Germany

Post #15by t00fri » 09.10.2005, 10:59

bdm,

thanks for your detailed explanations ...and thanks for checking out/using OpenOffice besides EXEL!

Toti and I are already planning, how to implement a very LARGE number of actual/realistic asteroids AND comets with little fps loss in the next FT2 version. Each of these asteroids will be clickable, displaying full info from the official ASTORB catalog.

++++++++++++
Name
Absolute Magnitude (H-parameter)
IRAS Color Classification string
B - V color
Slope magnitude parameter
Diameter
++++++++++++

Given the detailed catalog information about size and color we may proceed like for galaxies and attribute specific and quite characteristic template models to each asteroid.

As Toti correctly realized, we don't even have to employ random models.

Moreover we can display at every point in space the apparent magnitude of the object that is given by the formula

Code: Select all

 m = H1 + R1 log(r) + D1 log(D)


where H1, R1, D1 are the parameters given in the ASTORB catalog, r is the distance (in AU) Sun-Comet, and D is the distance (in AU) Observer-Comet.


Bye Fridger

hank
Posts: 645
Joined: 03.02.2002
With us: 17 years 6 months
Location: Seattle, WA USA

Post #16by hank » 09.10.2005, 19:48

t00fri wrote:
selden wrote:I think an octree culling algorithm for asteroids would be quite helpful.
With our new FT octree template framework, it's not even complicated to do.

The new FT octree framework supports moving objects?

- Hank

Avatar
t00fri
Developer
Posts: 8772
Joined: 29.03.2002
Age: 17
With us: 17 years 4 months
Location: Hamburg, Germany

Post #17by t00fri » 09.10.2005, 19:54

hank wrote:
t00fri wrote:
selden wrote:I think an octree culling algorithm for asteroids would be quite helpful.
With our new FT octree template framework, it's not even complicated to do.
The new FT octree framework supports moving objects?

- Hank


Very good question ;-)

We working on this ...

Bye Fridger

Topic author
bdm
Posts: 461
Joined: 22.07.2005
With us: 14 years
Location: Australia

Post #18by bdm » 10.10.2005, 10:56

UPDATE:

I have added a download link to my first message.

At present, the asteroid maker should be viewed as a beta, because there are still a few issues that I need to resolve. One issue that may not yet be resolved is the localisation issue, however I'm confident that this is resolved.

It works fine on Excel and Open Office. I haven't examined it with other spreadsheet applications.

If there are issues that are not mentioned in the documentation, please post about them in this thread.

Le Chacal
Posts: 25
Joined: 20.03.2005
With us: 14 years 5 months

Post #19by Le Chacal » 10.10.2005, 11:57

It doesn't work on my Excel 2002... There is errors in formulas of k1, k2, k3 and k4, and I don't understand anything in theses sheets...

Avatar
selden
Developer
Posts: 10064
Joined: 04.09.2002
With us: 16 years 11 months
Location: NY, USA

Post #20by selden » 10.10.2005, 13:41

It doesn't work wiith Excel 2000, either :(

On the Calculations sheet, the "Number" column contains the string #VALUE! in every row. The "Export" column contains ###### in every row. The other columns look reasonable.

The Celestia sheet consists of a header line saying
# Generated with Asteroid Maker Version 1.1 on 2005-10-10 09:31:42.
and many rows, each containing only the string #VALUE!
Selden


Return to “Add-on development”

Who is online

Users browsing this forum: 1 guest