[attn: bdm] Asteroid Maker 1.6 questions

Post requests, images, descriptions and reports about work in progress here.
Coffeebot
Posts: 6
Joined: 04.06.2006
With us: 18 years 5 months

Post #21by Coffeebot » 04.06.2006, 07:26

I just started playing around with Celestia and the asteroid-maker now that I've finally designed a fairly stable and plausible system. And I think they're great.

Since my #1 priority is realism for this system (I had to bend a few "rules" but not so much as to be unbelievable), I'd like to know how trustworthy the asteroid-maker is in regard to orbits and not colliding with other planets.

I generated a smaller-than-default field between my Jupiter and Mars equivalents (100 bodies) and it looks like some of the asteroid paths come dangerously close to several planets, including ones inside the inner planet range. And, for the record, I moved my view around to see if the orbit was "above" or "below" the endangered planet, and they still came too close.

So, the question is, does a-m account for gravitational pulls between bodies, and only allow them to orbit if they won't affect other planets? I think some of that is answered by the app itself, in that it knows nothing about the other planets in the system, because none of the details are entered.

The other question that I have, and may need to ask in another post/forum is whether or not Celestia handles gravity and collisions. If two objects are in unstable orbits, will they collide or catapult one another out of the system?

Thanks!

Avatar
selden
Developer
Posts: 10192
Joined: 04.09.2002
With us: 22 years 2 months
Location: NY, USA

Post #22by selden » 04.06.2006, 15:52

Coffeebot,

Celestia does no gravitational calculations and includes no collision logic. Trajectory paths are all predefined, using VSOP87, Keplerian ellipses or trajectories of xyz coordinates.
Selden

bdm
Posts: 461
Joined: 22.07.2005
With us: 19 years 4 months
Location: Australia

Post #23by bdm » 05.06.2006, 03:17

Coffeebot wrote:So, the question is, does a-m account for gravitational pulls between bodies, and only allow them to orbit if they won't affect other planets? I think some of that is answered by the app itself, in that it knows nothing about the other planets in the system, because none of the details are entered.

No, it doesn't take into account gravitational interactions. Basically Asteroid Maker just generates a series of orbits that conform to basic input parameters. It's a good idea to do a sanity check after generating the orbits by loading it into Celestia and hand-pruning any asteroids whose orbits are unsatisfactory for any reason.

This does not mean that one cannot modify Asteroid Maker to do this. Asteroid Maker includes various exclusion rules that block the export of asteroids under certain circumstances. These circumstances could easily be expanded to include orbits that pass too close to the orbits of the bounding planets.

I'm not sure yet on the best way to do this, but I believe that comparing the pericenter and apocenter of the asteroid to the pericenter and apocenter of the bounding planets would be the best way. Inclination would need to be considered as well. A high-inclination asteroid that crosses the orbit of a bounding planet will last a lot longer than an asteroid that orbits in the same plane as a bounding planet.

Perhaps the simplest method would be to define a Donut of Doom around the orbit of the bounding planets, and the orbit of any asteroid that intersects the Donut of Doom is, um, doomed and is therefore excluded. As yet I have no idea how to do this mathematically.

Asteroid Maker is a tool, not a complete solution on its own. Like any tool, sometimes other tools are required to finish the job to perfection.

Coffeebot
Posts: 6
Joined: 04.06.2006
With us: 18 years 5 months

Post #24by Coffeebot » 05.06.2006, 05:49

bdm wrote:Perhaps the simplest method would be to define a Donut of Doom around the orbit of the bounding planets, and the orbit of any asteroid that intersects the Donut of Doom is, um, doomed and is therefore excluded. As yet I have no idea how to do this mathematically.


mmmm...donuts.

But, seriously, that's not a bad idea. I've been loathe to dive into the code behind the spreadsheets, if only because I've been doing way too much of it at work. The "Torus of Terror" shouldn't be too terribly hard to calculate, but it would just require the user to enter more information for every planet they want to protect. In most cases, though, it would probably only be one or two more planets.

As a side note, is there a way to get celestia to display the orbits of asteroids without having to select them? It would be easier to weed out the destructive asteroids this way. Maybe just setting the asteroids' class to planet or just commenting it out would do the trick, temporarily.

Thanks for the quick responses. I'll see what I can come up with this week.

bdm
Posts: 461
Joined: 22.07.2005
With us: 19 years 4 months
Location: Australia

Post #25by bdm » 07.06.2006, 01:11

Coffeebot wrote:
bdm wrote:Perhaps the simplest method would be to define a Donut of Doom around the orbit of the bounding planets, and the orbit of any asteroid that intersects the Donut of Doom is, um, doomed and is therefore excluded. As yet I have no idea how to do this mathematically.

mmmm...donuts.

But, seriously, that's not a bad idea. I've been loathe to dive into the code behind the spreadsheets, if only because I've been doing way too much of it at work. The "Torus of Terror" shouldn't be too terribly hard to calculate, but it would just require the user to enter more information for every planet they want to protect. In most cases, though, it would probably only be one or two more planets.
More on what I think is required here. The "Donut of Doom" or "Torus of Terror" would not really be a torus as such, due to the eccentricity of the planets' orbits. The first approximation would be a circle of a certain radius around the orbit of the planet. The perihelion of orbits precess over time, and this should be taken into account. Therefore, the exclusion zone should actually be the sum of all possible exclusion zones. As a second approximation, the cross-section of this exclusion zone would not be a circle (unless the orbit was a circle) but instead would be a rectangle capped by semicircles at both ends. The planet would spend more time in the middle of this path than at both ends, so another approximation should be wider in the middle. I think the exclusion zone should be a torus with an elliptical cross section with the foci at the pericenter and apocenter distances, with the eccentricity of the ellipse equal to the eccentricity of the orbit.

I have no idea how mathematically accurate this would be, but it is a good approximation of what is needed for the exclusion zone.

An asteroid's orbit should be excluded if it intersects this elliptical exclusion zone.

Why go to this trouble? Sometimes an asteroid's orbit may be inclined enough that it does not pass anywhere near either planet and thus would remain in the belt for a long time. A more simplistic exclusion algorithm would exclude these bodies. Think of Pluto; it's got an inclined orbit and crosses the orbit of Neptune. If such bodies are generated we should keep them.

Coffeebot wrote:As a side note, is there a way to get celestia to display the orbits of asteroids without having to select them? It would be easier to weed out the destructive asteroids this way. Maybe just setting the asteroids' class to planet or just commenting it out would do the trick, temporarily.

Yes, in the "Render" menu under "View Options", there is a checkbox (tickbox) that can be selected to enable the rendering of asteroid orbits.

bdm
Posts: 461
Joined: 22.07.2005
With us: 19 years 4 months
Location: Australia

Post #26by bdm » 07.06.2006, 01:36

More on the exclusion zone:

For this discussion I will assume that the planet is external to the asteroid belt in a manner similar to Jupiter. For an internal planet, swap pericenter and apocenter as required. I also assume that the asteroid is not in a resonant orbit and has a semimajor axis smaller than the semimajor axis of the planet. I will use the capped-rectangle model for this discussion.

The exclusion zones for an asteroid can be divided into three parts.
  1. If the apocenter distance of the asteroid is less than the pericenter distance of the planet minus the radius of the exclusion zone, the asteroid should always be included.
  2. If the apocenter of the asteroid is between the pericenter distance of the planet minus the radius of the exclusion zone and the apocenter distance of the planet plus the radius of the exclusion zone, then the asteroid should always be excluded.
  3. If the apocenter of the asteroid is greater than the apocenter distance of the planet plus the radius of the exclusion zone, the asteroid may be included or excluded depending on whether its orbit intersects the exclusion zone.
This last case is the one where some additional mathematics is required. I'm not sure what to do here. I think we need to include the sine of the inclination somewhere, but we may also need to take the inclination of the planets' orbits into account. The best I could come up with is to project the orbit of the asteroid onto a plane that is perpendicular to the plane of the planets' orbits and intersects the semimajor axis of the asteroid, and then calculate whether the orbit of the asteroid projected onto that plane intersects the exclusion zone projected onto that plane.

Avatar
Hungry4info
Posts: 1133
Joined: 11.09.2005
With us: 19 years 2 months
Location: Indiana, United States

Post #27by Hungry4info » 14.06.2006, 05:54

The asteroid maker doesn't even work for me. I download it and it says that "data is missing".

Avatar
Hungry4info
Posts: 1133
Joined: 11.09.2005
With us: 19 years 2 months
Location: Indiana, United States

Post #28by Hungry4info » 14.06.2006, 06:11

Yeah... never mind. It still works anyway. I just realized I have to copy the generated information and paste it into a .ssc file. I thought it made the .ssc for you. So yeah, never mind. I am, to say the least, ignorant.

Coffeebot
Posts: 6
Joined: 04.06.2006
With us: 18 years 5 months

Post #29by Coffeebot » 14.06.2006, 14:08

Hungry4info wrote:Yeah... never mind. It still works anyway. I just realized I have to copy the generated information and paste it into a .ssc file. I thought it made the .ssc for you. So yeah, never mind. I am, to say the least, ignorant.

The text file that's included with AM tells you specifically how to export the data into an ssc, without having to cut and paste.
asteroid-maker-docs.txt wrote:EXCEL - There is no convenient way to export using Excel, because all Excel text formats insert extra double-quote (") marks in the names of each body. To export with Excel, the clipboard must be used:
1. Select the "Celestia" sheet.
2. Click on the column header of column A, so the whole column is selected.
3. Type Ctrl+C to Copy to clipboard.
4. Open a text editor and create a new document.
5. Paste from the clipboard into the text editor.
6. Save the document as an SSC file.

OPEN OFFICE - To save in OpenOffice 1.1.5:
1. Select the "Celestia" sheet.
2. In the "File" menu, select "Save As".
3. Choose the "Text CSV" option.
4. Enter a filename. (The SSC extension can be used here.)
5. In the "Export of text files" dialogue, select "Fixed column width" and click
"OK".


I use Open Office, and have had 0 problems with the export (just make sure it doesn't save the file as filename.ssc.csv as this will create a minor annoyance.

Edit:
Haha. I actually read the export instructions for Excel. Yeah. You have to cut and paste. Funny how the $300 spreadsheet app can't do the simple things like a free one can.


Return to “Add-on development”