HL2 and aliasing

john carmack mentioned the problem of texture aliasing with specular lit normal maps in his latest plan file

Renormalization of surface normal map samples makes significant quality
improvements in magnified textures, turning tight, blurred corners into shiny,
smooth pockets, but it introduces a huge amount of aliasing on minimized
textures. Blending between the cases is possible with fragment programs, but
the performance overhead does start piling up, and it may require stashing
some information in the normal map alpha channel that varies with mip level.
Doing good filtering of a specularly lit normal map texture is a fairly
interesting problem, with lots of subtle issues.

 

OK, I see your point.

Ouch, Using the step function normally means your on the road to alias city. It introduces a infinitly sharp edge. Does HLSL have smoothstep (I'm more from RenderMan land)?

...and Yes, raising shinyness very high will have a similar effect.

You win (but I'd expect to against mr bill)

 

In this case it means you've ARRIVED at alias city. And even though the specular power function doesn't introduce an infinitely sharp edge, it's still introducing a sharp edge, which also puts you at alias city.

The example above is actually OpenGL Shading Language, but yes, both the OpenGL Shading Language and HLSL have smoothstep.

-mr. bill

 

I think the aliasing is caused by not using or bad use of dsx/dsy. These shader instructions compute the texture gradients, which are needed to select the correct mipmap level.

When sampling an environment map for bump mapping, you read the texture indirectly and non-linearly, so the mipmap level does not vary like a regularly 'flat' textured polygon.

Maybe even using dsx/dsy correctly doesn't solve the problem, because the bump map makes the environment map sampling so 'random' that it would look blurred. Furthermore you can't mipmap a bump map as easily as a regular texture...

 

Actually, you can't mipmap a bump map at all. The effect of mipmapping a bump map is either to flatten out the bumps, or to expand the width of the bumps.

The former is usually the more 'acceptable' solution visually, but the fundamental problem is that the mipped bump map may reference multiple separate vectors, and since the lighting can be massively dependent on the exact vector, you really need to evaluate every one of these possible paths and sum them.

Anything that involves mipmapping bump maps is going to look wrong, one way or another.

 

Two words

Super Sampling.

 

Two more words: Poor performance.

 

Then just supersample only the scene area in question.

 

Uh, you can't do that very easily. For one, how do you go from supersample to non-supersample and back? Your depth data won't make sense at all.

 

Just like multi-sampling, but with multiple samples processed by the shader?

 

This is actually a problem with all pixel shaders I believe unless I am mistaken if you use a shader to create a checkboard texture to a surface you will not get the blurring that occurs with mipmaping of a texture.

What has to happen but won't for a few more years is all pixel shaders have to be written to a texture and then resampled as a texture or something similar this allows for the super sample and you won't have to worry about the Z problems .

Just like SS this has bad preformance.

 

Not to say that things are all perfect, but I just took a gander at the video, and it's not very good. There's tons of aliasing due to the video compression used/encoding.

I saw the original (on a giant plasma screen) and it was awsome. I would of noticed the bad artifacts, which appear on the video.

You will be impressed with the real thing.

 

I hope not. That would mean I would have to go outside to buy it.

 

Isn't that what Steam is for, to stop you agoraphobic people from having to worry about going out?

 

Oh yeh. Hehehe.

 

That's a very good point, actually. (I think mrbill is having a discussion around this in another thread as well).

 

You can in a lot of cases: In a past job we had AA'd procedural textures in a raytracer using just one 'sample' and knowledge of the size of the area to be sampled.

 

That's the classic way of AA in shaders.

The problem here (and I think I finally understand where Humus is coming from. Sleep is wonderful) is that a small area on a surface which has high curvature can have reflected in it the image of a very large area.

Think about a shiny ball bearing in a cathedral. If that ball bearing covers just a single pixel in the rendered image then it's colour should be the average of the whole environment, but what it's more likley to be is a single sample of the environment map in a reflection direction. As you move the reflection direction will change wildly and hence alias.

I guess what you'd want to do is calculate a LOD for the environment map look-up, but that's not necessarily easy.