OpenEXR (HDR) Industrial Light+Magic next big thing?

[Zengar]

No, it's not that simple. There's a strong feasibility limit here. Specifically, once you go to multipass rendering, there's just no realistic way to do HDR rendering. Multipass rendering will become ubiquitous with any program that makes extensive use of realtime shadows.

Sorry? Any card that supports floating-point textures can emulate fp-blending. Of course, doing multipass will make things difficult but you can still take the framebuffer texture as an input.

 

[tb]

No, it's not that simple. There's a strong feasibility limit here. Specifically, once you go to multipass rendering, there's just no realistic way to do HDR rendering. Multipass rendering will become ubiquitous with any program that makes extensive use of realtime shadows.

Sorry? Any card that supports floating-point textures can emulate fp-blending. Of course, doing multipass will make things difficult but you can still take the framebuffer texture as an input.

HDR is mostly an post processing effect. You simply have to render the scene into an floating point render target and do some scaling and blurring. You don't need fp blending, if you don't do any alpha blending in your scene and you don't need fp filtering if you do the "filtering" in the pixel shader or if you do the last step of your HDR in an 16 bit integer render target. This is it, what shader 22 (High Dynamic Range Shader - low quality version without filtering) of ShaderMark v2.1 does.
Shader 23 (High Dynamic Range Shader - high quality with fp filtering)
uses fp filtering to reduce the number of samples compared to shader 24 (High Dynamic Range Shader - high quality without fp filtering). 23 and 24 are math. equivalent!
Hardware fsaa support is another issue, which ShaderMark's HDR do support, but maybe Far Cry or Half-Life 2 not...

Thomas

 

[KimB]

Sorry? Any card that supports floating-point textures can emulate fp-blending. Of course, doing multipass will make things difficult but you can still take the framebuffer texture as an input.

No, it's just not feasible for the majority of game scenarios. Alpha blending, for instance, is commonly-used today (particularly for grass). You'd need to do a separate pass for each polygon that uses alpha blending. That's a prohibitive number of state changes. It also mucks up multipass rendering, as you'll continually be swapping the framebuffer texture.

 

[KimB]

HDR is mostly an post processing effect. You simply have to render the scene into an floating point render target and do some scaling and blurring. You don't need fp blending, if you don't do any alpha blending in your scene and you don't need fp filtering if you do the "filtering" in the pixel shader or if you do the last step of your HDR in an 16 bit integer render target. This is it, what shader 22 (High Dynamic Range Shader - low quality version without filtering) of ShaderMark v2.1 does.

Well, first of all, you can't do texture filtering properly (in general) without ddx/ddy instructions, which ATI doesn't support. And you do need alpha blending for any multipass lighting algorithm. It's also used frequently for many effects (from transparent objects to foliage). So no, I don't feel true HDR rendering is feasible without FP framebuffer blending support.

 

[tb]

Well, first of all, you can't do texture filtering properly (in general) without ddx/ddy instructions, which ATI doesn't support. .

HDR filtering is done only on screen aligned quads. So ddx/ddy aren't useful there, because there is no need for aniso. filtering or mipmapping. Or am I overseeing something?

Thomas

 

[KimB]

HDR filtering is done only on screen aligned quads. So ddx/ddy aren't useful there, because there is no need for aniso. filtering or mipmapping. Or am I overseeing something?

Thomas

Well, you're applying that texture filtering to the "bloom" pass after rendering. While I'm sure that this is where FP texture filtering will be widely-used first, there are certainly other uses, such as if you want to have lightmaps that do proper HDR lighting (i.e. for projective lights).