Joe wrote:Thanks Selden, that was certainly a very delight confirmation for me as I was using a similar approach to using DEM data in Celestia. What was frustrating is to fix the final CMOD onto the face of a planet. No matter how many trials, always (never even mostly) errors. Is there a better way than CMOD in resolving the trial-and-error approach?
I'm not sure what you're tying to say.
The SSC coordinate system declarations available in Celestia v1.6.0 and later can make placement of a model on a planet's surface relatively easy.
If its edges are exactly on north-south and east-west directions, placing a model in the correct position on the surface of a planet, with the correct orientation and size, should require only some relatively straight-forward arithmetic
if you know the latitude and longitude of the center of the model (or one of its corners) and its dimensions. (I'm assuming that the model is small relative to the curvature of the Earth's surface. Otherwise there are mapping coordinate system effects that you may need to take into account.)
If you can't be sure of some of these prerequisites, then some way to change and measure an object's position and orientation in real-time is needed, which Celestia doesn't provide.

For example, here's the SSC placement code that I used for my VLA model. I split the placement code into two objects because of the way I structured the models. I've added some explanatory comments.
Code: Select all
# SurfaceObjects are "correctly" oriented perpendicular to the local surface of the planet
SurfaceObject "vla-00" "Sol/Earth"
{
# this object is just used for reference, so it doesn't need to be visible
# except while testing
Class "invisible"
#the actual Radius value doesn't matter, since this object is not visible
# if it's too small, though, the object won't be drawn and objects referencing it won't be drawn, either.
Radius 0.0125
# specify longitude (+ values are East of the prime meridian),
# latitude, and altitude (in km above sealevel)
FixedPosition { Planetographic [ -107.6177275 34.0787492 2.124]}
FixedRotation { }
}
# below is the definition of the pedestal supporting the VLA telescope's yoke
# the Path used in its name doesn't need to include the reference object above
# because that is specified in the Frame declarations.
# This Name and Path determine where this object is listed in Celestia's
# Navigation/Solar System Browser menu
"vla-00-base" "Sol/Earth"
{
Class "component" # avoids having to specify Albedo so it doesn't glow
Mesh "vla-base.cmod"
# The Radius (in km) must enclose this object's mesh so the object will be drawn correctly
# but does not itself determine the size of this object
Radius 0.0125
# Don't scale the Mesh to Radius. Instead use the model's internal dimensions.
# The object will be placed in Celestia relative to the center of the Mesh's internal coordinate system.
# In other words, if the object is offset relative to the coordinate system used by the software which created it, it'll be offset relative to the position used by Celestia.
NormalizeMesh false
# Scale the model's internal dimensions to km.
# The resulting object must be smaller than the Radius specified above.
# Otherwise only parts of it will be drawn from some viewpoints.
MeshScale 0.000055
# position the Mesh relative to the reference object
OrbitFrame { BodyFixed { Center "Sol/Earth/vla-00"}}
FixedPosition [ 0 0 0 ]
# orient the Mesh relative to the reference object
BodyFrame { BodyFixed { Center "Sol/Earth/vla-00"}}
FixedRotation {}
}
I hope this helps a little.
(My problem with the Hale telescope's ground surface texture was that topo maps have an arbitrary border and size, making it difficult to determine what values to use to cut out the correct small region corresponding to the mesh. Of course, there's also the issue of needing to know the exact coordinate system that was used for drawing the topo map in order to reproject a section of it correctly onto a slightly differently oriented flat object. I ignored that, since the error should have been relatively small.)