Celestia Forums

I've implemented--but not committed--a change that allows the triaxial ellipsoids to be specified for ssc objects. It's similar to what's in use now for stars: a property called SemiAxes is used to set the dimensions of the ellipsoid. It may be used either with or without Radius. In either case, the radius and semi-axes are multiplied to give the final size of the object. If no radius is specified, the default value is one. Thus for Mimas, you'd write:

SemiAxes [ 209.1 196.2 191.4 ]

The big difference is that with stars, the default radius is not one
but some value calculated from the luminosity and temperature.

Another difference is that the y and z axes are swapped. With the introduction of reference frames in 1.5.0, I've made some efforts to make Celestia conform to a more standard astronomical coordinate system, with primary rotation axis = +z. I propose that the SemiAxes property for stars be changed as well. It's not a very widely use feature, so the number of affected add-ons should be very small. The only change required in the standard Celestia files is for Altair in nearstars.stc. Add-on creators: has anyone made extensive use of ellipsoidal stars? How disruptive would it be to swap the y and z axes?

--Chris

chris wrote:Add-on creators: has anyone made extensive use of ellipsoidal stars? How disruptive would it be to swap the y and z axes?

I'll have to check. I know I already used that property in some few cases only. If you change the property, I could certainly modify easily the few addons I created which are using the SemiAxes.

chris wrote:The only change required in the standard Celestia files is for Altair in nearstars.stc.

Vega too.

The CHARM2 add-on defines radii for both of these stars, but as it is generated from the Celestia datafiles anyway, I can regenerate it without much effort if needs be.

Further question: what happens if both Oblateness and SemiAxes are defined?

ajtribick wrote:Further question: what happens if both Oblateness and SemiAxes are defined?

Oblateness is ignored if SemiAxes is defined. It's just as easy to multiply everything together, so that the z-axis is radius*semiaxes_z*(1-oblateness). That's one less special case, but otherwise it doesn't make much sense.

--Chris