This patent-pending technology analytically renders NURBS and subdivision surfaces directly into perfectly anti-aliased pixels
Sounds like it does use anti-aliasing, although the way it's done does sound somewhat different from traditional anti-aliasing techniques (I haven't looked at it in detail). On a side note, it also sounds like there might be patent issues if anyone else decides to go with their approach.
What didn't make sense was why expanding the range of brightness levels would change anything. Tripling the range (so that all brightness levels go from 0-3)... This is made obvious when you then *divide* the resolution by 3 in order to display the image on the screen! And like others have said, you ain't making white any whiter than #FFFFFF...
The idea of HDR as used commonly in rendering is not to have more resolution *between* 0.0 to 1.0, but to have colors *higher* than 1.0 (and possibly less than 0.0). In your case, the colors would *not* be divided by 3 when output to the monitor - anything higher than 1.0 would get capped.
Values higher than 1.0 are stored for internal calculations - this extra information can have a huge effect on the final output image. Take for example, a scene with an overbright sky. The brighter parts of the sky would show up as (r,g,b) == (1.0, 1.0, 1.0) after the colors get capped, so what's the point of having it stored internally as higher than 1.0?
Well, lets say that same scene also had a chimney or something spewing out dark smoke in front of that bright area of the sky, and color data on the framebuffer was stored simply as 1.0 1.0 1.0. Since the smoke is darker than the sky (lets just say it's all 0.0 0.0 0.0 for the sake of simplicity), drawing it in front of the sky will result in muddy-looking, flat grey smoke (1.0 * (1 - alpha) + 0.0 * (alpha) == 0.5, if the smoke's alpha is, say, 0.5).
Now lets say the higher range bits were stored in the framebuffer - the sky may have really bright spots which would be stored with pixel values of, say 4.0 - 8.0. The parts of the sky that are just "sort of" bright will be rendered with values around 1.0. When being output to the monitor, those really bright parts would just get capped back down to 1.0, would would be no different from the non-HDR version - assuming there are no other effects used such as the aforementioned smoke...
So, lets go back to the smoke - when it's blended in front of the sky using the HDR framebuffer, using that same alpha blending equation, notice that those really bright spots (> 1.0) will still remain above 1.0. However, those "sort of" bright spots (about 1.0) will now be much lower than 1.0. The final output image will be much different from the one rendered without HDR - the really bright spots of light in the sky will still manage to shine through the smoke, making for some really cool effects.
This can be put to use for things like beams of bright light shining through fog, highly realisting light/shadow interactions, etc. Again, HDR is just a way to represent colors internally - it makes logical sense too. In real life, unlike monitor screens, there is no "maximum amount" of light - it's all relative. If you're in a modestly lit room, and you take a look at a white piece of paper, that paper may look a hell of a lot brighter than anything else in the room.
But, take that piece of paper and hold it in front of a window which opens to the sky - although the sky is "blue", which shouldn't be brighter than the "white" paper, the relative brightness of the sky makes the "white" paper look almost black (even if indoor lighting in the room is shining on the visible side of the paper). This is what computer monitors cannot reproduce - they lack this huge range, so they can display either a greyish piece of paper, which will make the sky appear completely white, or they can display a blue sky, with a dark grey or black piece of paper in front of it.
HDR is also very useful for post-processing effects, namely light bloom. Most current games using light bloom effects had their artists manually mark textures/objects/areas/etc. which are supposed to bloom. Blooming is achieved (for the most part) by rendering the areas marked by the artists onto a seperate bloom buffer, blurring that buffer, then additively blending that buffer back onto the main framebuffer.
Slashdot Mirror
I think your post could have used a few more smilies :P.
The idea of HDR as used commonly in rendering is not to have more resolution *between* 0.0 to 1.0, but to have colors *higher* than 1.0 (and possibly less than 0.0). In your case, the colors would *not* be divided by 3 when output to the monitor - anything higher than 1.0 would get capped.
Values higher than 1.0 are stored for internal calculations - this extra information can have a huge effect on the final output image. Take for example, a scene with an overbright sky. The brighter parts of the sky would show up as (r,g,b) == (1.0, 1.0, 1.0) after the colors get capped, so what's the point of having it stored internally as higher than 1.0?
Well, lets say that same scene also had a chimney or something spewing out dark smoke in front of that bright area of the sky, and color data on the framebuffer was stored simply as 1.0 1.0 1.0. Since the smoke is darker than the sky (lets just say it's all 0.0 0.0 0.0 for the sake of simplicity), drawing it in front of the sky will result in muddy-looking, flat grey smoke (1.0 * (1 - alpha) + 0.0 * (alpha) == 0.5, if the smoke's alpha is, say, 0.5).
Now lets say the higher range bits were stored in the framebuffer - the sky may have really bright spots which would be stored with pixel values of, say 4.0 - 8.0. The parts of the sky that are just "sort of" bright will be rendered with values around 1.0. When being output to the monitor, those really bright parts would just get capped back down to 1.0, would would be no different from the non-HDR version - assuming there are no other effects used such as the aforementioned smoke...
So, lets go back to the smoke - when it's blended in front of the sky using the HDR framebuffer, using that same alpha blending equation, notice that those really bright spots (> 1.0) will still remain above 1.0. However, those "sort of" bright spots (about 1.0) will now be much lower than 1.0. The final output image will be much different from the one rendered without HDR - the really bright spots of light in the sky will still manage to shine through the smoke, making for some really cool effects.
This can be put to use for things like beams of bright light shining through fog, highly realisting light/shadow interactions, etc. Again, HDR is just a way to represent colors internally - it makes logical sense too. In real life, unlike monitor screens, there is no "maximum amount" of light - it's all relative. If you're in a modestly lit room, and you take a look at a white piece of paper, that paper may look a hell of a lot brighter than anything else in the room.
But, take that piece of paper and hold it in front of a window which opens to the sky - although the sky is "blue", which shouldn't be brighter than the "white" paper, the relative brightness of the sky makes the "white" paper look almost black (even if indoor lighting in the room is shining on the visible side of the paper). This is what computer monitors cannot reproduce - they lack this huge range, so they can display either a greyish piece of paper, which will make the sky appear completely white, or they can display a blue sky, with a dark grey or black piece of paper in front of it.
HDR is also very useful for post-processing effects, namely light bloom. Most current games using light bloom effects had their artists manually mark textures/objects/areas/etc. which are supposed to bloom. Blooming is achieved (for the most part) by rendering the areas marked by the artists onto a seperate bloom buffer, blurring that buffer, then additively blending that buffer back onto the main framebuffer.
However, an HDR framebuffer would work