I have tried my pixelshader in another program called Shader Studio. It looks to work ok on a pixel basis there without those wierd blocks. What am I doing wrong? I''m basicly following the DX8.1 manual on how to set up my application.
It is the same texture that is set as texture stage 0 and 5.
blocky texdepth (PS.1.4)
Author
Have anyone tried doing depth-sprites using the texdepth instruction in pixelshader 1.4 (DX8.1) yet? I have run into problems on my ATI Radeon 8500 card.
My intention is to replace the z-value for each pixel rendered with the value specified in another texture. It all works fine in the reference driver but when I use the HAL driver I get blocky distortions in the whole Z-buffer. Even polygons rendered without an own pixelshader will get wrong Z-values in some sort of blocky way.
I use the following code:
ps.1.4
texld r5, t0
phase
texld r0, t0
texdepth r5
Below is a screenshot showing the error. The square in the middle is the one with the pixelshader. The white rectangle is supposed to show partly behind the middle square (which it does), but not in that blocky way. The white polygons are supposed to go through the black square and hide some parts of it, which it doesn''t. The white and the black polygons are not rendered using a pixelshader, but their Z-test get blocky in some weird way anyway.
I have tried my pixelshader in another program called Shader Studio. It looks to work ok on a pixel basis there without those wierd blocks. What am I doing wrong? I''m basicly following the DX8.1 manual on how to set up my application.
It is the same texture that is set as texture stage 0 and 5.
I have tried my pixelshader in another program called Shader Studio. It looks to work ok on a pixel basis there without those wierd blocks. What am I doing wrong? I''m basicly following the DX8.1 manual on how to set up my application.
It is the same texture that is set as texture stage 0 and 5.
Have you tried upping the Z-buffer accuracy?
Neil
WHATCHA GONNA DO WHEN THE LARGEST ARMS IN THE WORLD RUN WILD ON YOU?!?!
Edited by - thedo on February 5, 2002 12:12:03 PM
Neil
WHATCHA GONNA DO WHEN THE LARGEST ARMS IN THE WORLD RUN WILD ON YOU?!?!
Edited by - thedo on February 5, 2002 12:12:03 PM
Are you setting your pixel shader to NULL after you use it the first time?
If you don''t do this, then its still using your pixel shader, not the stndard TS pipe.
If you don''t do this, then its still using your pixel shader, not the stndard TS pipe.
- Is the window you display in bigger than the surface you''re creating ?
- Are you allocating your own Z buffer or are you using the auto* parts of the present parameters ?
If the Z buffer size were somehow smaller than the rendered size, I''d expect something like what''s in the picture.
- What''s the distance between your near and far clipping planes ?
If its too large you lose Z accuracy - even a 32bit z buffer won''t save you if its too large. ~80% of that accuracy is in the first 20% of the Z range.
- Are you doing anything with stencil buffers ?
- Are you doing anything with alpha test ?
- Are you doing anything with colour keys ?
- Are you clearing the Z buffer, and also only clearing the stencil if you use it.
Many cards share the Z buffer memory with their stencil buffers. Also the Z in the pixel pipe might be being done with the one of the colour channels or alpha.
Does your code work ok on RefRast ?
--
Simon O''''Connor
Creative Asylum Ltd
www.creative-asylum.com
- Are you allocating your own Z buffer or are you using the auto* parts of the present parameters ?
If the Z buffer size were somehow smaller than the rendered size, I''d expect something like what''s in the picture.
- What''s the distance between your near and far clipping planes ?
If its too large you lose Z accuracy - even a 32bit z buffer won''t save you if its too large. ~80% of that accuracy is in the first 20% of the Z range.
- Are you doing anything with stencil buffers ?
- Are you doing anything with alpha test ?
- Are you doing anything with colour keys ?
- Are you clearing the Z buffer, and also only clearing the stencil if you use it.
Many cards share the Z buffer memory with their stencil buffers. Also the Z in the pixel pipe might be being done with the one of the colour channels or alpha.
Does your code work ok on RefRast ?
--
Simon O''''Connor
Creative Asylum Ltd
www.creative-asylum.com
Author
> - Is the window you display in bigger than the surface you''re
> creating ?
No.
> - Are you allocating your own Z buffer or are you using the
> auto* parts of the present parameters ?
I use EnableAutoDepthStencil = TRUE. Does this pose a problem?
> If the Z buffer size were somehow smaller than the rendered
> size, I''d expect something like what''s in the picture.
It''s not only that the Z-buffer is smaller. It gives incorrect values too it seems. And it works just fine as long as I don''t use the texdepth instruction at all. If I use the pixelshader without the texdepth, the white and the black polygons looks nice again.
Here''s a screenshot using HAL without the texdepth in the shader.
> - What''s the distance between your near and far clipping > planes ?
1 to 1000 right now.
> - Are you doing anything with stencil buffers ?
No. I use the D3DFMT_D32 as Z-buffer format.
> - Are you doing anything with alpha test ?
No.
> - Are you doing anything with colour keys ?
No.
> - Are you clearing the Z buffer, and also only clearing the
> stencil if you use it.
The Z-buffer is cleared with D3DCLEAR_ZBUFFER.
> Does your code work ok on RefRast ?
Yes, I will include a picture of the same scenario as above but with the REF shader just to give you the feeling of how it should look.
As you can see, no blocky artifacts and the white polygons go through the black polygons.
And I do set the pixelshader to NULL before I draw the white and the black polygon. I also set the textures to NULL.
> creating ?
No.
> - Are you allocating your own Z buffer or are you using the
> auto* parts of the present parameters ?
I use EnableAutoDepthStencil = TRUE. Does this pose a problem?
> If the Z buffer size were somehow smaller than the rendered
> size, I''d expect something like what''s in the picture.
It''s not only that the Z-buffer is smaller. It gives incorrect values too it seems. And it works just fine as long as I don''t use the texdepth instruction at all. If I use the pixelshader without the texdepth, the white and the black polygons looks nice again.
Here''s a screenshot using HAL without the texdepth in the shader.
> - What''s the distance between your near and far clipping > planes ?
1 to 1000 right now.
> - Are you doing anything with stencil buffers ?
No. I use the D3DFMT_D32 as Z-buffer format.
> - Are you doing anything with alpha test ?
No.
> - Are you doing anything with colour keys ?
No.
> - Are you clearing the Z buffer, and also only clearing the
> stencil if you use it.
The Z-buffer is cleared with D3DCLEAR_ZBUFFER.
> Does your code work ok on RefRast ?
Yes, I will include a picture of the same scenario as above but with the REF shader just to give you the feeling of how it should look.
As you can see, no blocky artifacts and the white polygons go through the black polygons.
And I do set the pixelshader to NULL before I draw the white and the black polygon. I also set the textures to NULL.
Author
I have made some more research into my problem.
It seems that the problem with blockyness in the Z-buffer occurs if I switch from my pixelrenderer using the texdepth instruction (the middle square) to a pixelshader not using that instruction (the white and black rectangles).
I wrote a dummy-shader for the black and white rectangles. If I include a texdepth in that shader too, it will render without blockyness. If I do not have texdepth in it, it will be blocky.
What shall I do? I don''t want a pixelshader for the other geometry I''m going to render. Atleast I don''t want to write the Z-value with texdepth myself. Or can I get the Z-value it was supposed to write anywhere and write that with texdepth myself?
I guess this is probably a question for the ATI dev support, but could this artifact have something to do with their HyperZ thing?
It seems that the problem with blockyness in the Z-buffer occurs if I switch from my pixelrenderer using the texdepth instruction (the middle square) to a pixelshader not using that instruction (the white and black rectangles).
I wrote a dummy-shader for the black and white rectangles. If I include a texdepth in that shader too, it will render without blockyness. If I do not have texdepth in it, it will be blocky.
What shall I do? I don''t want a pixelshader for the other geometry I''m going to render. Atleast I don''t want to write the Z-value with texdepth myself. Or can I get the Z-value it was supposed to write anywhere and write that with texdepth myself?
I guess this is probably a question for the ATI dev support, but could this artifact have something to do with their HyperZ thing?
Kjell,
The problem is not likely the number of bits in your depth buffer but, rather, the precision of the z coming out of the pixel pipeline. What you want to do instead of using a texel channel directly as depth is treat the texel channel as "delta depth" and add it (possibly while making it signed with a _bx2) to the interpolated depth (stuffed into a texture coordinate channel by your vertex shader). I''m on the road or I''d hack up some (tested) code for you. In any event, this is very likely the jist of the problem. We can discuss this more when I''m back in the office and have access to my 8500 box.
-JasonM at ATI
The problem is not likely the number of bits in your depth buffer but, rather, the precision of the z coming out of the pixel pipeline. What you want to do instead of using a texel channel directly as depth is treat the texel channel as "delta depth" and add it (possibly while making it signed with a _bx2) to the interpolated depth (stuffed into a texture coordinate channel by your vertex shader). I''m on the road or I''d hack up some (tested) code for you. In any event, this is very likely the jist of the problem. We can discuss this more when I''m back in the office and have access to my 8500 box.
-JasonM at ATI
Author
Jason,
What I''m trying to do is draw a prerendered background scenery into my 3D-scene. This means I have an image containing the color data and I also have an "image" containing the depth of each pixel. So I''m not really trying to do depth sprites, but rather some sort of image based rendering.
What you are saying is that I still should use some delta depth rendering in my shader to get it to work?
Regarding the .r/.g values sent to the texdepth instruction; Does these represent the .z/.w values resulting from the vertex shaders transformations?
What I''m trying to do is draw a prerendered background scenery into my 3D-scene. This means I have an image containing the color data and I also have an "image" containing the depth of each pixel. So I''m not really trying to do depth sprites, but rather some sort of image based rendering.
What you are saying is that I still should use some delta depth rendering in my shader to get it to work?
Regarding the .r/.g values sent to the texdepth instruction; Does these represent the .z/.w values resulting from the vertex shaders transformations?
i can only tell you where the squares come from.
they HAVE TO come from the "hyper-z" archtecture, or however ATI calls it.
GF3 has similar.
these cards cache a single z-value for every one 8x8 block in memory, its like a "z-mipmap" that speeds up things when testing many pixels that are close to each other.
but i cant imagine why this architecture would fail, making the squares visible.
hm.
--- foobar
We push more polygons before breakfast than most people do in a day
Edited by - foobar on February 13, 2002 5:16:31 PM
they HAVE TO come from the "hyper-z" archtecture, or however ATI calls it.
GF3 has similar.
these cards cache a single z-value for every one 8x8 block in memory, its like a "z-mipmap" that speeds up things when testing many pixels that are close to each other.
but i cant imagine why this architecture would fail, making the squares visible.
hm.
--- foobar
We push more polygons before breakfast than most people do in a day
Edited by - foobar on February 13, 2002 5:16:31 PM
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
