WiteWulf wrote:You make an interesting point. A very similar thing IRL convinced me to always shoot with my DSLR in RAW. I took a pic from inside a cave looking out to a bright, sunny beach. The cave framed the scene, but was basically all black as it came out of the camera. Once I'd masked off the beach in the centre I increased the exposure and was absolutely blown away by the amount of detail the camera had captured inside the cave.
Basically, yeah, it's recreating that.
And, as I said, it wasn't, in my case, an effect or even really an attempt to be "realistic". It was, as I say, from seeing so many games where, the second it goes to "night" and you haven't brought a torch with you, the screen is basically black and you can't see fuck all. Which is stupid, and terrible gameplay.
I wanted to add a bit of "pupils adjusting to the light" simulation in there, just so that, at night or in a dark cave or whatever, you'd have "night vision" to actually see things, but when you wander out into the blazing Sun, you can also see things.
And you'd get the "walking out of a dark cave into the sunlight" where it's bloom-y but then clears up, as your virtual eyes adjust, for free - as my HDR-to-SDR tone mapping equations (which I found online) have an "exposure" setting to them, so "eye adjustment" is really just turning that dial up and down, over time, to match the image's overall brightness.
But, as Dio says, a lot of games are no doubt doing what I'm calling "internal HDR". That they render it all to a floating-point texture (that can hold really big and small values). Then you've got a "tone map" equation in your pixel shader that takes the floating-point and converts it to something the display can display.
This is useful, even when the target display isn't HDR, because you're basically avoiding clipping.
Like, bright Sun versus a street lamp (the Sun is so, so, so much brighter and the lighting equations ought to reflect that, that a street lamp turned on and off in the daylight ought not to make much of a difference to anything). Dark cave versus bloom-y daylight. Indoor versus outdoor, but still being able to see everything just fine, after a bit of "eye adjustment" - just like in real life.
There's a wide range of brightnesses in the real world, which 0-255 with RGB can't represent. So you work it all out in floating-point and then have a pixel shader do a floating-point to RGB8 thing for you at the final stage.
And I was doing this on a plain sRGB monitor, with no real view to thinking about HDR displays. Other than "if a 10-bit HDR display is attached then it can be mapped to 10-bits".
The way I think of it is that when you do audio, recording studios often record and edit at 96KHz or 192KHz. Even though they're going to release the final product at more than, at best, 48KHz.
You record and edit at 96KHz or 192KHz, not because the human ear could ever reasonably tell the difference, but because when you're editing the audio, you're going to lose precision around the edges.
Cut this, make it louder, apply an EQ, make it quieter, apply a reverb, copy it and shift it for phasing, make all of that louder.... every time you do a manipulation in the editing, you could be losing a little bit of precision. The x2 of 96KHz and x4 of 192KHz is basically accounting for this. It's a "margin of error".
As you edit 192KHz audio, tiny little losses of precision here and there won't amount to anything audible when you downscale it to 48KHz.
Same thing with Photoshop. You edit the high resolution photograph - as high rez as possible - because when you apply effects and stuff with Photoshop, there's going to be sub-pixel inaccuracies and things like that creeping in. But "work big" and then downscale it at the end. Then you don't have to worry because the tiny little losses are just not perceivable. A "sub-pixel" mistake at 100Megapixels is going to become a sub-sub-sub-pixel mistake, once you've sized it down to 1920x1080 or whatever.
"Work big" to get the calculations right, to retain precision, to avoid clipping. Then downscale it to an SDR monitor's range, or shrink the Photoshop picture to a smaller size to put it on your blog, or the recording studio outputs it at 44.1KHz 16-bit for "CD audio" on a plastic little disc.
And, in that view, HDR monitors are just devices capable of potentially displaying a bit more of that floating-point texture as calculated (but no way at the actual scale of floating-point, as that's got a massive range that no known technology could accurately represent). So I've currently got floating-point to 8-bit RGB for sRGB stuff. But if I had a 10-bit HDR monitor then I can "tone map" to 10-bits. The display can show a bit more of the range I've calculated.
But I - and as Dio rightly notes, many games - are going to be doing the calculation at floating-point level, regardless of what display - SDR / HDR - might be at the output end of this. If it's a HDR monitor, then it can show a little more of the detail that's in there. But if it can't, then it doesn't. You're not doing the HDR just to go "ooh, look, fancy effect". But to get all your "physically based lighting" stuff right and proper. And if a monitor can show a little more of that fine detail, that's nice. But that's not the aim.
"Words ought to be a little wild - for they are assaults of thought on the unthinking."
- John Maynard Keynes
