Celestia Forums

Three bugs in one!

1. Planetary moons do not eclipse the planetary rings.

2. Planetary rings do not take Emissive = true.

3. When a body eclipses another, the eclipsed body's night texture only shows on the "dark anyway" side, i.e. the night side. This is the case even with objects where the entire eclipsed body is covered.

What you describe are not bugs, but rather features that have not yet been implemented.

Why would you want your rings to be emissive true? Chris is working on improving the ring lighting, but nothing along the lines of emissivity as far as I know. Not a lot of reason to, rings are not emissive true in reality anyway.

Mneme wrote:3. When a body eclipses another, the eclipsed body's night texture only shows on the "dark anyway" side, i.e. the night side. This is the case even with objects where the entire eclipsed body is covered.

Typically on Earth, during a total Solar eclipse, I don't believe that the street lights are turned on, and likewise I can't remember ever having to turn on house lights during such an event.

I guess if an entire hemisphere of a fictional body (with a technologically advanced civilization) was eclipsed for an extended period of time, then you could could argue that the lights are more likely be switched on.
However...the reality (at least in our Solar System) is that any bodies that experience the scenario you describe are of course not currently populated, and are likely to be too small to have sufficient gravity to be populated at any time in the future. In fact, even if they were large enough, the fact that they experience total hemisphere blackouts might well be a deal-breaker for any proposed colonization anyway.

So as the scenario is a totally fictional one, I imagine it's unlikely that this would be implemented in Celestia.

Perhaps in a few thousand years, when the human race has spread throughout the solar system, this might be a realistic scenario.
I'll be glad to be proved wrong.

Glowy rings! (Accretion discs, etc.)

http://www.tarazedi.com/files/wanderer.png

The object in question that made me notice this was actually a glowy volcanic-hellpit sort of thing with the nightside lights being lava. That doesn't turn off in the daytime.

http://www.tarazedi.com/files/garden.png

I hadn't thought of volcanoes and lava, etc. Io would be the obvious example in the Solar System.

As an experiment, I substituted Earth's lights onto Io, and it appears to me that the nightlights are in fact active when Io is eclipsed by Jupiter, just very much dimmer:

If you want see this for yourself, just add the NightTexture line to Io's definition as follows:

and click on this URL:
cel://PhaseLock/Sol:Jupiter:Io/Sol/2010-06-06T06:19:24.33800?x=7+R5sm1GAg&y=9F0skWou5////////////w&z=DOz0e72vKA&ow=0.0987428&ox=-0.0165912&oy=0.27068&oz=-0.957448&select=Sol:Jupiter:Io&fov=40.5545&ts=1&ltd=0&p=0&rf=368007&lm=57348&tsrc=0&ver=3

My guess is that the eclipse shadows are being drawn after the NightTexture, and it's effects are being applied to all textures, (including the NightTexture).

It would seem logical that eclipse shadows should only darken the standard textures, but not the emissive NightTexture.

In light of this (no pun intended), it does seem that you have a valid issue here.

CC.

I'm not sure it's quite that way either actually. On my screen, Inferno has this going on:

Nightside: night texture is normal.

Dayside: night texture fades out at terminator; about 30* into the dayside the night texture is completely invisible. This would be the normal behavior. This is the same behavior when eclipsed. The night texture applies with a fadeout exactly as it would if it were uneclipsed, only it's fading out into blackness rather than dayside textures. It's not that the planetary shadow is overlaying the night texture, it's just that as far as the night texture knows it's still fading into the (invisible) dayside texture.

Hi Mneme,

Have you checked this eclipse-shadow behaviour using different Render Paths? Just press Ctrl+V a few times.

On my machines, Multitexture and OpenGL Vertex produce something similar to what Chuft-Captain's picture shows. But the OpenGL 2.0 Render Path makes the shadow disparity disappear and makes everything look right.

Hope this helps.

-Gary

I was using OpenGL 2.0 I believe.

Multitexture and OpenGL 2.0 both give me the same behavior I described. OpenGL Vertex is broken for me (the moon actually has dayside light and a pure black eclipse circle like an annular eclipse even though it's total, and Basic is what I expect (not much).

Mneme,

There's not a lot of point describing to us what happens with your addon, as we don't have it, (We could go around in circles for days comparing apples with oranges as there's too many variables involved.)

For us to help, you need to firstly use the standard test case I provided above with Io, and show us (ie. with pictures) what's happening in your different render paths (and with different ambient light settings).
(It literally takes a couple of minutes to create the test case above)
(My settings in the picture above were render path - Multitexture,, and ambient light = medium)

So, step 1 is to confirm the same behaviour on your machine and on ours,...and this is very important: with the same test case.

That process will identify whether the issue is with Celestia's shading in general, or with a specific render path.

Whether there's also errors in your addon is another issue, which can be addressed later, but firstly we need to remove the addon from the equation.

CC

Io with earthnight, OpenGL 2.0, Jupiter-facing hemisphere. Nightside lights exhibiting same behavior as in my add-on.



Io with earthnight, OpenGL 2.0, non-Jupiter-facing hemisphere. Nightside lights normal.



Io with earthnight, OpenGL Vertex, Jupiter-facing hemisphere. Same behavior as in my add-on.

This seems to confirm what I said earlier, that the nightlights are being obliterated by the eclipse shadow. The onset of the eclipse from this viewpoint, makes it obvious what's occurring: cel://SyncOrbit/Sol:Jupiter:Io/2010-06-06T06:17:41.95908?x=C03HH56JAg&y=Gxh8i6NTAw&z=nxvXNHuHLw&ow=0.984735&ox=0.0293912&oy=0.0131209&oz=0.171058&select=Sol:Jupiter:Io&fov=40.5545&ts=4&ltd=0&p=0&rf=368007&lm=57348&tsrc=0&ver=3

I assume you had no ambient light in these shots? Try changing to Render>Ambient->Medium and I suspect you'll find that the NightTexture is present, but very dim in the eclipsed area..

CC

ps. It would be helpful if you could use my celURL which shows lit (bot-left), unlit (right), and eclipsed (top-left) portions in the same scene, which would allow a direct comparison of what you see compared to me from the exact same viewpoint.

Here's another version of it: cel://PhaseLock/Sol:Jupiter:Io/Sol/2010-06-06T06:19:16.13724?x=7eR5sm1GAg&y=AV4skWou5////////////w&z=Aez0e72vKA&ow=0.0987428&ox=-0.0165912&oy=0.27068&oz=-0.957448&select=Sol:Jupiter:Io&fov=40.5545&ts=1&ltd=0&p=1&rf=302471&lm=57348&tsrc=0&ver=3
and the view (showing the terminator) with 3 different ambient light settings:

The first view appears to reflect exactly what you are seeing...
(click the image to enlarge)

...As the ambient light increases it becomes apparent that the NightTexture is in fact being displayed to some degree in the eclipsed region (top left)....
...With a further increase in ambient level, it becomes obvious that the NightTexture is being muted to varying degrees in the eclipsed region depending on the ambient light level. (In the Ambient light=None setting the loss appears to be complete)
This seems to support my theory that the eclipse shadow is subtracting from the NightTexture, whilst IMO the NightTexture should be unaffected by the eclipse shadow (only non-emissive textures should be altered by an eclipse).

I suspect it's also quite an easy fix,... perhaps just involving a change in the order in which NightTextures and Eclipse Shadows are drawn by the renderer, or perhaps more generally preventing emissive channels from being muted by eclipses ... which might actually be a better solution as it would correctly handle emissive parts of spacecraft (which don't make use of the NightTexture statment).

EDIT: I've created a sourceforge bug report for this: https://sourceforge.net/tracker/?func=detail&aid=3011919&group_id=21302&atid=121302

Just my contribution following Chuft link. Celestia 1.60, though:
render path multitexture, ambient light medium:


render path OpenGL 2.0 ambient light medium:

--- edit ---

john Van Vliet wrote:

well people tend to be outside .

...burning their retinae out. LOL