HDR Rendering?

#1 For those of us who don't know, what is it?

#2 High Dynamic Range. We're not planning on supporting this in the base TSE. I'm not a big fan of trying to get this running with current video hardware because it can't really be done "right". Maybe when Geforce 6800 class cards become the norm we can do it in the base implementation, but right now it's not really worth it for most games.

But this is what TSE is all about, easy access to shaders, so if you want to come up with your own custom shader/lighting solution for your game, then go for it!

#3 Thanks for the info.

#4 I'm slowing adding the float and high precision integer formats that are really nessecary for HDR. I've got them in my own TSE build, stalled a bit getting OpenEXR loader in at the moment (plenty of other things). Once in a fit state, I'll send them over to Brain to patch into TSE. I'm not actually using them for HDR as that is a MUCH bigger change to TSE, that I'm not convinced is worth it at the moment.

Brian is absolutely right, HDR is a serious pain and will be for a few years. Even if you have a card that supports FP16 with blending (NV40 at the moment) there is alot of work to get it into a reasonable state. The bandwidth requirements are scary (rendering to a 64 bit buffer is twice as expensive as a 32 buffer) and you have to do tone-mapping (just one bit involves summing the HDR buffer to get average log luminance)which costs a fair amount as well.

Looks lovely mind ;-)

#5 Sweet Dean! We're reworking the Texture Manager to support a bunch of new stuff and OpenEXR was on the list. We'll hold off on the loader for it now.

#6 Summing the color values was something I was wondering about, because don't they have to be unclamped colors? I think we are going to need to have some kind of hardware support before we are able to do HDR/tone-reproduction stuff in realtime because things would have to be written, unclamped, to some kind of accumulation register or something so you can get the average log-luminance.

Nice work, though, Dean. That'll be sweet.

#7 It says 16-bit floating-point format is compatible with NVIDIAS FX series.

#8 Yes, but they haven't exposed it yet for D3D. Don't know what the holdup is, those cards have been out for a year and a half.

#9 Pat:
Float buffers are unclamped so any pixel shader can get access to the values and can store them directly unaltered. Clamping is one of the major changes to OpenGL that the float buffer support is having to deal with, the quick overview is that once float targets are used all clamping is turned off.

If you doing the classic light adaptive tone-mapping ala Reinhold "Photographic Tone Reproduction for Digital Images" you can do a recursive render-target descent summing the scene log luminance. Under PS 3.0 you can get it down to 2 passes (via a complex looping shader).

NV GFFX support some float formats but have a bunch of restrictions (no WRAP, no mip-map, etc.) that require Dx9.0c for it to work. Even with that we only get 1 or 2 channel formats unfortantely, which rules them out of HDR on Dx9 :-(

#10 Sweet, Dean. That is good information. I had to do Reinhardt for a comp graphics class and it looked really nice.

#11 Some HDR examples are working fine for me on DX9.0c, havnt looked deep into thm, but I assume they are using the 'half' type.

#12 Sorry for the delay (been busy with other things), I've hit a snag with getting the OpenEXR added to Torque.

OpenEXR uses the STL, which upsets torque alot...

I currently fixing the memory manager disable macro so you can at least use the STL when the memory manager is turned off, but thats just a nasty hack.

Westy:
float16 (half) is just the same on GFFX, the DX demos are using a RGBE format thats uses standard 8 bit integer formats. Basically you store a shared exponent in the alpha channel. Losing a lot of precision and you can't blend properly but still works quite well considering.