Shadow Depth Buffers on Radeon 8500

Although GeForce3 has less texture combiners and not as flexible per-pixel operations as the Radeon 8500, it currently has 1 very strong advantage over 8500, which is the ability to do percentage-closest filtering & compare on 16/24 bit single-value textures (e.g. proper sampling/comparing from depth-buffers to do shadow-mapping).

On 8500, i’ve tried two approaches which look a magnitude worse than what i can acheive on the GF3.

The first is taken from the Nvidia GF2 technique which approximates a 16bit depth compare via 2 8bit compares. This requires more bandwidth than the GF3 approache since i have to render depth to the color buffer or do a costly copy_depth_buffer_to_texture.

The second approach iterates a distance-field RGBA8888 “object_id” and does the same comparision as above with 4 compares (which actually works well for cube-map-point-lights). However, either i point-sample the object_id and its edges are pixelated compared to the GF3 sampling (where i get a 0…1 fall-off value), or i bilinear sample the 8500 object_id, but it leaks horribly onto unshadowed/incorrect surfaces.

Has anyone else attempted to do image-based shadowing on an 8500?

Does anyone know if ATI intends on exposing anything else for the 8500?

[ Back when Radeon first appeared, i wrote devrel@ati about the api-absent object-id 32bit compare texture-sampling yet i never receieved a response. They had screenshots and DX7 code on their site about it, but it never materialized. ]

Although GeForce3 has less texture combiners and not as flexible per-pixel operations as the Radeon 8500, it currently has 1 very strong advantage over 8500, which is the ability to do percentage-closest filtering & compare on 16/24 bit single-value textures (e.g. proper sampling/comparing from depth-buffers to do shadow-mapping).

What is this feature? I’ve never heard of any NV extension exposing anything like this.

hi Korval,

The ‘feature’ is the SGIS_Depth_Texture / SGIS_Depth_Compare (or a similar name, am not in front of code right now). Check out both extensions and associated docs on the NV dev site.

There are 3 main benefits that aren’t effectively emulated.

  1. Direct use of depth-buffer values as a texture type (16, 32 or 24(+8) bpp)

  2. Percentage-closer filtering used when bilinearly sampling a texture using texcoords s & t. This avoids the classic bilinear interpolation which causes inaccuracy & popping on depth-shadows.

  3. Comparision operator using the iterated texCoord’s r compared to the s,t value computed in 2).

These capabilities have non-photo-realistic-art-style uses beyond depth-buffers and are yet to be fully exploited-

Isn’t it the drivers which expose a depth buffer as a texture? I would really like to be able to use shadow buffers on the 8500…