Pluto

[chris]

That's an interesting solution. How would you select the texture set to use? Would that be a universe-wide setting or per-body?

Universe-wide would probably make more sense, if the asked for texture set is not available for a given body, simply use the default one.

Yes, I think a universe-wide setting is the answer . . . Certainly for the limit of knowledge surfaces, you wouldn't want to set it per-body. Also, a universe-wide setting is easier to incorporate into cel:// URLs

--Chris

[Christophe]

Yes, I think a universe-wide setting is the answer . . . Certainly for the limit of knowledge surfaces, you wouldn't want to set it per-body. Also, a universe-wide setting is easier to incorporate into cel:// URLs :)

It sure would :-)

It would also be interesting for texture set to be possible as add-ons, that is to define them outside of the body definition.

I was also thinking that once we have a central add-on repository a great feature would be to have a 'provide object' look-up for add-ons. For example you click on a cel:// URL referencing an object that does not exists in your installation, Celestia queries the repository for a list of add-ons providing that body and offers you to download and install one. Wouldn't that be neat?

[granthutchison]

Yes, I think a universe-wide setting is the answer . . . Certainly for the limit of knowledge surfaces, you wouldn't want to set it per-body.

This seems like an excellent option. For the core package you'd get "limit-of-knowledge" and "interpretive" combined with a much smaller overhead than my original suggestion - some small blank overlays and then just the double texture for Pluto (and Charon, I guess, if anyone ever makes an interpretive version from the albedo data).

Grant

[jrobert]

So does this mean that in new versions of Celestia, Pluto and Mercury would have blank areas where data has not been gathered? I'm not entirely clear on this "Limit-of-Knowledge" concept.

[granthutchison]

We're looking for ways to resolve the problem that some folk want to see only what we know to be correct, and others would like to see beautiful interpretations of astronomical data (and probably most would like to see both those things at some time or another).
So the idea is that Celestia would provide nice-looking textures (blank bits of the map filled in with cloned or imaginary data, some sort of detailed surface texture applied to the blurred Hubble map of Pluto, etc), but with the option to blank out the "fake" bits - so that people can see which are real data, and which have been imagined in order to make things look nice.
Perhaps a single keypress would switch you from a fully textured Mercury (half of which would be covered by imaginary data, since we haven't mapped that part) to a model of Mercury with a smooth blank area indicating the unmapped part.
Best of both worlds, it seems to me, as well as being interesting and informative.

Grant

[chris]

It would also be interesting for texture set to be possible as add-ons, that is to define them outside of the body definition.

This is a very good idea . . . Otherwise alternate surface add-ons for planets in the base distribution will require and edit of solarsys.ssc.

I just checked in a change for mask textures. I actually decided to call them overlays. An example:

Code: Select all

"Ariel" "Sol/Uranus"
{
    Texture "ariel.jpg"
    OverlayTexture "ariel-lok.png"
}


The overlay should be a texture with an alpha channel; the base texture shows through where the overlay is transparent. As for a way to declare alternate surfaces, I think that the .ssc format could be extended to allow something like this:

Code: Select all

AltSurface "limit of knowledge" "Sol/Mercury"
{
    Texture "mercury.jpg"
    BumpMap "mercurybump.jpg"
    BumpHeight 4.0
    OverlayTexture "mercury-lok.png"
}


If this is allowed, the for consistency it should also be permittable to start a body definition with the keyword Body. In order to be backward compatible, this wouldn't be enforced of course--there are simply too many add-ons out there to force everyone to change their .ssc files.

I was also thinking that once we have a central add-on repository a great feature would be to have a 'provide object' look-up for add-ons. For example you click on a cel:// URL referencing an object that does not exists in your installation, Celestia queries the repository for a list of add-ons providing that body and offers you to download and install one. Wouldn't that be neat?

That would be insanely cool!

--Chris

[selden]

Chris

Thanks!

It seems to me that Celestia may need an on/off keyboard command associated with overlays so people can see what they're missing.

And, of course, I've already thought of another use for this:
a "cutaway" to show subterranian features. For that usage, it'd be nice if the alpha channel of the overlay could rotate separately from the primary channel, but that can wait for some future major release