Some new interesting information about valve's HDR implementation
- Thread starter tEd
- Start date
Wow
Finally, a bright ray of light in a so forth foggy area ...
(for me of course)
That article succeeds in getting the main idea through while explaining what to look for/expect in HDR enabled scenes. I do have some questions though ...
Does it work like a universal rendering solution to any scene, once hard coded into the engine, or is it like some level related, additional effect applied by the level artist ? I imagine it somewhere inbetween, like lightmaps used to be, only that, erm ... they are dynamic. Will all lights (dynamic, static or prerendered) be taken into account in a HDR enabled scene ? They mention setting up the skybox range levels; it suggests it was done by the level artist.
Also the article mentions some sort of radiosity solution for interiors ...
Finally, a bright ray of light in a so forth foggy area ...
(for me of course)That article succeeds in getting the main idea through while explaining what to look for/expect in HDR enabled scenes. I do have some questions though ...
Does it work like a universal rendering solution to any scene, once hard coded into the engine, or is it like some level related, additional effect applied by the level artist ? I imagine it somewhere inbetween, like lightmaps used to be, only that, erm ... they are dynamic.
Will all lights (dynamic, static or prerendered) be taken into account in a HDR enabled scene ? They mention setting up the skybox range levels; it suggests it was done by the level artist.Also the article mentions some sort of radiosity solution for interiors ...
Laa-Yosh said:
What do you mean? That's what HDR is!!!
In all seriousness. What I've seen of HDR in games..... sucks. Farcry gets slightly better outside, but only because it looks less washed out. In doors, it sucks, honestly. I cant stand the unnatural lighting in produces. Same with most cases with SP:CT, rocks do not glow!
Maybe this will be good, though I already think HL2 in general is light years ahead in terms of looks to me, it is easily the best looking game out there IMO, no matter what tech specs you throw out.
Luminescent
Veteran
Maybe that's a result of HL2's excellent artstyle rather than its rendering engine technology.
trinibwoy said:Mind explaining why - for those of us even more clueless than they are?
1.
MRT stands for "Multiple render target".
A render target is something you can render to, it can be a back buffer, an offscreen buffer or a texture.
MRT means that multiple render targets can be written in the same rendering pass.
So the term "multiple render to texture" is strange and is probably a misinterpretation of the journalist.
Also note that currently available cards do not support anti-aliased render targets in MRT rendering.
2.
I don't actually know what sRGB stands for but it's not separate RGB values.
sRGB is a color space where the components have a 2.2 gamma relative to the actual light intensity.
A color space working with actual light intensities is usually described as linear color space.
The journalist appearently thinks that linear color space means that the colors are represented as a scalar as opposed to a three component vector as in RGB.
Of course both sRGB and linear RGB has 3 components, only the component values has a slightly different meaning.
Luminescent said:
That's exactly my problem - HL2 has managed to be unique in its tasteful visual style, probably because of their art director (I think he's bulgarian, so he had different influences than a native american would've had). This new look is in a total contrast to what HL2 has been like.
First of all, let me just say two things:
1. It's a lot of work to get HDR to work with integer buffers, so I don't expect most game developers to do it. HDR with FP buffers that support blending, on the other hand, just require you render as normal and add an appropriate tonemapping pass.
2. I really don't buy that Valve can have possibly gotten this to work without serious limitations. I don't know what those limitations will be yet, but I'm sure they will be there.
3. I would seriously hold off judging HDR too harshly until we see some games designed with HDR in mind from the start. Next year we should be seeing some such games.
So, "multiple render to texture" may actually be more accurate, and be an indication that they are rendering separately to multiple textures.
1. It's a lot of work to get HDR to work with integer buffers, so I don't expect most game developers to do it. HDR with FP buffers that support blending, on the other hand, just require you render as normal and add an appropriate tonemapping pass.
2. I really don't buy that Valve can have possibly gotten this to work without serious limitations. I don't know what those limitations will be yet, but I'm sure they will be there.
3. I would seriously hold off judging HDR too harshly until we see some games designed with HDR in mind from the start. Next year we should be seeing some such games.
Well, it sounds like they're rendering to targets of different formats, so it seems likely that multiple passes are used for the HDR effect, as opposed to MRT, which, if I remember correctly, requires all targets to be of the same format.Hyp-X said:
So, "multiple render to texture" may actually be more accurate, and be an indication that they are rendering separately to multiple textures.
Well it looks like they are rendering normally once, and then render to a high precision target again.
The normal target can have AA, the other one is used mainly to generate bloom, so it's blurred anyway -> no real need for AA.
You can actually perform tone-mapping in the material shader assuming you use the brightness information from the previous frame(s).
This implementation has a cost of rendering everything twice. Also not having blending support for the high precision target you can have problems like smoke not occluding the bloom of a bright light source behind it.
Also reflections and semi-transparent stuff (like windows) won't be rendered correctly.
The normal target can have AA, the other one is used mainly to generate bloom, so it's blurred anyway -> no real need for AA.
You can actually perform tone-mapping in the material shader assuming you use the brightness information from the previous frame(s).
This implementation has a cost of rendering everything twice. Also not having blending support for the high precision target you can have problems like smoke not occluding the bloom of a bright light source behind it.
Also reflections and semi-transparent stuff (like windows) won't be rendered correctly.
caboosemoose
Regular
Chalnoth said:
My sentiments exactly.
Chalnoth said:
I would say that the tonemapping is the trickiest part in HDR. You need to figure out a way to estimate the average brightness of the scene, such as repeatingly downsampling to get to a 1x1 texture, then blending with a previous frame's result to get smooth transitions, and then map over the entire screen as an exposure lookup. Not neccesarily hard stuff, but takes some work. Once you know the exposure, it should be fairly straightforward to dynamically adjust the range if you'd use an integer render target.
You mean shading? I don't think it should be called deferred rendering as this has nothing to do with TBDR.Humus said:
Anyway, we'll see in about 1-2 years what support of HDR will be like. I expect 80% of games that support HDR in the next two years will do so only through FP16 buffers on SM3 hardware.