Celestia Forums

One thing that I've seen add-on creators struggle with is exact positioning of meshes with respect to each other. Positioning of meshes is complicated by Celestia's automatic rescaling and centering. The result is that mesh creators have had to resort to adding invisible bounding boxes and such to their meshes. I want to start thinking about how to address this is in 1.5.1 while maintaining compatibility with 1.5.0 add-ons.

Disabling mesh recentering is the easier problem to solve. Currently, Celestia computes the center of a mesh's bounding box and uses this value as the model center. If recentering were to be disabled, the origin defined in the mesh file would be the center. A means of disabling mesh recentering would eliminate the need to use the rather confusing MeshCenter property or invisible bounding boxes. Most asteroid and spacecraft meshes that I've seen have an origin at the center of mass. It would be convenient to be able to use this instead of working backward from the Celestia-calculated bounding box center.

Rescaling of meshes is a more complicated problem. Celestia 1.5.0 normalizes mesh geometry so it fits inside a box with a maximum side length of 2, then applies the radius scale. For a single mesh, this is desirable. Add-on creators don't have to concern themselves with the units used when modeling; they just set the radius and everything works. But multipart add-ons have a problem. Consider the case of a spacecraft where the body and solar panels are defined as separate objects. They will have different scale factors applied automatically, because unless special measures are taken (usually invisible geometry), the body and solar panel meshes will have different bounding boxes. Aligning them will require careful setting of the radius for both meshes.

Perhaps this isn't a big problem. In the case of this spacecraft, the modeler can easily check the extents of the solar panels and body, then set the radius appropriately. I'd like to hear how much of a problem it is. My intuition is that solving the mesh centering problem would eliminate most of the positioning headaches.

My proposal is quite simple. I suggest overloading the MeshCenter property so that this:

MeshCenter "origin"

...would use the origin defined in the mesh as the center.

--Chris

Chris,

this isn't really a problem. I don't think you should fuss with this. Using invisible boxes is a good technique, very easy to apply. Personally, I don't think there is anything special to be done here.

chris wrote:Rescaling of meshes is a more complicated problem. Celestia 1.5.0 normalizes mesh geometry so it fits inside a box with a maximum side length of 2, then applies the radius scale. For a single mesh, this is desirable. Add-on creators don't have to concern themselves with the units used when modeling; they just set the radius and everything works. But multipart add-ons have a problem. Consider the case of a spacecraft where the body and solar panels are defined as separate objects. They will have different scale factors applied automatically, because unless special measures are taken (usually invisible geometry), the body and solar panel meshes will have different bounding boxes. Aligning them will require careful setting of the radius for both meshes.
--Chris

IMHO the radious scale must be eliminated at all. As in the other 3D modelers and viewers the add-on creators must create the solids with 1:1 ratio. Moreover the framing system of the models, parts and subparts must be totally relative using some sort of scene graph that would be extremely useful for animations too. But we've already discussed about this.
Kind regards.

Paolo,

Sorry, but providing models with appropriate internal sizes simply is not feasable for astronomical objects.

Some objects are tiny, millimeters in radius, while others are billions of light years in radius. Also, there are circumstances where the same model needs to be drawn many times with many different sizes.

I don't think you'll find any 3D modelling software that can handle an astronomical range of sizes

selden wrote:Paolo,

Sorry, but providing models with appropriate internal sizes simply is not feasable for astronomical objects.

Some objects are tiny, millimeters in radius, while others are billions of light years in radius. Also, there are circumstances where the same model needs to be drawn many times with many different sizes.

I don't think you'll find any 3D modelling software that can handle an astronomical range of sizes

My mistake in explaining myself! Of course I was referring to multibody artificial objects like probes, shuttles, rovers, artifical satellites, space stations and so...

Even within a solar system, the scale of the units needed is much larger than any 3D program will allow: some objects are smaller than a breadbox (less than 0.1 meter) and others are larger than the Sun (hundreds of thousands of km).

e.g. "microsatellites" to solar magnetic fields.

Paolo wrote:

selden wrote:Paolo,

Sorry, but providing models with appropriate internal sizes simply is not feasable for astronomical objects.

Some objects are tiny, millimeters in radius, while others are billions of light years in radius. Also, there are circumstances where the same model needs to be drawn many times with many different sizes.

I don't think you'll find any 3D modelling software that can handle an astronomical range of sizes

My mistake in explaining myself! Of course I was referring to multibody artificial objects like probes, shuttles, rovers, artifical satellites, space stations and so...

The Radius property is critical to Celestia, because loading of a mesh needs to be deferred until an object is actually large enough to see. In addition to behaving as a scaling factor, the radius specified in the ssc file tells Celestia how large an object is without having to load the mesh file. Now, it would be possible to keep using radius as a size hint without using itto scale the model. Then, the add-on creator would be responsible for ensuring that the radius in the ssc file matched the actual size of the model. If there's enough demand, I may add a mechanism for disabling mesh size normalization and rescaling by the radius.

--Chris

Personally, I'm not interested in this feature. There are MUCH more important things to do for Celestia right now, and I don't even see how this scale feature would be usefull to me. It's already okay the way it is now.

chris wrote:In addition to behaving as a scaling factor, the radius specified in the ssc file tells Celestia how large an object is without having to load the mesh file. Now, it would be possible to keep using radius as a size hint without using itto scale the model. Then, the add-on creator would be responsible for ensuring that the radius in the ssc file matched the actual sizes

I, for one, am quite happy with the way we do it now, so unless there are advantages i am unaware of...

- rthorvald

Cham wrote:Personally, I'm not interested in this feature. There are MUCH more important things to do for Celestia right now, and I don't even see how this scale feature would be usefull to me. It's already okay the way it is now.

That's the sort of feedback I want . . . The mesh positioning would be useful for some of my projects, but it sounds like it can be lower priority. And I'm pleased to hear that most people aren't having trouble with mesh scaling, because I'd rather not mess with that.

--Chris

Actually, the only problem I'm experiencing with model placing is the orientation. I'm often getting some "random" orientation when I try to place a spaceship in orbit around some exoplanet, for example. But for the moment, this is reallly a minor problem. Please, put your time on more important features and bug fixes.

Well scaling pieces can be a bit annoying but it's not so problematic; actually very few models propose animated pieces.

Concerning the actual MeshCenter, it's quite usefull if you want to call attention on a certain point of the model; in the case of the shuttle for example centering the model near the cockpit make much sense than having the center in the middle of the model...

Chris,

Mesh centering and group scaling is not really a problem for us because there are alternative ways to do what we want.

Here, we made a top-level software that computes mesh centering by generating invisible object as you said. It also manages scaling by applying display ratio to a group of objects (typically spacecraft and solar panel).

So, as this software now exists to "hack" this lack of features, we can set this work as low priority as well. Solving these issues will just change internal ssc generation.

Bye

Mathieu (spacebel)

chris wrote:Perhaps this isn't a big problem. In the case of this spacecraft, the modeler can easily check the extents of the solar panels and body, then set the radius appropriately. I'd like to hear how much of a problem it is. My intuition is that solving the mesh centering problem would eliminate most of the positioning headaches.

In my experience (because my addons are constructed from multiple related pieces) the most frustrating part is that Celestia must be restarted in order to see the effect of an SSC modification. Often, a bit of simple maths will shortcut the number of iterations, but with complicated geometries I would often have to resort to trial and error to get it's position or radius just right, in relation to other objects.
This invariably results in multiple restarts and has a big impact on addon development time. (Imagine if you had to restart your IDE, rather than just re-compile, every time you wanted to see the effect of a code change. )

IMO, the feature that would go a long way towards easing this process for addon creators would be the ability to reload a specific SSC,STC,XYZ file (or list of files) on the fly after making a change, and see the object resized, relocated, or re-orientated dynamically in front of your eyes (based on the new SSC definition).

I'm pretty sure this is already on your todo list anyway.... any comments?

Cheers
CC