Differences in HDR

xiaxou

Newcomer
Hi everyone,

I have been reading some post here, and i have seen that there are at least two kind of ways to get HDR:

- One way would be like Oblivion uses through FP16. Where no nvidia card can manages using both antialiasing and High Dynamic Range.

- Apparently there is a second way to get this HDR using also antialiasing.... i am not very technical i just want to make it clear.

My question is: will there be visual differences in the HDR depending upon if one of these techniques is used????

I know PS3 cannot have both HDR and antialiasing through FP16. will there be differences of HDR using RSX dedicated for HDR, through FP16, and when RSX is used to have both on screen HDR and antialising? Which has better quality?

Thanks fellows
 
Humus also did an investigation into various methods of HDR awhile back IIRC (thread is somewhere on the forums, but I can't recall where).

edit:

Here's the thread.
 
Last edited by a moderator:
xiaxou said:
My question is: will there be visual differences in the HDR depending upon if one of these techniques is used????
There should be a visual improvement in areas of overexposure on the non-FP16 (non RGB) HDR method. In the RGB mode, increases in colour components can cause colour errors. Think of an orange sphere with a white specular highlight. The red, green and blue components increase with the light. Um, I'll try and explain with a table that shows a selection of points from outside the specular highlight to it's centre where it's white after the image has been resolved (what's in the front-buffer). Brightness is increasing as you go down, from basic colour (255,128,0) to white (255,255,255).
Code:
 R       G      B
255     128     0     <--- Hue is orange
255     160    32
255     192    64
255     224    96
255     255    128    <--- Hue is Yellow
255     255    160
255     255    192
255     255    224
255     255    255
This results in changes in hue, as the ratio of green to blue changes. You'll see in a fair bit of HDR screengrabs these secondary colours around white highlights, yellow, cyan and magenta.

Non RGB colour space that works on illumination without changing hue will (or at least should!) fade to white without colour abberations. The above table would instead look something like this...
Code:
 R       G      B
255     128     0
255     144    32
255     160    64
255     176    96
255     292    128
255     208    160
255     224    192
255     240    224
255     255    155
I've never tried this type of HDR on realtime graphics, but I did write an HSL shader for a raytracer that had these benefits and it made a big difference. Dunno if nAo could produce a few pics from his method that can show the difference?
 
xiaxou said:
Hi everyone,

- One way would be like Oblivion uses through FP16. Where no nvidia card can manages using both antialiasing and High Dynamic Range.

I thought the HDR on Oblivion was fp10???

can somebody confirm???
 
Check the posts from Nao!
X360 supports FP16 only without simultaneous blooming.

As for the FP16-part, I think he was referring to the PC version which supports FP16 or AA. The X360 version is only FP10, AFAIK.
 
My understanding now from the last thread that Xenos supports FP16 with HDR and MSAA, but without blending.
 
--------------------------------------------------------------------------------
In the recent GDC warhawk video they have both 4xAA and HDR on at the same time

Shame the game looks crap.
 
hupfinsgack said:
Check the posts from Nao!
X360 supports FP16 only without simultaneous blooming.
I've never seen a post like that. It makes no sense at all.

From what I've gathered from nAo and others, FP16 support on Xenos:
-has no alpha blending (just like NAO32) <-- likely the biggest impediment to the use of FP16
-writes at half speed (won't be a problem, as 2GPix/s is plenty)
-needs more tiles (possibly is an issue)
-works with AA but there is no hardware AA resolve (must be done in shaders)

What I am currently in the dark about, however, is what Xenos' filtering abilities are. Can it filter any higher precision formats? FP16, FP10, or FX16?
 
Mintmaster said:
I've never seen a post like that. It makes no sense at all.

Sorry I mixed up blending with blooming :oops: That's what prolonged sleep deprivation does to you...
 
Alstrong said:
for the less-than-knowledgeable, what is the purpose of blending :?: :oops:

It allows you to composite stuff being rendered, with stuff you rendered before.

So for example you can have a translucent object where the background shows through.

One usage might be to give you more detailed foliage on a plant, but retain soft edges - draw a texture with leaves in it, and have pixels in the texture with varying levels of "alpha" (an extra value for each pixel in addition to the RGB value) which would say how much of the background to blend in for each texel. The middle of a leaf would be opaque, the bits in between leaves would be transparent, and the pixels on the edge might have a medium value. Texture filtering will soften that further.

You don't have to use a linear blend between colours - you can choose how the pixels are composited. Sometimes the pixels are added together - so everything gets brighter the more and more you render. This is used a lot of special-effect particles and gives you a kind of glow effect, like each particle is emiting light.

Blending usually occurs in the back-end of the pipeline, after the pixel-shader runs - these days people call this bit the "ROP". It's done here to avoid artefacts with the rendering - the pixel shaders generally aren't allowed to access the frame-buffer they're rendering to, or you get collisions and stuff between different shader units and all kinds of nasty glitches appear. The ROP just has a blend-mode setting which describes how to compose pixels together, and then it reads the frame-buffer pixel, takes the output from the pixel-shader, applies the blend operation and writes the pixel back.

You could blend in a shader but it would pretty much mean copying the back-buffer to a temporary texture for each polygon, and then using that as a source texture. The blend unit in the ROP will be far more efficient...

Problems with blending include the order in which things are drawn (in order to get the correct result, you might have to render things in a specific order - from the back of the scene to the front), and with artists putting silly colours in the pixels which aren't fully opaque and gives nasty edges around things (how many games have you seen an ugly dark halo around a translucent object? - thats because the artist didn't bleed the colour of the object into the translucent area of the texture - they probably just left background colour in there).

Blending is pretty fundamental to a lot of rendering - you need it for any translucent effect, including pretty much any particle system or special-effect, or any multi-pass effect (bloom, etc) and in many other common situations.
 
Mintmaster said:
has no alpha blending (just like NAO32)

I'm pretty sure you can blend with NAO32, but you have to come out of the colourspace to do that. That's what I recall anyway, someone may remember the specifics better.
 
That's what Mintmaster means by doesn't support blending. You need to do a conversion to an alternative colour space. The NAO32 method does, as you can incorporate these conversions, which I guess it what's you're thinking off, but the NAO32 colour space doesn't, like FP16 on Xenos in hardware, as per Mintmaster's example.
 
what's wrong with FP10? seems like some of you guys are downplaying FP10 now. sure it's not as great as FP16 but as long as it looks good enough right? just like nao32?
 
Back
Top