Available for download - Asteroid Maker 1.6

[buggs_moran]

Found a problem. First line in the calculations page under the column M - Q there is a reference to $J3 in the calculations, it should be $L3. Will try it in an addon when I get home, but the Celestia page looks fine now.

[bdm]

I may have uploaded the wrong version, I will check in about 10 hours from now. A fixed version (1.2) will be available shortly after that. (It may take a while to upload on my dialup connection so it may be a while.)

The problem with the #VALUE! error lies in the Kirkwood belt calculations in row 3. These are the columns headed with K1 to K5. A quick and easy fix for the problem is to copy the values for cells M4:Q4 into M3:Q3. This replaces the bad formulae in row 3 with the correct formulae.

More detailed fix instructions:
1. Open the spreadsheet and select the Calculations sheet.
2. Select the cells M4:Q4.
3. Press Ctrl+C to Copy the cells.
4. Select the cells M3:Q3.
5. Press Ctrl+V to Paste.

[B_McKinley]

Many, many thanks for even this version. I wasn't looking forward to the prospect of creating asteroid belts, now it's automated.


Will be staying tuned for updates.

Thanks,
brian

[buggs_moran]

So I said to myself...Self, I wonder what would happen if I used this spreadsheet in a cunningly (well, I though it was cunning) interesting way to create ring clutter around Saturn. At 10000 objects it is definitely cluttered . This took a bit of manipulation to generate all of the objects. I have to say that it needs lots of work, but it might just be possible. 10000 objects didn't seem to upset my system much, but you would really need more like 10 times that. I am sure some keen programmer could autogenerate 100000 house sized objects. Plus, I was tired of monkeying around and didn't resrict larger objects to the denser parts of the rings... The code worked very well though...

[Le Chacal]

I don't understand...

# Generated with Asteroid Maker Version 1,1 on YYYY-10-DD 12:46:42.

##############################################
#VALEUR!
"Asteroid 1" "Lam Ser"
{
Class "asteroid"
Texture "golevka.*"
Color [ 0.001 0.001 0.001 ]
# No mesh
Radius 3.01
EllipticalOrbit {
Period 000.000000000002
SemiMajorAxis 0.00000001
Eccentricity 0.00000000
Inclination 000.0056
AscendingNode 000.0094
MeanLongitude 000.0285
LongOfPericenter 000.0014
}
Obliquity 000.0091
EquatorAscendingNode 000.0355
RotationOffset 000.0295
RotationPeriod 0000.00000029
}

This is an example of calculation... Lambda Serpentis is a star of 1.04 Solar mass, so the asteroids calculated are INSIDE the star...
Why theses values are so little ?

[bdm]

I'm not sure why the values are so small, but there's small values across the board that you've posted - eccentricity, colour, everything.

Here's what typical orbital parameters *should* look like:

Code: Select all

##############################################
# Asteroid 1 - Mass: 6.5672e+19 kg. Normal asteroid with 0 moon(s)
"Asteroid 1" "Lalande 21185"
{
    Class                "asteroid"
    Texture              "bacchus.*"   
    Color                [ 0.900 0.800 0.700 ]
    Mesh                 "larissa.cmod"
    Radius               168.10
    EllipticalOrbit {
        Period           005.296102966209
        SemiMajorAxis    2.345435840158
        Eccentricity     0.132838288808
        Inclination      062.9598
        AscendingNode    191.6197
        MeanLongitude    098.1920
        LongOfPericenter 340.1807
    }
    Obliquity            157.9598
    EquatorAscendingNode 241.7383
    RotationOffset       191.0396
    RotationPeriod       0020.033185627151
}

What spreadsheet are you using?

I think it's a locale issue (European decimal points). I think it's interpreting "1.000" as one thousand rather than one. The only suggestion I have is to try disabling the thousands separator. I think this is throwing things off somehow. When this is repeated throughout, it would explain why the values are so small.

[bdm]

1.2 has been released. This version addresses the #VALUE! error caused by incorrect formulae in five cells of row 3. I have also added Hilda orbits for the inner planet.

[Le Chacal]

Bloody european decimal point ! You have the point, now it works !

Thanks bdm !

[t00fri]

So I said to myself...Self, I wonder what would happen if I used this spreadsheet in a cunningly (well, I though it was cunning) interesting way to create ring clutter around Saturn. At 10000 objects it is definitely cluttered . This took a bit of manipulation to generate all of the objects. I have to say that it needs lots of work, but it might just be possible. 10000 objects didn't seem to upset my system much, but you would really need more like 10 times that. I am sure some keen programmer could autogenerate 100000 house sized objects. Plus, I was tired of monkeying around and didn't resrict larger objects to the denser parts of the rings... The code worked very well though...

Ah, I can see my nice "blue-hat" Saturn texture

Bye Fridger

[selden]

There seems to be a bug in moon generation.

Sometimes two moons are generated for the same asteroid, but the definition of the second is incomplete:

Code: Select all

#BLANK
"A2-II" "Lalande 21185/Asteroid 2"
#BLANK
#BLANK
#BLANK
#BLANK
#BLANK
#BLANK
#BLANK
#BLANK
#BLANK
#BLANK
#BLANK
#BLANK
#BLANK
#BLANK
    }

Other times, the second moon has an invalid value for its orbital period:

Code: Select all

# Moon II: Mass 1.3283e+12 kg
"A25-II" "Lalande 21185/Asteroid 25"
{
    Class                "moon"
    Texture              "vesta.*"     
    Mesh                 "roughsphere.cms"
    Color                [ 0.900 0.800 0.700 ]
    Radius               0.51
    EllipticalOrbit {
#VALUE!
        SemiMajorAxis    166.918559190412
        Eccentricity     0.000000000000
        Inclination      000.0000
        AscendingNode    167.7838
        MeanLongitude    160.4648
        LongOfPericenter 281.2196
    }
    Obliquity            000.0000
    EquatorAscendingNode 013.9184
    RotationOffset       328.7409
    # No rotation period - tidally locked
}


[selden]

It'd be nice if the spreadsheet generated Albedo declarations.

The Color declaration (already generated by the spreadsheet) is used for the dot that is drawn drawn when the object is too far away to resolve (less than a couple of pixels across).

The Albedo declaration determines how bright that dot is.

[buggs_moran]

It'd be nice if the spreadsheet generated Albedo declarations.

The Color declaration (already generated by the spreadsheet) is used for the dot that is drawn drawn when the object is too far away to resolve (less than a couple of pixels across).

The Albedo declaration determines how bright that dot is.

Ditto, a big ditto. That was one of the things I didn't like in my Saturnian rings...lots of bright dots.

[bdm]

Are there any other missing parameters that I should include in the next revision? So far, I need to add the following:

* Albedo. This will be tied to the texture in the same way that color is.
* Extra information on the body, in a comment. I would like to include Asteroid Class here.
* Epoch.

I think I will also include a little space for user-defined fields to make customisation easier.

During this revision, the spurious lines reported by Selden will be removed as well.

It will be a few days before these revisions are ready.

[bdm]

There seems to be a bug in moon generation.

Sometimes two moons are generated for the same asteroid, but the definition of the second is incomplete.

This was a common problem, but I removed most of these prior to release of 1.0. This incomplete definition still occurs in cells Celestia.A121 and Celestia.A136, but I have determined that they occur nowhere else. The formula that determines whether to display moon info is incorrect, but the problem only manifests itself when Asteroid 1 has exactly one moon. This will be fixed in 1.3.

Other times, the second moon has an invalid value for its orbital period.

This is a very interesting bug and I'm surprised I didn't find this earlier. It's an obvious problem in Excel, but I used OpenOffice for development and OpenOffice appears to be more forgiving of this kind of error.

What's happening here is the calculation of the period is referencing the wrong cell. The strange thing is that the incorrect cell reference still gives reasonably correct results in OpenOffice because the cell that was misreferenced was the mass of the second moon. So instead of computing the period using M1+M2, only M1 was used.

This will be easy to fix in 1.3.

It will be a couple of days before 1.3 is released. To be included in 1.3:
Additions
* Albedo
* Asteroid orbit class (in a comment)
* Space for two user-defined fields

Bug fixes
* Removal of spurious moon definitions for first asteroid
* Correction of period formula for second moon

[bdm]

1.3 has been uploaded and is now available for download.

* Albedo
* User-defined fields
* Period formula for second moon corrected
* Added eccentricity and inclination for moon orbits

[Adirondack]

bdm,

will you upload the *new* version 1.3 to the CML?

Version 1.1 is available here:
http://www.celestiamotherlode.net/catalog/utilities.html


Adirondack

[hank]

1.3 has been uploaded and is now available for download.

* Albedo
* User-defined fields
* Period formula for second moon corrected
* Added eccentricity and inclination for moon orbits

Did you consider doing this with a CELX script? Then it would be available to all Celestia users, regardless of their platform or whether they have spreadsheet software installed. There's also at least a small chance that in the future it might be possible to use the script to insert the generated objects into Celestia on the fly.

- Hank

[bdm]

bdm,

will you upload the *new* version 1.3 to the CML?

Version 1.1 is available here:
http://www.celestiamotherlode.net/catalog/utilities.html


Adirondack

I have a better plan. I plan to upload version 1.4 to CML and the download link in the next day or two. There's not a lot of difference between 1.3 and 1.4 except for improved modelling of asteroid inclinations, one or two minor bug fixes and the addition of a new independent page that transforms orbits from one plane to another. I want to fix one more bug before I upload it.

As to CELX scripts, I have not given that consideration due to my lack of knowledge of the programming capabilities of that scripting language. The calculation of asteroid orbits is not an easy matter. Some of the functions I use in the spreadsheet are sqrt, sin, cos, arcsin, arccos, arctan, exp, log10 and norminv. If some of these functions are not in CELX then a conversion is not possible.

[hank]

I have a better plan. I plan to upload version 1.4 to CML and the download link in the next day or two.
...
As to CELX scripts, I have not given that consideration due to my lack of knowledge of the programming capabilities of that scripting language. The calculation of asteroid orbits is not an easy matter. Some of the functions I use in the spreadsheet are sqrt, sin, cos, arcsin, arccos, arctan, exp, log10 and norminv. If some of these functions are not in CELX then a conversion is not possible.

The Lua standard math library includes sqrt, sin, cos, asin, acos, atan, exp, and log10, and it may be possible to implement norminv. Would you be able to provide me with a copy of your spreadsheet in SYLK format so I can have a look at the formulas you're using? Also, about how many input parameters are involved altogether?

- Hank

[bdm]

The Lua standard math library includes sqrt, sin, cos, asin, acos, atan, exp, and log10, and it may be possible to implement norminv. Would you be able to provide me with a copy of your spreadsheet in SYLK format so I can have a look at the formulas you're using? Also, about how many input parameters are involved altogether?

- Hank

norminv(x, mean, stddev) is a function that converts a value to the corresponding value in a normal distribution with a given mean and standard deviation. 0.0 < x < 1.0. In the spreadsheet it is mostly used to calculate a Rayleigh distribution using the formula sqrt(norminv(x, 0, stddev)^2 + norminv(y, 0, stddev)^2) where 0 < x < 1 and 0 < y < 1. Norminv need not be used, but it does improve the accuracy of the distribution of the resulting orbits. (You probably know about norminv already but I provide an explanation to benefit those who don't know what it is.)

I'm not familiar with SYLK format, but the spreadsheet is compatible with OpenOffice. You may convert it if you wish but I prefer not to do so due to bandwidth considerations (I only have dialup access from the machine on which I develop the spreadsheet.)