T00fri's Titan @ Celestia

[t00fri]

Cham,

If it helps, here's a picture similar to Fridger's but with ambient light turned off.


...

Cham,

to make things more concrete I dumped the first intro
image from the Ciclops Titan animation (their most
recent archive image) and compared it to a similar image
from Celestia.



Chris: is'nt that a nice confirmation of the shadow
pattern we have been waiting for!? Just make the hood
under the ring shadows a little more blue...


Bye Fridger

[granthutchison]

You seem to adhere to the credo that we should refer to visible light all the time. For me this is a rather artificial limitation, since there are so many highly valuable/instructive data in other wavelength bands. So no LOK situation whatsoever!

No, my credo is simply that our baseline, default setting should consistently be to show people what things really look like, wherever that's possible. Behind that, I'm very happy for people to have all sorts of other "eyes" available to them if they choose to deploy those options.

In order to achieve real progress with such a more challenging task, we inevitably have to merge all our diverse know how and DISCUSS actively.

Some discussion points, then:
1) I think that some sort of waveband-of-vision slider, though it would be a fine thing, is unimplementable for lack of data in many instances and prohibitive file sizes where all data are available. So I think we'd need to have just a simple range of specified wavebands, perhaps as alternate textures.
2) But what do we mean by "infrared"? Just the single wavelengths of the Titan views, or the various false-colour composites that are available for other objects?
3) Can we achieve any sort of consistency in the wavebands used for our "infrared" textures? I think this is impossible, since the interesting waveband to observe Titan is a boring waveband for most other places, and most likely has never been used. So do we then have a mishmash of false colour images from various wavebands, and lump them all together as simple "infrared" (of various sorts)? Can we standardize the false colours used by reprocessing the available images? Maybe, but I don't think universally without dumping a lot of detail.
4) As you say, what do we do when no data are available? If we agree some false colour conventions (shades of red for IR, violet for UV), then maybe anything without a defined texture in that waveband could be shaded a uniform bland version of the false colour. But as soon as we adopt a colour convention in this way, we lose some of the waveband detail that we might otherwise be able to display. However, since that waveband detail is likely to vary from object to object (see above), which introduces an inconsistency in display, perhaps we wish to supress it anyway.

Did you really download my most recent clouds addendum??

I suspect not, from what you say. I'll go look.

I put tentatively 3 km as the CloudHeight which I took from a recent ESA caption. But no, there is no solid info, I think.

Cloud thickness is another problem, isn't it? The dense haze may extend a long way below 40km, but won't make it much higher than the tropopause. So Celestia needs some way to specify a lower and upper bound to clouds.

Grant

[t00fri]

You seem to adhere to the credo that we should refer to visible light all the time. For me this is a rather artificial limitation, since there are so many highly valuable/instructive data in other wavelength bands. So no LOK situation whatsoever!

No, my credo is simply that our baseline, default setting should consistently be to show people what things really look like, wherever that's possible. Behind that, I'm very happy for people to have all sorts of other "eyes" available to them if they choose to deploy those options.

In order to achieve real progress with such a more challenging task, we inevitably have to merge all our diverse know how and DISCUSS actively.

Some discussion points, then:
1) I think that some sort of waveband-of-vision slider, though it would be a fine thing, is unimplementable for lack of data in many instances and prohibitive file sizes where all data are available. So I think we'd need to have just a simple range of specified wavebands, perhaps as alternate textures.
2) But what do we mean by "infrared"? Just the single wavelengths of the Titan views, or the various false-colour composites that are available for other objects?
3) Can we achieve any sort of consistency in the wavebands used for our "infrared" textures? I think this is impossible, since the interesting waveband to observe Titan is a boring waveband for most other places, and most likely has never been used. So do we then have a mishmash of false colour images from various wavebands, and lump them all together as simple "infrared" (of various sorts)? Can we standardize the false colours used by reprocessing the available images? Maybe, but I don't think universally without dumping a lot of detail.
4) As you say, what do we do when no data are available? If we agree some false colour conventions (shades of red for IR, violet for UV), then maybe anything without a defined texture in that waveband could be shaded a uniform bland version of the false colour. But as soon as we adopt a colour convention in this way, we lose some of the waveband detail that we might otherwise be able to display. However, since that waveband detail is likely to vary from object to object (see above), which introduces an inconsistency in display, perhaps we wish to supress it anyway.

Did you really download my most recent clouds addendum??

I suspect not, from what you say. I'll go look.

I put tentatively 3 km as the CloudHeight which I took from a recent ESA caption. But no, there is no solid info, I think.

Cloud thickness is another problem, isn't it? The dense haze may extend a long way below 40km, but won't make it much higher than the tropopause. So Celestia needs some way to specify a lower and upper bound to clouds.

Grant

A waveband slider would be nice but clearly this is asked too much. What I was contemplating was definitely more "discrete":

-- various waveband "slots" like UV, visible, H-alpha, Methane, near-IR, IR as a start. Clearly, using alternative textures would be an easy way to get going. The actual wavelength used within a slot could be displayed in the canvas overlay as usual. If you look more closely, you will notice that astronomers have also widely standardized the wavelengths they are using. So it's not all that bad, I think.

--One issue is what to do, if there are images of more than one object that we want to display jointly, but the wavelength of which is somewhat different...

Well, we have to compromise in one way or another. However, in my view there are a number of tolerable options ... Since displays outside of the visible band are necessarily false color, we might well combine some well thought of Celestia standardization with color binning of some sort. I am confident we could find a satisfactory scheme...

Bye Fridger

[selden]

Clearly, using alternative textures would be an easy way to get going.

Only within the solar system, unfortunately.

DSC catalogs don't provide that option for Nebula objects. Nebulas have been observed in standardized wavelengths for a very long time.

[granthutchison]

So it's not all that bad, I think.

And there's the point on which we differ - I think it really is pretty bad . I think it's a huge bog that could suck down all my time for months on end, with little or no satisfaction to be gained from it. So I'm (as you see) exceedingly reluctant to get involved. I will, however, applaud enthusiastically if I get to see you skip across to the far side of this bog even once.

Grant

[t00fri]

Clearly, using alternative textures would be an easy way to get going.

Only within the solar system, unfortunately.

DSC catalogs don't provide that option for Nebula objects. Nebulas have been observed in standardized wavelengths for a very long time.

Right Selden,

that's why I said ...get going;-). But look, we (i.e Christophe and Chris, mainly) have coded the whole multiview thing in a relatively short time. So sure there are solutions.

Bye Fridger

[t00fri]

So it's not all that bad, I think.

And there's the point on which we differ - I think it really is pretty bad . I think it's a huge bog that could suck down all my time for months on end, with little or no satisfaction to be gained from it. So I'm (as you see) exceedingly reluctant to get involved.

What a pity! And why no satisfaction??

I will, however, applaud enthusiastically if I get to see you skip across to the far side of this bog even once.

Grant

I'll take your word for it

Bye Fridger

[granthutchison]

And why no satisfaction??

Because I anticipate something of an unsatisfactory cludge at the end of the day: the trade-offs that you feel will be relatively minor look like they're going to be unpleasant to me. But I'll be very happy if you prove me wrong on this, honestly.

Grant

[Cham]

Cham,

If it helps, here's a picture similar to Fridger's but with ambient light turned off.


...

Cham,

to make things more concrete I dumped the first intro
image from the Ciclops Titan animation (their most
recent archive image) and compared it to a similar image
from Celestia.

Bye Fridger

I'm having a hard time figuring how the rings can cast a shadow like this. What makes me feeling weird, with this shadow, is the circular patern on the north pole (up side) of the planet. I'll have to make a real model of a sphere with a ring around it and cast some real light on them.

[selden]

Cham,

You've been skipping over replies.

Fridger had "ambient light" turned on in Celestia.

The fully circular pattern surrounding the pole is caused by a defect in Celestia. Shadows are being projected through the surface to the far side of the sphere.

This effect is visible when you turn on "ambient light" -- either to low or medium or in a script. It's caused by ring shadows and eclipse shadows being drawn on all of the surfaces that they intersect instead of being drawn on only the first surface. Figuring out which surface is first can be very expensive in CPU time.

If you don't turn on the non-physical ambient light, then the non-physical shadows are not visible.

[Matt McIrvin]

The fully circular pattern surrounding the pole is caused by a defect in Celestia. Shadows are being projected through the surface to the far side of the sphere.

This effect is visible when you turn on "ambient light" -- either to low or medium or in a script. It's caused by ring shadows and eclipse shadows being drawn on all of the surfaces that they intersect instead of being drawn on only the first surface. Figuring out which surface is first can be very expensive in CPU time.

Perhaps so, but to fix this bug, Celestia wouldn't have to figure out which surface is first. It would just have to apply the ambient brightness to eclipse and ring shadows.

This would change the current behavior-- eclipse and ring shadows would no longer be black in the presence of ambient lighting-- but to the extent that ambient light is pseudo-physical, it doesn't make any sense to make them black anyway. An object that is actually ambiently lit will tend to show the lighting even in shadows projected on it. In this way ambient light would somewhat more accurately simulate such physical phenomena as, say, planet-shine and ring light.

[Matt McIrvin]

...That said, I should add that I know little of OpenGL, and it's possible that there is some API-specific reason it couldn't be done this way, in which case disregard the preceding.

[Evil Dr Ganymede]

This would change the current behavior-- eclipse and ring shadows would no longer be black in the presence of ambient lighting-- but to the extent that ambient light is pseudo-physical, it doesn't make any sense to make them black anyway. An object that is actually ambiently lit will tend to show the lighting even in shadows projected on it. In this way ambient light would somewhat more accurately simulate such physical phenomena as, say, planet-shine and ring light.

"earthshine" (or saturnshine) effects are called "Radiosity" in 3D rendering circles. It's when you get light bouncing off other objects in a scene and illuminating the shadows. It can be very computationally expensive to figure out (which is why Ambient Light could be a handy kludge for it, but it's a bit too simplistic).

[maxim]

... considerations about multiband modi ...

I am a strong advocator of visual multiband modi in celestia.
But as I'm not very familiar with the background of technical realization in all-days-work, I've found it quite hard to investigate in a broad overview on this issue. If someone out there could give a brief explanation of actual usage and constraints on the subject, I would really appreciate. I can't discuss things without knowing some more about it.

more substantial:
- are there (well defined?) commonly used wavebands? which?
- is there a standard colorisation? what is used commonly? what are the considerations on coloring?
- are there sets of certain filters used? does their parameters limit waveband visualisation to a discrete amount?
- what are typical band combinations? for visual range there is R,G and B? are there similar combinations in other ranges?
- are non visual bands usually displayed monochromatic?
- is R and nearIR a common combination?
- is B and nearUV a common combination?
- DSOs seems to be usually displayed on a combination of atomic bands of H, He, Fe or ...? are these combination artificial in a way that there is no (implicit?) standardisation?

Answers to these kind of questions would allow to define a discrete number of bandslots and an algorithmical approach to combination methods. This way there could be indeed a setting that allows showing the visual band of a body together with the IR band of another one:

Combining R,G,B (which exists only for body A) and IR (wich exists only for body B) would give such a result if there is an agreement about wavelength shift/compression.

Having a well-defined scheme (as is with RGB combination) we can go on for implementing details or discussing an extented usage of alternate textures IMHO.

maxim

[maxim]

I see that there's no one out there who has fast answers to these questions.
If I'll gonna find some time, I will investigate for myself more deeply - but that won't be too soon.

maxim

[Evil Dr Ganymede]

Just as another datapoint...

Personally I don't see the point of having a dedicated multispectral viewer. I think if you want to look at alternative maps of the surface then that's what alternate textures are for - just use those. Besides, it's not like we have multispectral data for everything anyway.

I think it's also beyond Celestia's purpose. I see this as a tool for simulating and flying around the solar system and the universe for fun and general educational purposes, not for rigorous scientific analysis. Worrying about throwing in multispectral views for everything seems to be pushing it out of the "amateur interest" league and into "professional scientist" league. And most people, frankly, are not going to bother looking at that side of it.

It'd be fine as an optional add-on I think (or an alternate version Celestia, like marc's Mostly Harmless etc), but I don't see why it needs to be included in the official version.

Just IMO, etc.

[selden]

There are some peoplw who are very interested in using Celestia as a scientifically accurate 3D presentation system. Unfortunately, many of them are unwilling or simply don't have the time to participate in a public Web forum like this one.

The ability to directly access FITS data files that include the necessary spectrographic information might help in this regard.

[t00fri]

Selden:
---------

Of course, I agree enthusiastically with what you wrote...

Maxim:
---------

Indeed I have plenty of arguments available, but unfortunately, I am extremely short with time until end of next week...That's why I did not respond. Sorry.

Bye Fridger

[Guest]

I'd quite like some kind of multiwavelength texture stuff, although I don't mind using AlternateTextures. For example the usual images of Venus cloud textures include ultraviolet data to bring out cloud details, so using multiwavelength this facet could be brought out.

The implementation of such a feature would probably require a large-scale restructuring of the way textures are organised and handled, which would be a major version number increase I would suspect.

[selden]

One possibility would be simply to agree on a convention for the names of texture images and of their AltSurface entries when they involve something other than the full band of visual wavelengths.

For example (just off the top of my head: this is awkward but reasonably precise)

1. place the wavelength specifications last in the filename or AltSurface name.

2. specify a range of wavelengths (a waveband) by separating their bounding frequencies by a hyphen

3. an underscore takes the place of a comma:
3a. specify specific wavelengths by separating their frequencies by an underscore
3b. separate wavebands by an underscore
3c. prefix the list of wavelengths by an underscore

4. suffix each and every wavelength by the appropriate unit designation

Thus a set of compatible surface texture images might be named

EagleNebula_1000nm-2000nm.jpg
SwanNebula_1000nm-2000nm.jpg
TriffidNebula_1000nm-2000nm.jpg

and the AltSurface DSC catalog for selecting them would be

Code: Select all

AltSurface  "_1000nm-2000nm" "EagleNebula" {
                Texture "EagleNebula_1000nm-2000nm.jpg" }
AltSurface  "_1000nm-2000nm"  "SwanNebula" {
                Texture SwanNebula_1000nm-2000nm.jpg" }
AltSurface  "_1000nm-2000nm"  "TriffidNebula" {
                 Texture "TriffidNebula_1000nm-2000nm.jpg" }


Then to see the 1000-2000 nm images of all the listed Nebulas, just select the AltSurface _1000nm-2000nm for any of them.


Of course, this particular example won't work in currently available versions of Celestia since DSC files and Nebula definitions don't support either AltSurface or Texture declarations.