Simplified Mesh Placement Proposal

[chris]

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.

Thanks for doing this testing, Selden.

Regarding planetshine, I spent a significant amount of time making it work between objects with no orbital association. I wanted to see interplanetary spacecraft illuminated by planets, even though the spacecraft orbits were heliocentric. The planetshine code is very general, while the eclipse detection code is more of a special case hack left over from the earlier days of Celestia. I intend to address the problem in 1.7.0 and allow eclipse shadows to be case between any two bodies.

Code: Select all

Here's the SSC code I used for testing:

[code]"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.[/quote]

Excellent test. Everything looks sized as expected.

--Chris

[cartrite]

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

--Chris

That same model gets about 28 fps with 1.5.1 KDE built from source.
cartrite

[duds26]

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

That foot doesn't need to be shortened to ft,
it is hardly more work to type and new people will faster understand what it means.

[selden]

Personally, I think it's better to stick with SI units and use kilometers in Celestia. The conversion from feet (or inches) to km is easy enough.

(The reference that I used for creating the spacecraft models in some of my older addons used inches for almost everything. As a result, I used 3D units of 10 inches.)

[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

That foot doesn't need to be shortened to ft,
it is hardly more work to type and new people will faster understand what it means.

At least for now, only numeric values are allowed for MeshScale. There are about 3281 feet in a kilometer, so if the mesh vertex positions are in feet:

MeshScale 0.0003048

(since 1/3281 = 0.0003048)

--Chris

[cartrite]

I'm not sure what is causing the increased frame rates. I thought it had something to do with this code update but after playing around today with these reference markers, the frame rates dropped again. As far as I can tell, if I turn some features off or set textures to medium and exit the program and restart it I get better frame rates on this complex model. Turning features off or lowering the resolution of the textures does not change anything while the program is running. I also think I noticed that if I start the program with features off or textures at medium resolution, that I can increase the texture resolution or turn everything on and that does not affect frame rates either. Go figure.
So if I start Celestia and get high frame rates, they stay high. But if I start Celestia and the frame rates are lower for whatever reason, they stay lower while the program is running.
cartrite

[symaski62]

Code: Select all

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

"mesh1" "Sol/TEST" {
  Radius 1 
  Color [ 1 0 0]
  EllipticalOrbit {
  SemiMajorAxis 3
  Period 24
  }
}

"mesh2" "Sol/TEST" {
Color [ 0 1 0]
NormalizeMesh true
 Radius 0.5 #MeshScale 1
EllipticalOrbit {
SemiMajorAxis 6
Period 24
}
}

"mesh3" "Sol/TEST" {
  Color [ 0 0 1 ]
NormalizeMesh false
Radius 0.5 #MeshScale 1
EllipticalOrbit {
SemiMajorAxis  9
Period 24
}
}

"mesh4" "Sol/TEST" {
  Color [ 1 1 0]
NormalizeMesh false
Radius 0.05 #MeshScale 0.1
EllipticalOrbit {
SemiMajorAxis 12
Period 24
}
}

"mesh5" "Sol/TEST" {
  Color [ 0 1 1]
EllipticalOrbit {
SemiMajorAxis 15
Period 24
}
}

TEST

[duds26]

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"


Please make it possible to write the following strings: m and km !
--Chris

[duds26]

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

So this means that models that are modeled and have sizes will be translated into celestia with their correct sizes and scale?

And please make something for checking compatability, for that Celestia can look for what version of celestia an addon is made.
Something like: CelestiaVersion = x.y (eg CelestiaVersion = 1.5)
That must be present in a .cfg file in the corresponding folder of the addon with a CelestiaVersion line or something like that.

All addons that have such a tag can be threated differently by celestia, so there is no garbage left for new add-on creators.
And if there is no such tag, celestia can assume it's for celestia 1.5 or something like that, to keep compatibility for older addons.