Sorry for the long post but it's taking a long while to update my ssc catalogues of minor objects due to some issues I want to propose solutions for, and give as much information as I can. Here a list of problems I encounter with ssc definitions of solar system objects:
- The radius of many objects is poorly known. Instead the absolute magnitude is usually given. With the help of the (geometric) albedo one can calculate the size and thus the radius of the object. The albedo in turn again is poorly known for many objects so finding a set of parameters that is consistent with the absolute magnitude requires a lot of trial and error with complicated calculations. Using the absolute magnitude instead and let Celestia calculate the appropriate size seems to be more reasonable.
- So far, Celestia desperately normalizes the dimension of an object so that the maximum dimension, be it the size of a mesh or the highest value in the SemiAxes definition, is equal to the Radius value. So if you are using a random shape from cms modeling Celestia renders the object too small. The maximum radius of an object again is usually poorly known or at least has little meaning. Instead the mean radius of an object is usually given and does state the actual size of an object independent of its shape.
- The Color parameter is used to multiply the brightness of the splotch of light of an object and blend its texture by the same color. One can counteract the loss of brightness by increasing the brightness of the texture, but the intrinsic brightness of the splotch representing the object is lost. If Celestia internally scaled the color so that the luminance equals 1, these issues could be avoided.
- Map projection on non-spherical objects can't be controlled. Converting maps from planetocentric to planetographic and vice-verca is not an easy task. If Celestia provided different projection types one could use any type of map projection.
Here I propose new parameters to be used in ssc files. These parameters are more precisely known for many minor bodies or have more meaning that the parameters Celestia provides so far.
Main parameters (to be used in main object definiton):
AbsMag float
Absolute Magnite as defined for a solar system body.
GeomAlbedo float
Geometric Albedo. Already used in 1.7, but listed for its relation to the other parameters.
MeanRadius float
Mean Radius of the object, defined as the geometric mean of the 3 body axes a, b, and c: (a*b*c)^(1/3). If not specified, Celestia will use Radius intead or if also undefined, calculate the mean radius from AbsMag and GeomAlbedo. Usefull for objects which sizes aren't well constrained and the albedo is also poorly known or can only be estimated. Celestia should display and work with the mean radius rather than the maximum radius if the object is irregularly shaped. Overwrites Radius.
Color vector
Same as the color parameter already defined, but Celestia will normalize the vector so that 0.3*red + 0.59*green + 0.11*blue = 1. With these values Celestia will balance the brightness of the disc it displays the object with at high distances (otherwise defined by GeomAlbedo, distance etc. ). Default value is [ 1 1 1 ].
BlendTexture float
Celestia will multiply the texture with the normalized Color vector and the float defined with this parameter and scale it with a constant (I believe this constant to be 2/Pi, what I got as the phase integral of a lambertian scatterer, but if there is any uncertainty lets ignore this factor as we can just multiply it manually with the float as imput). Celestia will then blend the color of the object onto the texture. The value should be the average brightness of the texture, more precisely the average value of its Y channel in the YGbGr color space. If you want this to be precise, keep in mind that cylindrical maps as used in Celestia are not equal area projections. You can measure the value considering projection by averaging out the texture horizontally and then measure the average brightness in a circle with the dimentions of the texture.
Shape { }
Subdefnition for parameters that otherwise are so far used for 3D models or in cms definitions. See below for details.
Shape subdefiniton:
SemiAxes vector
The relative dimensions of the 3 body axes a, b and c. Celestia should normalize these values internally so that their geometric mean is 1, so that you can choose to use relative, normalized or absolute values. If not defined, Celestia will assume the vector [ 1 1 1 ] or in other words a sphere.
Oblateness float
Oblateness of the object, ranging from 0 (spherical) to 1 (disc). Overwritten by SemiAxes. Celestia should increase the equatorial radius so that the mean radius is equal to the MeanRadius parameter (or Radius if undefined).
FeatureHeight float
Parameter used so far only in cmd models. If > 0, Celestia generates random noise at this amplitude to simulate irregular shaped objects. Default value is 0.
Octaves integer
Number of Peroids of the noise around the object, so the spatial scale of the noise.
Resolution vector
Replaces the Rings and Slices parameters in cms defintion. This vector thus has 2 dimensions. Currently the default value of this vector in Celestia is [ 20 20 ]. For spheroid objects Celestia seems to use some kind of fractal to approxiamte a sphere. If that was applied to the height modification by the other cms models this parameter would be obsolete. Otherwise I'd recommend a low default value in the vicinity of say 20-40 for irregular shaped objects and 100-1000 for spheroid objects.
NoiseOffset vector
Changes the shape of the random noise.
Mesh "filename"
3D model to be used as the mesh for the object instead of random noise. If defined overwrites all parameters that produce the shape instead, so Oblateness, FeatureHeight, Octaves, Resolution and NoiseOffset. If SemiAxes is defined, Celestia knows what coordinate system to use on the body but will not distord the mesh with these parameters. Mesh is scaled so that that the mean value of SemiAxes equals the MeanRadius. If SemiAxis is undefined, Celestia will scale the internal coordinates of the mesh to the mean radius.
NormalizeAxes bool
If set to false, Celestia wont rescale the model so the mean radius of the axes fit the MeanRadius parameter. Could be used for cases where the maximum dimension of an object should be used instead. Also applies to shape models defined by the Mesh parameter.
Projection"type"
Map projection to be used on the object. If the dimensions of the object are defined by SemiAxes or Oblateness, Celestia will warp the texture to fit the projection type. Values can be "planetocentric" or "planetographic". Can be used for textures that are not avaliable in the correct projection. So far Celestia requires planetocentric projection on shape models defined by Mesh and planetogrpahic projection on how it handles the SemiAxes parameter. Projection type "planetocentric" means Celestia will morph the map assuming planetographic projection to planetocentric and vice-versa.
Some examples of how these object definitions would look like:
Code: Select all
"2003 AZ84:(208996) 2003 AZ84" "Sol"
{
AbsMag 3.77
GeomAlbedo 0.107
Texture "asteroid.*
Color [ 0.995 0.995 1.000 ] # derived from spectrum
BlendTexture 0.5
Shape
{
SemiAxes [ 1.00 0.82 0.52 ]
}
.
.
}
"Albion:195760 Albion:1992 QB1:1992 QB1:QB1" "Sol"
{
AbsMag 7.1
GeomAlbedo 0.13 # ? average for cold-classicals
Shape
{
FeatureHeight 0.2
Octaves 2
}
.
.
}
"Hyperion:Saturn VII" "Sol/Saturn"
{
MeanRadius 135
Shape
{
SemiAxes [ 180 133 103 ]
Mesh "hyperion.cmod"
}
.
.
}
"Jupiter" "Sol"
{
Radius 71492 # equatorial radius (max radius)
Texture "jupiter.*"
Shape
{
Oblateness 0.06487
Projection "planetocentric"
NormalizeAxes false
}
.
.
}
What do you think? Are these parameters usefull to include or modify as described? Would it be feasable to implement these feautures without much hustle? At the very least I think the AbsMag parameter should be added as something similar is already used for stars. And remove Cestia's obsession to scaling everything down to the max radius. I'm not sure how much processing power normalizing the Color and SemiAxes parameters will require, as well as reprojecting map types. Those would be lower priority to implement in my opinion.
