Will next generation h/w be alot harder to review?

[andypski]

Of course it should also possible to use the same shader method on NV3x hardware, although currently the available depth resolution might be lower because floating point render targets are not available.

Why would you need FP render targets for shadow buffering?

You don't - I already said that. You could use 16-bit int, or 16-bit FP, or 32-bit FP, or 8-bit int or whatever - it just needs to meet your requirements for depth-resolution.

btw, I think it's a poor design decision that "D3D has no concept of PCF". Same for the ARB shadows extension.

Perhaps so, but that's the way it is. Naturally it is likely to be faster to do something like PCF in dedicated hardware, and an argument can therefore be made for it. On the other hand, modern shader performance should be high enough that it's not really much of a problem. Perhaps now PCF on shadow buffers may become less attractive anyway, with the emergence of new approaches to soft shadow borders such as smoothies. The degree of smoothing of the shadow border obtained just with PCF is not particularly great, and certainly not particularly compelling when compared to these sorts of shadow approaches.

 

[X2]

Of course it should also possible to use the same shader method on NV3x hardware, although currently the available depth resolution might be lower because floating point render targets are not available.

Why would you need FP render targets for shadow buffering?

You don't - I already said that. You could use 16-bit int, or 16-bit FP, or 32-bit FP, or 8-bit int or whatever - it just needs to meet your requirements for depth-resolution.

But the NV2x/3x offers D24X8 for shadow buffering, so I don't understand the "depth resolution might be lower" comment. You don't offer more than 24bit, do you?

 

[Hyp-X]

But the NV2x/3x offers D24X8 for shadow buffering, so I don't understand the "depth resolution might be lower" comment. You don't offer more than 24bit, do you?

He was talking about (in that sentence) running the shader based implementation on NV3x cards, not using the hardwired one.

If you use the shader based approach you stuck with whatever render target formats are available - you can't use D24X8 because it's functionality is overloaded.

 

[X2]

Ah right, I forgot you won't get the depth value from the texture into the shader, just the comparison result.

 

[andypski]

Of course it should also possible to use the same shader method on NV3x hardware, although currently the available depth resolution might be lower because floating point render targets are not available.

Why would you need FP render targets for shadow buffering?

You don't - I already said that. You could use 16-bit int, or 16-bit FP, or 32-bit FP, or 8-bit int or whatever - it just needs to meet your requirements for depth-resolution.

But the NV2x/3x offers D24X8 for shadow buffering, so I don't understand the "depth resolution might be lower" comment. You don't offer more than 24bit, do you?

Yes, but I was talking about using a standard interface, which requires the use of standard textures rather than attaching a depth buffer as a texture. The refrast does not allow you to do this, hence this would not work in a 'reference' implementation. I don't deny that you can use D24X8 if you don't want to use a standard interface that will run on the reference renderer for the API.

[EDIT] Looks like someone beat me to it [/EDIT]

 

[KimB]

Of course it should also possible to use the same shader method on NV3x hardware, although currently the available depth resolution might be lower because floating point render targets are not available.

Why would you need FP render targets for shadow buffering?

Because there's a depth compare involved. You might not, of course, need FP render targets, but would at least need high-precision integer targets.