Preliminary HDR stuff

[klauss]

I've been toying with RenderMonkey, trying to get a good HDR look.

I've concentrated, mostly, on faking it on hardware supposedly not capable of HDR - without floating point pixel formats. Mostly because, if I assume support for them, it becomes pretty straight-forward.

For now, there's no way to put it on the engine (regular VS, of course not - but not even in the current Ogre framework), because the best way to do it would be with what's called "compositor scripts", which are still a to-do in Ogre - well... not to-do exactly, since it's marked [in progress]

So... until that's done (which should be soon, apparently), the User Interface Framework won't support HDR - I don't want something dirty, even if functional, if by just waiting a little while I can get something better.

Anyway, the RenderMonkey project went along nicely, even with multiple versions of the stuff: One for single pass postprocessing (doesn't look nearly as nice, and is quite demanding - I don't like it), many for multipass processing (8 passes - seems barely enough, though). The multipass versions have been coded both with internal formats of sRGB and RGBE - both mocked up versions, since the standards didn't perform very well. The RGBE seems to look the best, but the sRGB version isn't bad either - very subtle differences. sRGB is slightly faster than RGBE and less demanding on the hardware. Since it's GLSL, I'm not certain about the requirements... I'll translate it to HLSL and then Cg (Cg is almost identical to HLSL, but doesn't work in RenderMonkey) eventually, and then I'll know what kind of hardware exactly is required.
My guess is that any arbfp1/ps2 card will work, since the stressing part is mainly the number of passes, not so much the complexity of each - although they're not a cakewalk either.

Ok... before posting this, I was asked in Ogre forums to wiki this thing, so I'll rather link to the Wiki page, if that's OK - wouldn't want to type all that again

Faking HDR - Ogre Wiki

(note - the screenshots and the article itself are a bit outdated, the linked RenderMonkey project contains the RGBE implementation and dithered output, even though the article claims it doesn't - I should correct that).

[chuck_starchaser]

Just read the wiki.
First thing that would have occurred to me, actually, would be to just write some pixel shader code that puts out an intensity proportional to the log of ithe input, calibrated so that suns look just a bit saturated white, and moonlit night-sides of planets are just barely visible; but such that the chroma is invariant. Sure, it would lower contrast in many cases but our brain adjusts for contrast very easily. And this code could be added at the output of every pixel shader, so hdr would get done without an extra pass.

Code: Select all

vect3 out;
....
//static, logarithmic hdr:
float output_intensity = sqrt( dot( out, out) );
float hdr_adj = ( C1 * log( output_intensity ) + C2 ) / output_intensity; //C1 & C2 are tweakers
out.red *= hdr_adj;
out.grn *= hdr_adj;
out.blu *= hdr_adj;

This wouldn't do glows and stuff, but those are extras, anyhow; the way I see it, hdr is about compressing dynamic range so it fits the hardware, nothing more; and this could be done on the fly, without an extra pass.

[klauss]

RGBE is done in a single pass too, as sRGB.

I referred to adding a stage for output format conversion... but I meant it as like:

Code: Select all

return encode_rgbe( color );

Rather than an extra pass.

RGBE is a floating-point format that gets encoded as RGBA data - you feed it RGB data (no alpha), and it outputs RGBA pixels (where A encodes the exponent).

The problem with it is when you use it to encode textures - where do you put transparency info?
Anyway... it's usually used in textures without alpha already (skyboxes... glowmaps... lightmaps... etc...), so, it shouldn't be a big problem.

Anyway... even with normal textures and otherwise normal input (colors and all), there's a lot of room for extended range results - specular components tend to go way high, dark sides of stuff gets very dark but not black if lit with subtle ambient lights - or even planets' city lights (they're dim). HDR allows precise rendering of that extra dynamic range. But have in mind that HDR is somewhat meaningless if you don't perform the postprocessing (glows) - you get almost no quality gain that you couldn't have gained with lighting tricks. And... color values usually arrive at the vertex shader (and then the pixel shader) in float already, so you can use HDR colors even if you don't use HDR textures.

[chuck_starchaser]

What I meant is rather simple, if not overly simplistic. No special formats, no nothing. Basically, taking advantage of the fact that colors are already float format internally to the videocard, and compressing the dynamic range by outputting an intensity proportional to the log of the input intensity, statically pre-adjusted so the brightest and darkest things we want to see details of don't saturate. Anyways, if I figure out how to get set up, I'll try it.

[hellcatv]

I was just talking about HDR in vegastrike with my labmates...

one thing to note is that most things with high dynamic range are additive textures (stuff like lights and engines) for these rgbe would work properly...

I think the most important part is rendering to a floating point buffer at the end (so we get the free hardware blending!!!) and then using a bloom filter.

I think users without float support don't get high dynamic range.... I really want to see this done right, not hacked.... I remember I spent ages trying to fake it for those star trek ships petey was working on for Vega trek 0.2.0, but we eventually gave up and decided to wait until the hardware was ready to do it properly....

also if we do it with floating point render targets we can use those high dynamic range screens I keep seeing at SIGGRAPH each year

[klauss]

I think we would be able to switch implementations quite easily.
Yes... I will never support faked HDR if that means removing support for true HDR... rest assured of that.