30 replies to this topic

[john]

Is there a way to get around the precision issues caused when doing per-pixel specular lighting in pixel shaders? The problem is, when doing the specular exponent in shaders, it causes banding and most of the time the specular value is ugly. What do you guys suggest?

[Altair]

Which shader model are you using?

[john]

I'm using pixel shader 2.0

[Kenneth Gorking]

Try to use floats, if possible, and check your computations: you might be using half datatypes somewhere, which gives some banding.

[Altair]

With ps2.0 you can make a look-up to a specular texture, where x=saturated dot prod between light vector and view-reflection about the normal, and y=specular exponent. Alternatively you can use pow instruction.

[davepermen]

both solutions shouldn't have any precicion issues. the specular texture was possible with ps1.4, too, and made faked solutions with ps1.1 - ps1.3 look really ugly.

there should not be any issues with ps2.0 at all..

[Altair]

You can use the specular look-up even on ps1.1, but that's more tricky and you have to use half-vector approach which doesn't quite give correct results. ps2.0 has no challenge ;)

[davepermen]

it will not be per pixel correct as the code will not be independent on the vertex-layout of your mesh (you can't just subdivide and get the same image..).

i'm only talking about solutions that give a real solution, not some approx.. else yes, 1.1 can fix the precision issue like 1.4 can..

[Altair]

Quite often approximations are real solution in practice :) Half-vector specular lighting is very commonly used technique.

[davepermen]

it's just a very commonly used technique because on pre-ps1.4, other solutions simply don't fit well into the shaders at all.. doesn't make it useful. (per-vertex-half-vector with interpolation, that is.. you can evaluate it per pixel, thats a non-issue and of course and works fine).

[Altair]

davepermen said:

it's just a very commonly used technique because on pre-ps1.4, other solutions simply don't fit well into the shaders at all.. doesn't make it useful. (per-vertex-half-vector with interpolation, that is.. you can evaluate it per pixel, thats a non-issue and of course and works fine).

Not only because it suits well to <ps1.4, but because it's also cheaper in latter models as well and quite often suitable solution. Depends on the case what kind of solution you should use (i.e. your poly density).

[davepermen]

sure. anyways, i'd continue to only suggest general solutions that work no mather in what situation, and, if later needed, optimisations for special situations.. this is one.

[Altair]

When working with artists, it's actually better to go other way around. If you start with half-vector approach they can tweak the data from the start to reach required accuracy. Anyway, it of course depends how much you can gain by using half-vector approach (performance/quality/compatibility) if you should see the trouble of supporting both approaches.

[davepermen]

well, i never worked personally with pre-dx9 hw-shaders at all, so i won't ever care anymore about it.. requiring dx9 isn't a big issue anymore, as long as the other requirements are quite high-end, too (means, it's worth the dx9-requirements), and then, those tweaks won't ever mather.

[Altair]

It's not big issue if you are not planning to sell a lot of copies ;) As I said, even in latter shader models you want the shading to perform well.

[davepermen]

you don't have any performance advantage in not doing it correctly in dx9. thats what i'm saying.

[Altair]

Oh really? Can you tell me how do you do that without any performance hit?

[davepermen]

just put the ordinary equation in.. i have not discovered any real performance-hit.. the math is minimal to do it 'correctly' (correct phong).

[Altair]

Heh, well last time I checked (nvshaderperf), on nv40 calculating reflection vector in pixel shader results 2 cycle performance hit, which may be significant depending on what you are doing.

[davepermen]

you can still do halfangle (if you double the angle afterwards again:D). but teh ending math is about the same then. if you do halfangle per pixel, it works great. but for ps1.3 you have to do it per vertex, where it's inherently wrong. thats why i didn't suggest it by myself.

reflection is a dot, a mul, a sub.. halfangle requires two normalized vecs to get added, renormalized, then dotted, and then the angle-cosine doubled with some trigonometric identity.. takes longer. at least, on paper.