Projected shadows on th 8500, have a look...

Boke

Boke

New member
Pay no attention to the FPS, I have been messing with Dot3 bump mapping and somehow slowed everything way down, I will fix it soon.

Now for the problem.. I only have 256 Z shadow values to compare to the Z buffer. If anyone here can think of a way to encode the Z depth value into an RGBA using a pixel shader ( OK.. OK... Fragment shader )... PLEASE?! share the knowledge :)

shadows.JPG
 
Last edited:
Thanks guys!!

NitroGL
I have a question... In the pic above I have a base texture in texture stage 0, a bumpmap loaded stage 1, the shadow map in stage 2, and stage 3 contains the Z depth. If I sample the bump texture in the shader using 'tex t1' my frame rate falls in half, to what you see above. If I pull the 'tex t1' out, it runs at about 120 fps. I'm not actually doing anything with the texture, just sampling it causes the problem. I don't seem to be thrashing textures, and I can't possibly be maxing the fill rate. Do you have any ideas what the problem could be? I thought multi-texturing was supposed to be practically free...
 
Boke said:
Thanks guys!!

NitroGL
I have a question... In the pic above I have a base texture in texture stage 0, a bumpmap loaded stage 1, the shadow map in stage 2, and stage 3 contains the Z depth. If I sample the bump texture in the shader using 'tex t1' my frame rate falls in half, to what you see above. If I pull the 'tex t1' out, it runs at about 120 fps. I'm not actually doing anything with the texture, just sampling it causes the problem. I don't seem to be thrashing textures, and I can't possibly be maxing the fill rate. Do you have any ideas what the problem could be? I thought multi-texturing was supposed to be practically free...
Click to expand...

Is the bump texture actually being used? I've noticed that for some reason it'll slow way down if the texture is never use, but just sampled. If that's not the case, then I'm not exactly sure (might be a quark of D3D).
 
If you ask to sample a texture it will sample the texture. Driver optimizations can be made to recognize when a sample isnt being used, but its not a case that should really happen in a final app so it hasnt been done. In effect, you get what you ask/deserve.

In a bandwith bound situation (do the math to see what is being used), just sampling the texture will slow you down. And with 32 bit trilin textures as with your normal map, you will find yourself being bandwidth bound more often than not.

Try turning off trilin with the normal map, or *ick* using a compressed or 565 normal map if you can get away with the quality loss.

---

hmm.. I havent tried squeezing more precision out of a depth channel for shadowmapping yet, but here's an idea: use a clamped texture read to sample a 1D texture with encodes it into some color value, probably a 16 bit one for bandwidths sake. maybe ARGB4444 cuz it its nice and evenly distributed.

Then on the light pass, do the same depth value 1d texture lookup and the old result read. There should be something involving a subtract between the two, followed by a dp4 with color channel importance weightings, and a cmp to give you the result you want..

sounds like it could work to me.. Ehn.. I havent thought it through much, so sometimes things that sound like it could work end up not in the end.

good luck!
 
CBrennan [ATI]

Thanks for the reply!!

"just sampling the texture will slow you down"
Ok.. thats what I thought.. I just thought it might be a problem in my code.

"use a clamped texture read to sample a 1D texture with encodes it into some color value"

I tried that one.. it worked.. but still not enough precision.

Edit:
I must have done something wrong with the 1D lookup it should work better than what is posted below.

With help from 'binaur' at http://www.shaderstudio.com ( He made a very nice shader tool ), I came up with this, I'm sure its not perfectly accurate but it does a very good job. I am using it to render the depth as an rgb ( with a small change you can do rgba ) values to a texture.
Code: 
c0 = Transform matrix
c4.z = 3.0 / FarPlane
c5 = 0, 1, 2, 3

vs.1.1 
m4x4 r0, v0, c0 
mov oPos, r0 
mul r1, r0.z, c4.z  
sub oT0, r1, c5 

ps.1.4	
texcrd r0.rgb, t0.xyz 
+mov r0.a, c0.a
 
Last edited:
LOL,

Yea, Thats the part binaur helped me with. At first it made no sense to me either.

Here is whats happening..

"mul r1, r0.z, c4.z"
Scales the z depth by 3.0/FarPlane, this scales the depth to the 0.0 to 3.0 range and places the depth it into all channels of r1.

"sub oT0, r1, c5"
'Spreads' the Z depth out, and into, the 3 color channels.... (The 3 in "c5 = 0, 1, 2, 3" is only needed if the alpha channel is used.)

This all works because the values are clamped to the 0 to 1 range when written to the texture.

zDepth = 400; FarPlane = 500:

zDepth * 3.0/FarPlane = 2.4;

r = saturate( 2.4 - 0 ) = 1.0
g = saturate( 2.4 - 1 ) = 1.0
b = saturate( 2.4 - 2 ) = 0.4

I hope that makes sense... but now that I look at things again... I only end up with 768 possible depth values :mad: Back to the drawing board...
 
hmm.. spreading it out that way can only recover at most 2 lost bits or x4 range.. x3 as you've got it done. I was thinking more of actually sampling a texture, say a 2048x1 texture (or smaller if you rely on the bilin filter to fill in the gaps) to do an arbitrary mapping into multiple color channels. one way to do it is put the top 8 bits in R, the next 8 bits in green, and the lowest 8 bits in B, but that is aggressive given that there are only 2048 texels, but you can play..

I believe that you can get somewhere between 12 and 16 bits of precision this way..

Ugh, I can't wait until this type of thing is just an unhappy memory of the way things were.
 
Yea.. it looks like the 2048x1 texture lookup is the best option.
I pulled my far plane back to 50 and got acceptable results, but I would really like to get it out to at least 100. Thanks again for your input!

"Ugh, I can't wait until this type of thing is just an unhappy memory of the way things were."

:)
 
Boke said:
LOL,

Yea, Thats the part binaur helped me with. At first it made no sense to me either.

Here is whats happening..

"mul r1, r0.z, c4.z"
Scales the z depth by 3.0/FarPlane, this scales the depth to the 0.0 to 3.0 range and places the depth it into all channels of r1.

"sub oT0, r1, c5"
'Spreads' the Z depth out, and into, the 3 color channels.... (The 3 in "c5 = 0, 1, 2, 3" is only needed if the alpha channel is used.)

This all works because the values are clamped to the 0 to 1 range when written to the texture.

zDepth = 400; FarPlane = 500:

zDepth * 3.0/FarPlane = 2.4;

r = saturate( 2.4 - 0 ) = 1.0
g = saturate( 2.4 - 1 ) = 1.0
b = saturate( 2.4 - 2 ) = 0.4

I hope that makes sense... but now that I look at things again... I only end up with 768 possible depth values :mad: Back to the drawing board...
Click to expand...

Ahh.
 
I'd like to ask a bit different question but on-topic.
I'm using Object-ID for my shadow-maps and sometimes I get in shadow-pass some artifacts which are caused by different resolution of shadow-map and screen (color buffer). I'm using 512x512 as a shadow-map. I don't have any problems when lighted objects are close to the light. But if they're far there's a lot of jaggy edges.
Do you have any tips or ideas how to avoid this? (as far as it's possible to avoid)
The screenshot from the first post of this topic looks great! No any artifacts.

Thanks
 
"The screenshot from the first post of this topic looks great! No any artifacts."

I afraid thats because I had the camera and light set to almost the same position. I get jaggy edges too, probably worse than you are getting.

"Do you have any tips or ideas how to avoid this?"
One thing that would help is to use a shader to make the shadow get lighter as the distance from the light increases. That would make the shadows look more like they do in real life too. I have not tried it yet, but it should be pretty easy to do.
 
You must log in or register to reply here.
Back
Top