Simplified Mesh Placement Proposal

[chris]

Celestia add-on creators face some difficulties when trying to place mesh objects precisely relative to each other. Celestia's 'normalization' of mesh objects is the cause of some of these problems. When a mesh is normalized, it is scaled and centered so that its longest axis fits into a sphere with the specified radius of the object. The common workaround is to add identically-sized invisible bounding box to objects that will be positioned close to each other. This ensures that the models will effectively share the same coordinate system.

While effective, creating these bounding boxes adds extra work for add-on creators. It also means that meshes end up getting incorrectly flagged as translucent for purposes of depth sorting. I propose the addition of two new ssc properties to solve the problem of mesh placement without resorting to adding bounding boxes:

Code: Select all

# defaults to true for backward compatibility
NormalizeMesh <boolean>

# defaults to 1
MeshScale <number>


When an object has NormalizeMesh false specified, no automatic scaling and recentering of the mesh is done. The add-on creator must make sure to set the Radius of the object to a value large enough to contain it.

MeshScale exists to convert the internal units of the model into kilometers as required by Celestia. For example, it is much more convenient to build a spacecraft in a system where the unit is one meter instead of one kilometer. For such a model, you would specify the MeshScale as 0.001.

Neither of these additions would affect backward compatibility.

--Chris

[BobHegwood]

So do I understand this situation correctly here Chris?

Both of these commands can be used at the same time?
In other words, we could utilize the "NormalizeMesh <boolean>," for backward compatibility as well as the "MeshScale <number>" for newer add-ons?

If that's the case, that sounds like a great way to encourage more modeling.

Thanks, Bob

[chris]

So do I understand this situation correctly here Chris?

Both of these commands can be used at the same time?
In other words, we could utilize the "NormalizeMesh <boolean>," for backward compatibility as well as the "MeshScale <number>" for newer add-ons?

If that's the case, that sounds like a great way to encourage more modeling.

Right, both can be used at the same time. However, I don't think that it makes too much sense to use MeshScale along with MeshNormalize true.

Mesh normalization was probably a mistake. If there weren't concerns about backward compatibility with old add-ons, I would make NormalizeMesh false the default, and make things easier for new add-on creators. But add-on compatibility is extremely important for Celestia, so this isn't a possibility.

--Chris

[selden]

I think that these specifiers will help a lot!

However, a problem I have with most of the models in the Addon I'm currently working on is that1 unit = 1 foot

[chris]

I think that these specifiers will help a lot!

However, a problem I have with most of the models in the Addon I'm currently working on is that1 unit = 1 foot

Well, then you just need to use this:

Code: Select all

MeshScale 0.0003048


I could make it even easier and allow distance units to be given as strings, e.g.:

Code: Select all

MeshScale "ft"


--Chris

[BobHegwood]

Right, both can be used at the same time. However, I don't think that it makes too much sense to use MeshScale along with MeshNormalize true.

Mesh normalization was probably a mistake. If there weren't concerns about backward compatibility with old add-ons, I would make NormalizeMesh false the default, and make things easier for new add-on creators. But add-on compatibility is extremely important for Celestia, so this isn't a possibility.

--Chris

Well, as usual I probably just did NOT make myself understood here correctly. Let's see...
What I'm trying to get at is having the ability to keep my current (old-style) add-ons working like you have described, but also being able to add new add-ons which have been built within the new framework presented here. In order for this to be possible, are we talking about adding a compatibility line to every old add-on? Or, are we simply placing something in the celestia.cfg file which would allow the old add-ons to work?

On the other hand, perhaps you mean that any new add-on built under the new structure would require a line of code in order to allow for the new rendering.

Do you see what I'm trying to get at here? Sorry, I know I'm a Bozo.

[chris]

Right, both can be used at the same time. However, I don't think that it makes too much sense to use MeshScale along with MeshNormalize true.

Mesh normalization was probably a mistake. If there weren't concerns about backward compatibility with old add-ons, I would make NormalizeMesh false the default, and make things easier for new add-on creators. But add-on compatibility is extremely important for Celestia, so this isn't a possibility.

--Chris

Well, as usual I probably just did NOT make myself understood here correctly. Let's see...
What I'm trying to get at is having the ability to keep my current (old-style) add-ons working like you have described, but also being able to add new add-ons which have been built within the new framework presented here. In order for this to be possible, are we talking about adding a compatibility line to every old add-on? Or, are we simply placing something in the celestia.cfg file which would allow the old add-ons to work?

No modification is required in order to make old add-ons work: no change to celestia.cfg, and no modifications of the add-ons themselves. I've got Ulrich's and your interest in mind, here (As well as that of all the other Celestia users who don't want a bunch of their add-ons to stop working when they upgrade to a new version of Celestia.)

On the other hand, perhaps you mean that any new add-on built under the new structure would require a line of code in order to allow for the new rendering.

This is indeed what I meant. Only new add-ons that wish to use the simplified mesh placement methods will need the extra line of code.

--Chris

[BobHegwood]

Thanks very much for the explanation to the Brain-Dead.
I absolutely love the idea in that case. Hee, hee. Sorry, but we are getting very busy on the ML lately so this would help immensely.

As always, Sir, I thank you for all that you do here. Much appreciated by us lesser mortals.

[Guckytos]

I think that these specifiers will help a lot!

However, a problem I have with most of the models in the Addon I'm currently working on is that1 unit = 1 foot

Well, then you just need to use this:

Code: Select all

MeshScale 0.0003048


I could make it even easier and allow distance units to be given as strings, e.g.:

Code: Select all

MeshScale "ft"


--Chris

Hmm, I would like it more if Celestia would stick to SI basic units and not use imperial or american units, if possible.
Otherwise things could get mixed up and lead to mars probes entering the terrain and not the orbit as planned

Just my 2 cents.

Best regards,

Guckytos

[BobHegwood]

Hmm, I would like it more if Celestia would stick to SI basic units and not use imperial or american units, if possible.
Otherwise things could get mixed up and lead to mars probes entering the terrain and not the orbit as planned

Just my 2 cents.

Best regards,
Guckytos

For what it's worth here, I agree completely with this sentiment. Although I am not all that familiar with kilometers, I'm learning.
It would indeed also muddy the waters quite a bit for prospective add-on creators.

[cartrite]

I just built the "unnormalized-mesh.patch" and tested to see what if anything it would do to my 3dmars meshes. I found that if I used

Code: Select all

NormalizeMesh false

it made the model disappear. There were no errors in the console output either. Using

Code: Select all

NormalizeMesh true

had no affect and the models worked normally. I also tried

Code: Select all

NormalizeMesh "false"

and that worked. So the it seems that the quotes are necessary. Not sure why the model disappears without the quotes. My question is by using quotes, is this disabling the code? Is the code ignoring the NormalizeMesh declaration because of the quotes or is it ignoring the NormalizeMesh declaration because it doesn't have quotes?
cartrite

[chris]

I just built the "unnormalized-mesh.patch" and tested to see what if anything it would do to my 3dmars meshes. I found that if I used

Code: Select all

NormalizeMesh false

it made the model disappear. There were no errors in the console output either. Using

Code: Select all

NormalizeMesh true

had no affect and the models worked normally. I also tried

Code: Select all

NormalizeMesh "false"

and that worked. So the it seems that the quotes are necessary. Not sure why the model disappears without the quotes. My question is by using quotes, is this disabling the code? Is the code ignoring the NormalizeMesh declaration because of the quotes or is it ignoring the NormalizeMesh declaration because it doesn't have quotes?

The quotes shouldn't be necessary. All that they'll do is cause an error that is ignored and NormalizeMesh will have it's default value: true.

The Mesh is probably disappearing because the vertex positions are in the wrong units--the mesh is either being rendered too small, or it's much too large. What is the range of the vertex positions?

--Chris

[cartrite]

I think the x and y are between -1 and 1 and the z are around 1 + or - the height values for mars but in scale with the x and y. This is what Blender uses. The radius in the ssc is 3396. They do appear tiny if I ever used Anim8or to open them. Also In OGL2 they seem completely invisible. Other render paths show a tiny have sphere that I couldn't approach to see much. It was the size of a normal star when scaled discs are used.

So the quotes are causing the statement to be ignored. I thought that mite have been the case.
Anyhow it's good to know that I could use NormalizeMesh true . That works just in case the default gets changed to false.
cartrite

[chris]

I think the x and y are between -1 and 1 and the z are around 1 + or - the height values for mars but in scale with the x and y. This is what Blender uses. The radius in the ssc is 3396. They do appear tiny if I ever used Anim8or to open them. Also In OGL2 they seem completely invisible. Other render paths show a tiny have sphere that I couldn't approach to see much. It was the size of a normal star when scaled discs are used.

That's the problem then--when you have NormalizeMesh set to false, the actual size of these objects in Celestia is one kilometer. You need to either modify the meshes to be Mars-sized (x and y between -3396 and +3396) or add a MeshScale 3396. Right now, the 1 unit in your mesh is 1 Mars radius = 3396 km.

So the quotes are causing the statement to be ignored. I thought that mite have been the case.
Anyhow it's good to know that I could use NormalizeMesh true . That works just in case the default gets changed to false.

As much as I'd like to make NormalizeMesh false the default, it would have the really bad side effect of breaking almost every existing add-on that used meshes So, it's not really a possbility.

[cartrite]

That's the problem then--when you have NormalizeMesh set to false, the actual size of these objects in Celestia is one kilometer. You need to either modify the meshes to be Mars-sized (x and y between -3396 and +3396) or add a MeshScale 3396. Right now, the 1 unit in your mesh is 1 Mars radius = 3396 km.

As much as I'd like to make NormalizeMesh false the default, it would have the really bad side effect of breaking almost every existing add-on that used meshes So, it's not really a possbility.

I tried the MeshScale 3396 but that caused some side effects too. One problem that I have is the meshes I created of Mars are not spheres. They are ellipsoids with radii that vary with the lat/lon coordinates. The atmosphere is a sphere so it gets clipped. I am getting closer with MeshScale 3236 but the atmosphere is still getting clipped slightly. I guess maybe I should see if I can raise the atmosphere.

cartrite

[cartrite]

Another side affect of using this code is that for some reason, I get twice the frame rates. I've been checking all night but I can't find any other reason I would get slower rates with the clean svn version 4446. Is this real or am I missing something? I get this bump up in frame rates even though I got NormalizeMesh true.
cartrite

[chris]

Another side affect of using this code is that for some reason, I get twice the frame rates. I've been checking all night but I can't find any other reason I would get slower rates with the clean svn version 4446. Is this real or am I missing something? I get this bump up in frame rates even though I got NormalizeMesh true.

That's surprising, but there is a possible explanation. The NormalizeMesh changed overlapped another change I was working on to fix some planetshine related bugs. The fix keeps dim planetshine light sources from being used in shadow calculations since they don't cast noticeable shadows on a planetary scale. So there's some extra work that's avoided, and that may explain the speedup. I'm still surprised at the magnitude of it though. How many frames per second were you getting before and after the patch?

--Chris

[cartrite]

How many frames per second were you getting before and after the patch?

--Chris

It is very consistent. Almost like clockwork. A very high resolution model I've been running is getting 14.1 frames per second with svn 4446 and gets 33.5 fps with the unnormalized-mesh.patch.
cartrite

[selden]

Applying the mesh normalization patch to r4449, the patch is compatible with Fridger's new globular cluster code: neither breaks the other.

I was somewhat surprised to see the new planetshine code working between Mesh objects in separate orbits around the sun. It'd be nice if eclipse shadows worked, too: shine is cast between objects which should be completely eclipsed. But that can probably wait until v1.7.


Here's the SSC code I used for testing:

Code: Select all

"sphere" "Sol" { Radius 1 EllipticalOrbit { SemiMajorAxis 1 Period 1}}

"mesh1" "Sol" { Radius 1 Mesh "bar.cmod" Color [ 1 0 0]
  EllipticalOrbit { SemiMajorAxis 1.00000001 Period 1}}

"mesh2" "Sol" { Mesh "bar.cmod"  Color [ 0 1 0]
NormalizeMesh true
MeshScale 1
EllipticalOrbit { SemiMajorAxis 1.00000002 Period 1}}

"mesh3" "Sol" { Mesh "bar.cmod"  Color [ 0 0 1 ]
NormalizeMesh false
MeshScale 1
EllipticalOrbit { SemiMajorAxis 1.00000003 Period 1}}

"mesh4" "Sol" { Mesh "bar.cmod"  Color [ 1 1 0]
NormalizeMesh false
MeshScale 0.1
EllipticalOrbit { SemiMajorAxis 1.00000004 Period 1}}

"mesh5" "Sol" { Mesh "bar.cmod"  Color [ 0 1 1]
EllipticalOrbit { SemiMajorAxis 1.00000005 Period 1}}


And here's what it looks like.

[chris]

How many frames per second were you getting before and after the patch?

--Chris

It is very consistent. Almost like clockwork. A very high resolution model I've been running is getting 14.1 frames per second with svn 4446 and gets 33.5 fps with the unnormalized-mesh.patch.
cartrite

That's a remarkable speed increase . . . Any idea what you got with 1.5.1?

--Chris