HL2 and aliasing

Humus

Crazy coder
Veteran
http://www.3dgamers.com/dl/games/halflife2/source_hdr02.exe.html

Watching this little movie of HL2 effects I can clearly see that they haven't solved the aliasing problem that tends to come with perpixel lighting. In fact, the specular lighting is so overdone that the aliasing takes over the whole scene. Especially on the roof where the monster is, don't think I've ever seen such horrible aliasing on something that's this far in development. :?
 
Humus said:
http://www.3dgamers.com/dl/games/halflife2/source_hdr02.exe.html

Watching this little movie of HL2 effects I can clearly see that they haven't solved the aliasing problem that tends to come with perpixel lighting. In fact, the specular lighting is so overdone that the aliasing takes over the whole scene. Especially on the roof where the monster is, don't think I've ever seen such horrible aliasing on something that's this far in development. :?

That was something that i noticed too. Looked like a bad case of texture aliasing. But if this is caused by the per pixel lighting, what can be done about it ?
 
The roof where the AntLion was actually struck me as ugly and unnatural, but I found the AntLion and in between the reflective panels to be appealing and more "realistic", though the lighting effects are about as intense.

I'm thinking the problem with the roof in particular is due to exaggeration for demonstration, trying to hit people over the head with a hammer to demonstrate the difference made (though I really don't see the roof surface belonging in the game anywhere). However, the wooden fence behind the AntLion seem to exhibit a more subtle aliasing problem that I think might be more of a common concern in the game.
 
Yes, i've noticed this also. Any idea of what can be done?

On a related note, why is there such a performance hit on e3_techdemo_5.dem (45% more or less) when AA is enable and not in the other demos (B3D excel file)? Is it a typo or an issue with this partcular map?
 
Well, to begin with they should avoid having too sharp contrast in the normal map. Then it can be helpful to not only apply the usual boxfilter when creating mipmaps for the normal map, but also apply a slight blur filter for each level. They should also definitely reduce the specular exponent.
 
I had presumed that there was no anti-aliasing in this demo (as per most of the other HL2 demos), but on closer inspection, it looks that AA is used on other parts of this scene. I also don't know if any of these aliasing problems are exacerbated by the Bink compression used for the video.

I would hope that the Valve controlled AA would take into account these kind of glaring problems and try to put some AA onto these areas to lessen the issue, but we'll just have to wait and see.

Otherise we'll have to wait for next gen hadware that have the power to run Centriod FSAA on these complex DX9 engines :(
 
Humus said:
...clearly see that they haven't solved the aliasing problem that tends to come with perpixel lighting. In fact, the specular lighting is so overdone that the aliasing takes over the whole scene.

Well, apart from the fact that that overcast sky appears to be as bright as the sun, and so making the problem 10 times worse....

It seems as if the specular map on the roof (or function if they did it procedurally) has too much high frequency information in it. I cant believe it's the light source becuase that sky was relativly constant. If it's a specular map then better texture filtering should help.

Also remeber that these will have been run on ATI boards which don't do multiple fragment shader samples. Switching on FSAA wouldn't help at all.
 
I'd say that those surfaces in the movie are not using speculars, but rather bump mapping and enviroment mapping - with a HDRI enviroment map. This is also logical, considering that a simple specular highlight wouldn't benefit much from HDR rendering.

And the specular component is a fake substitute for reflections anyway :)

So, the aliasing problem is most likely caused by the bump map; thus, wouldn't anisotropic filtering be a solution for it?
 
All I can say is I hope the game looks nothing like that. It was crazy I have never seen such shiny rusted metal. It was horrid. BTW I have not watched that many videos of half life b/c I am planning on buying it, and dont want to ruin it, but I have watched 2 others and they look better to me so I am relieved. Why couldn't one see the sky from inside the barn? Oh and btw the sunbeams in Tenebrae on the part where you select difficulty I think look better :).
 
Laa-Yosh said:
I'd say that those surfaces in the movie are not using speculars, but rather bump mapping and enviroment mapping - with a HDRI enviroment map. This is also logical, considering that a simple specular highlight wouldn't benefit much from HDR rendering.

And the specular component is a fake substitute for reflections anyway :)

So, the aliasing problem is most likely caused by the bump map; thus, wouldn't anisotropic filtering be a solution for it?

A specular map defines how reflective a bit of the surface is. I had thought that that roof had ment to be wet, with some bit reflective and some bits not. Hence you use a specular map, the value of which goes into the Ks (Specular coefficient) or Kr (Reflectivity Coefficient) in your lighting equation.

A bump/normal map just gives you the normal direction and therefore which direction that reflection is viewable from. The aliases didn't seem to line up with any detail on the roof that I could see, so I interpretted it as a part wet / part dry surface.

Both can / may be used, and both need to filtered properly to not have aliasing issues. Specular and Bump maps filter quite well with the linear interpolation done by texture filter units. So, Yes, Aniso would help, but that surface wasn't really very oblique, which is when aniso helps the most.

I don't know about normal maps. Does anybody have any experience filtering normal maps?
 
I thought perspective corrected linear blending solutions introduced artifacts in normal maps? I guess it depends on whether angle or "depth" information is stored?
 
demalion said:
I guess it depends on whether angle or "depth" information is stored?

Exactly. Angle information = Normal Map. Depth Info = Bump map. At least that's the terminology I use.

I thought interpolating vectors linearly introduced problems because the magnitude of the interpolated vector wouldn't be 1. Then when you do (N.L) you get too small a result. Bottom line is you need to normalise the vector in the shader program, but I've never experimented.

I guess you might get away with it if the normals you're interpolating between are close to each other, but that doesn't give a very bumpy surface :|
 
Sxotty said:
All I can say is I hope the game looks nothing like that. It was crazy I have never seen such shiny rusted metal. It was horrid. BTW I have not watched that many videos of half life b/c I am planning on buying it, and dont want to ruin it, but I have watched 2 others and they look better to me so I am relieved. Why couldn't one see the sky from inside the barn? Oh and btw the sunbeams in Tenebrae on the part where you select difficulty I think look better :).

I ran it again--there's at least one large section of the roof in the barn though which the normal sky (clouds) is plainly visible. It's also easy to see the sunbeams through the HDR-effect holes in the roof which are getting direct sunlight, which justifies the HDR effect in them when viewed from the appropriate angle. Also the metal roofing looked very convincing to me. Check out the overcast sky, partially filled with moisture-laden clouds, the wind in the rooftop alleyway--and it's obvious that if it hasn't just rained it's at least drizzled--which is normal daily weather for some climes. As well, these aren't playable demos--they are movies--and as always something will be lost in the translation.
 
Laa-Yosh said:
So, the aliasing problem is most likely caused by the bump map; thus, wouldn't anisotropic filtering be a solution for it?

Nope. The problem does not occur from texture sampling. It's the functions applied on the values that gets undersampled so to speak. Texture filtering can ensure that we get a good representation of the mean value of the function encoded in the texture over the area of the texture that it maps to a certain pixel. For normals this means we get a reasonably good average normal. Then we apply lighting to that. But what we really need is a good average value of the lighting over this area. To do that however, you'd need to perform some sort of supersampling in the shader.
 
Some of the HDR effects where somewhat strange. If you look at the light through the holes, the light 'crawls' over the edges (I don't know how to describe it better). However, whenever another wooden pillar was in front, I couldn't really see the light crawling over the edges of that pillar. Somewhat strange. Anyone else noticed the same thing?
 
PSarge said:
I thought interpolating vectors linearly introduced problems because the magnitude of the interpolated vector wouldn't be 1. Then when you do (N.L) you get too small a result. Bottom line is you need to normalise the vector in the shader program, but I've never experimented.

I guess you might get away with it if the normals you're interpolating between are close to each other, but that doesn't give a very bumpy surface :|

Yes, normals may have to be normalized. But that's still not the solution. Normalizing the normal makes the lighting look more right, but it doesn't solve aliasing either since that's not the source of it, actually tend to intensify the aliasing slightly too.
 
sonix666 said:
Some of the HDR effects where somewhat strange. If you look at the light through the holes, the light 'crawls' over the edges (I don't know how to describe it better)

It's called "Blooming" and it's there by design. It's an effect that happens in camera lenses (and the human eye?) where a bright light source tends to bleed into the surrounding area when you look at it. I think it's all down to light scattering in the lense of the camera / fluid of the eye. It's there all the time, but a bright light source makes it noticable.

Humus said:
Nope. The problem does not occur from texture sampling. It's the functions applied on the values that gets undersampled so to speak.

So if the texture maps aren't the source of the high frequency information, what do you think is? The output of a function which has frequncy-limited inputs, is still frequency-limited. The only other inputs to shaders are vertex variables, which tend to be low-frequency as they're interpolated across polygons.
 
PSarge said:
Humus said:
Nope. The problem does not occur from texture sampling. It's the functions applied on the values that gets undersampled so to speak.

So if the texture maps aren't the source of the high frequency information, what do you think is? The output of a function which has frequncy-limited inputs, is still frequency-limited. The only other inputs to shaders are vertex variables, which tend to be low-frequency as they're interpolated across polygons.

The output of a *NON-LINEAR* function is *not* frequency-limited. A function like a varying conditional has no frequency limit at all. A specular lighting calculation for a highly shiny surface is really quite close to a varying conditional.

-mr. bill
 
mrbill said:
The output of a *NON-LINEAR* function is *not* frequency-limited. A function like a varying conditional has no frequency limit at all.

Yes, you're right. I had assumed we were talking about a function more like simple adds and multiplies.

A specular lighting calculation for a highly shiny surface is really quite close to a varying conditional.

I don't understand that statement though.
 
PSarge said:
mrbill said:
A specular lighting calculation for a highly shiny surface is really quite close to a varying conditional.

I don't understand that statement though.

Code:
#define EPSILON 1.52587890625E-05

    float NdotH = clamp( dot(normalize(N), normalize(H)), 0.0, 1.0 );

#ifdef PERFECT_REFLECTOR
    // As Shininess goes to infinity, the only time specularIntensity is non-zero
    // is at the perfect relfector angle when NdotH  == 1.0 (don't forget EPSILON)
    float specularIntensity = step( 1.0-EPSILON, NdotH );
#else
    float specularIntensity = pow( NdotH, Shininess );
#endif

-mr. bill
 
Back
Top