HDR: High Dynamic Range illumination

[dirkpitt]

1. Appearance and dissappearance of stars is a little too sudden. In fact appearance is gradual (but fast), while dissappearance seems completely abrupt.

2. Appearance and dissappearance of stars does nor work the same when the sun is eclipsed behind a planet, and when you move it out of the screen. In the first case, I see stars appearing when the disk of the sun is half way eclipsed. In the second, stars appear only when the last pixel of the star (or illuminated planet, you get the idea) is noved out of the window.

Thanks for the feedback, I'm the author of the HDR patch.

In general, I would tend to agree with your points.
Regarding (1), the equation I used is the same as the one modeling Temporal luminance adaptation in this paper:

Code: Select all

exposure = exposurePrev + (exposureNow - exposurePrev) * (1.f - exp(-1.f/(15.f * EXPOSURE_HALFLIFE)));


EXPOSURE_HALFLIFE is 0.4 seconds, or about 0.4 seconds for exposure to halve. In real life, the human eye can take up to minutes to adapt in darkness. 15 is the framerate I get on my machine with bloom turned on (slowww!), this ought to be the real framerate but for simplicity it is hardcoded for now.

What should be done to improve Celestia's implementation I think is, when the scene brightness changes from dark->very bright, use a short half life (e.g., 0.4 sec), but when brightness changes from bright -> dark (e.g., rotating away from the sun), use a longer half life (e.g., 10 sec or more).

As for (2), unfortunately the eclipse calculation currently assumes the sun is a point. This is a very convenient simplification but unfortunately the results are less than satisfactory. Also, everyone is mentioning this all the time, but the exposure adaptation does not handle gracefully the transition where stars go from discs to points. Don't worry, it's a known bug and is being worked on!

[ElChristou]

Just build a new osX HDR version Tx to Dirkpitt!

Feedback: apparently my slowdowns are just a config problem, HDR is not for 32Mo cards!
- Got very low FPS when using Highres map (2k dds or more (with normals etc)
- Full screen don't work (is this only osx?)
- Got some illogic behavior like the above:

1) no stars, normal
2) stars, not normal
3) no stars, not really normal
4) stars only late when mars cover almost all the window (not normal)

[duds26]

There are a little bit too few stars visible in the screenshots with Mars.
In the lower two, there should be more stars and brighter visible than in the two highest pictures.
The celengine is not calculating the brightness correctly.

Exposure not gamma corrected

,

This is a big issue because everything will look different on a Mac than on a PC!!
8O :!: Celestia should always give everything the same with adding gamma correction values (to the graphic card), please fix this.


Implementing HDR is a wonderful thing, but all these unexpected effects and bugs.
And the 1.5.1 isn't even out yet, please get this out first.

[t00fri]

Friends,

looking at these nice HDR shots, I still don't feel entirely happy.

Let's compare the two backlit images of Titans atmosphere:

1) The new HDR image (<= cartrite)



2) My original one without any HDR effects:


I don't see all that much difference due to HDR here, while there should be: the sun on that HDR image is NOT at all an overly bright source of light. It's rather a somewhat dull yellow patch...

See what worries me?

F.

[ElChristou]

...the sun on that HDR image is NOT at all an overly bright source of light. It's rather a somewhat dull yellow patch...

Before working on the stars rendering at close range I think there is lot to fix for the fading background and DW must be working on this. Now it's true that in this pict the sun should be white with a glare much bigger...

(BTW, during a few seconds I was wondering where was the sun in those pict because of the savage cut done by the PHP engine...)

[cartrite]

Fridger,

The OGL2 is a little bright if you have a specmap.

This is a known bug.

Actually, it not only has a problem with a specmap in OGL2 being too bright but also the newer atmosphere rendering in OGL2 being too bright.
This is why I posted the image. So people will have an idea of what to expect. This is disabled by default. A sign that it is no where near finished.
cartrite

[chris]

Friends,

looking at these nice HDR shots, I still don't feel entirely happy.

Let's compare the two backlit images of Titans atmosphere:

I don't see all that much difference due to HDR here, while there should be: the sun on that HDR image is NOT at all an overly bright source of light. It's rather a somewhat dull yellow patch...

See what worries me?

So, given the apparent brightness of Titan's atmosphere, you're expecting the glare from the Sun to cover a larger area of the screen?

The current HDR technique uses standard 8-bit color components, so there's a limit to what dynamic range can be represented, and thus to how bright any element can appear. The advantage of it is that it works with nearly any graphics card. There are many fewer limitations with 16-bit floating point color components, but these require GeForce 6 series or Radeon 1xxx/2xxx series graphics cards. Quite a bit of DW's code is relevant for both 8-bit and floating point frame buffers. Even the dynamic range compression will still be useful, as 16-bit floating point value (commonly referred to as a 'half float') can still only represent a range of intensities smaller than what may be encountered in astronomy.

The atmospheric scattering calculations need to be adapted for HDR, too. The Mie phase function produces values that are outside the [0,1] range represented in a low dynamic range frame buffer. In the present implementation, scaling factors are applied to keep pixels in roughly in the representable range.

--Chris