Celestia Forums

OK. With Pre5, I ditched the old AlfCen code I had and used the default that came with Celestia, and used the following ssc for the planet:



Now, I have Prometheus at 4 AU from A, and Polyphemus (a twin placeholder planet) at 0.4 AU from A.

For Prometheus - now at 4 AU from A - I can finally see some illumination from B - even when B is at 35 AU, with no ambient, the "dark side" (from A) is still just barely above black. This is demonstrated in the link below. B is directly behind the camera, and you can see the darkside illumination from that star.

cel://PhaseLock/Rigel%20Kentaurus%20A:Prometheus/Rigel%20Kentaurus%20B/2193-01-14T22:18:26.67324?x=MBzESHNCztHEG+f//////w&y=EIVwzksa9VXa69L//////w&z=EI5IzRoZbt8yPio&ow=-0.547743&ox=0.086026&oy=-0.472275&oz=-0.685225&select=Rigel%20Kentaurus%20B&fov=22.894060&ts=10000.000000<d=0&rf=37651&lm=3


For Polyphemus, at 0.4 AU from A - I see no illumination from B at all. What's more, I see no illumination from B at all even when there is no illumination from A visible at all - even when B is at its closest approach of 11 AU! This is demonstrated below.

cel://PhaseLock/Rigel%20Kentaurus%20A:Polyphemus/Rigel%20Kentaurus%20B/2193-02-09T10:42:13.25412?x=YDOExE5ARoyVG+f//////w&y=lFG5Bg9dgdDb69L//////w&z=CAgy9fA4l+QOPio&ow=0.659355&ox=0.347901&oy=-0.052884&oz=-0.664394&select=Rigel%20Kentaurus%20B&fov=27.827868&ts=10000.000000<d=0&rf=37651&lm=3

There's obviously no illumination on the darkside from B there (which is again directly behind the camera, and at its closest to the planet), even though the planet is barely lit by A in this view.

Now, a thin crescent illuminated by A at Polyphemus is surely not going to drown out all the illumination from B is it? I know that it's supposed to be showing what our eyes would see, but if A is entirely eclipsed by Polyphemus, then surely the only illumination you'll see is from B. And you should be able to see that.

It seems to be that one solution to this would be to have a phase angle dependence on the apparent visibility of the hemisphere illuminated by the companion. If the phase angle is low (i.e. both stars are behind the camera), then the illumination of the closer star will drown out any illumination from the further one. If the phase angle is near 180 degrees (i.e. the planet is between A and the camera, and B is behind the camera) then illumination from B will dominate and become more visible since A isn't illuminating much of the visible surface of the planet.

Is this possible to implement? I think it'd produce more realistic results.

Evil Dr Ganymede wrote:It seems to be that one solution to this would be to have a phase angle dependence on the apparent visibility of the hemisphere illuminated by the companion. If the phase angle is low (i.e. both stars are behind the camera), then the illumination of the closer star will drown out any illumination from the further one. If the phase angle is near 180 degrees (i.e. the planet is between A and the camera, and B is behind the camera) then illumination from B will dominate and become more visible since A isn't illuminating much of the visible surface of the planet.

Is this possible to implement? I think it'd produce more realistic results.

It's possible to consider the phase angle for light intensity scaling, but it handles only a few special cases of a much bigger problem, so I'm not going to bother implementing it. The big problem I'm talking about is 'auto-exposure': analyzing the scene to determine how to map light intensity to pixel values for display on a monitor. The problem you describe is only the latest manifestation of a serious shortcoming in Celestia. A more significant one is that even when looking directly at the Sun, stars are still visible in the sky. In your example, what if one of the stars is visible at the same time as the more dimly illuminated side of the planet? Realistically, the planet should be rendered completely black. High-dynamic range rendering with floating point pixels is the only robust way to implement autoexposure, particularly when objects with arbitrary geometry are permitted.

--Chris

I see the problem...

So when you say "floating point pixels", do you actually mean that the pixel colours aren't defined by integer values between 0 and 255? So you've got 16-bit pixels? (though that would just be integer pixel values defined from 0 to 65000, woudn't it?)

Evil Dr Ganymede wrote:I see the problem...

So when you say "floating point pixels", do you actually mean that the pixel colours aren't defined by integer values between 0 and 255? So you've got 16-bit pixels? (though that would just be integer pixel values defined from 0 to 65000, woudn't it?)

16 bits for each channel--red, green, blue, and alpha--for 64-bits total per pixel. 16-bit (often called half precision) floating point values have a 10 bit significand, one sign bit, and a 5 bit exponent. With 5 bits for the exponent, the smallest representable nonzero value is 2^-15 and the largest is 2*2^15. Thus, in 16-bits, you can store intensities that vary by a factor of two billion. That's still not quite enough, but you don't compromise too much by clamping on the high end. Also, though you lose precision, denormalized half-precision values can range down to 2^-24.

--Chris

There's obviously no illumination on the darkside from B there (which is again directly behind the camera, and at its closest to the planet), even though the planet is barely lit by A in this view.

Since we can't actually see your screen, we can only guess at what you're actually seeing. Can you e'mail me a copy of Celestia's screenshot from the viewpoint of your URL?

Which Render path are you using? On my system, the FX render path is the only one that draws the dimly lit side of Prometheus completely black.

If you are not using the FX path, then it seems to me that there must be something wrong with your system.

Have you made any adjustments to Nvidia's driver's color correction controls? That would limit the gradations that are visible. To first approximation, the diagonal line in the left side of the "Color Correction" properties window should be a straight line.

Maybe it's just that your screen's brightness or contrast settings are wrong. Have you calibrated them? If your system has a DVD drive, you should consider renting one of the home-theater calibration DVDs so you can adjust your display to show colors and intensities as best it can.

Alternatively maybe something's really broken: either the card or the drivers.

On my system I have no problems seeing the illumination on both sides of Prometheus, from either B or A components. Using your URL, Prometheus is dimly lit on my screen. I can see both the clouds and surface features. Using the mouse to turn the planet, the more brightly lit A side comes into view. I verified that "Ambient Light" is off on my system, so it really is the starlight illuminating the planet.

System:
512MB 2.4GHz P4, WinXP Pro, SP2
128MB FX5200, ForceWare 66.81 beta
Celestia v1.4.0pre5

I thought the cel URLs would show it, but evidently not!

I'll post some screenshots when I get home tonight. I was using the OpenGL/Nvidia combiner paths though.

Oh, and Prometheus (which is the one now at 4 AU) DOES show the illumination from both stars. It's Polyphemus (the one at 0.4 AU now) that doesn't. (maybe I should have used less similar names )

URLs take your copy of Celestia to the same location in space, looking in the same direction and with the same rendering settings. They do not guarantee that you'll see the same things.

On my system, both planets are lit by both stars.

chris wrote:High-dynamic range rendering with floating point pixels is the only robust way to implement autoexposure, particularly when objects with arbitrary geometry are permitted.

Is this simply an information, or do you have any strategic plans to work on this? (Just out of curiosity)

maxim

Here's what I see:

(The large image is in PNG format to preserve the darkest colors. JPEG seems to lose some.)

This is using Render path "OpenGL vertex program+Nvidia combiners".

The dark side of Polyphemeus is only middling dark and readily visible. The dark side of Prometheus is very dark, just barely visible.

Interesting... that's definitely not what I'm seeing (but you know that already, Selden ).

Selden, could you please post the screenshot I emailed you if that's not too much trouble, so that others can see what I'm seeing?

Otherwise everyone else will have to wait about 5 hours until I get home before I can post it .

Here 'tis:



just the opposite from what I see!

Thanks!

I'm using a compiled version of the current cvs and have the same problem as our Evil Dr. Should I be using the prereleases from chris?

Nevermind. Mine is fine, I'm just mistaken.

Ummm, errr, ahhh. I made a mistake.

There really does seem to be a lighting problem.

I found the major cause of the differences in our pictures: the dates are not the same.

EDG's picture is dated over 100 years in the future.
I've been viewing the planets with today's date, when the stars and planets have a different alignment.

Here's a picture at todays date.
Top left: ALF Cen A behind Prometheus, but near side is bright.

Bottom left: ALF Cen B behind Prometheus, but near side is bright.

Bottom right: orbits of A, B and Prometheus, showing that A and B both are on one side of Prometheus, so the side away from them should be dark.

Top right: a wide angle view of the sky above the bright side of Prometheus, with no bright light source visible


.

p.s. for those who are wondering how there can be star orbits and names although Chris has not yet implemented them, I defined "fake planets" with the same orbital parameters as the stars. So the orbits and names are of those planets.

selden wrote:Ummm, errr, ahhh. I made a mistake.

There really does seem to be a lighting problem.

I've a hard time believing that there's a bug here. I tested the hell out of this lighting code, and I can't something like this would sneak by me. Do the OpenGL 2.0 and the vertex program/combiners path produce similar results?

--Chris

OK, here's another view of both worlds from nearer our time.

(Sorry. I can't figure out how to get the little preview image that Selden has in his posts!)



It's a lot harder to see the illumination of B on Prometheus (4 AU from A) here (you may have to turn your lights off to see it) but it's there. The illumination is not there for Polyphemus (at 0.4 AU from A) though. In both cases, B is about 30 AU directly behind the camera.

And this is the case on Basic, Multitexture, Open GL Vertex Program, and Open GL Vertex Program/NVIDIA combiners paths on my video card.

I dunno if that helps at all with whatever bug Selden's found, but there you go.

maxim wrote:

chris wrote:High-dynamic range rendering with floating point pixels is the only robust way to implement autoexposure, particularly when objects with arbitrary geometry are permitted.

Is this simply an information, or do you have any strategic plans to work on this? (Just out of curiosity)

maxim

I do have plans to work on high-dynamic range rendering with floating point frame buffers. But, there are other tasks that have priority right now: finishing up the work on multiple star systems, improved star rendering, better atmosphere rendering, and improving mesh rendering (among other things, I want Eros bump mapped with the 0.125 degree laser altimetry data).

--Chris

I think I found another example of the bug that Selden found with the lighting that shouldn't be there for Prometheus/Polyphemus planets. Look at this:



(ignore the fact you can see the stars through the planet. My screen capture appears to be fubared in both PNG and JPG ).

But you can see the "black clouds" on the left, yes? Well, the bright star you can see in the background is Alf Cen B, and Alf Cen A is off to the right. So what's illuminating the haze/clouds on the left of the planet?!

(and there's no ambient light here).

BTW, this is with Haze turned on in the atmosphere. If I turn the haze off, the clouds stop being "black" and look normal, but you can still see them. See the "black clouds" thread on the Bugs board for more details). It looks like the cloud layer is being illuminated when it shouldn't be?

Evil Dr Ganymede wrote:My screen capture appears to be fubared in both PNG and JPG ).

If this really bothers you, you could try if capturing screenshots from within CELX doesn't have this problem - it may work better because there is no dialog box on the screen prior to capturing (at least not if you insert a short wait()). PM me if you need/want help.

Harald

Now something very odd is going on... I turned the haze back on and it seems to be working fine now. B can be on the other side of the planet and the visible dark hemisphere is not illuminated by it anymore.

I haven't changed anything else either. How can it just resolve itself like that?!