MRT depth texture and alpha problem

[Hawkwind]

My pixel shader renders colour to an off-screen target surface and depth to a second target surface (for use in Depth of Field later ).

This is ok if my destination blend is zero, and source blend is one (as is the
case for opaque rendering). When I render alpha though I use INVSRCALPHA
and SRCALPHA ( as usual ). Unfortunately this seems to affect the value
written to my second target surface - understandable I suppose since it could be envisaged as just another pixel rather than a depth target.

In this case is it necessary to render twice... once for the colour and then
without alpha (and with the colour disabled) to get the depth target values ?
or is there an amazing way round this ?

Cheers

[starstutter]

ummm, well, here's what I can tell you.

It depends on what you're doing, but in most cases of your situation you certainly don't need to set up another render target to capture depth. You can just use the 'a' channel on the main render target provided you don't have anything transparent. And besides, you should be rendering the transparent pieces in another pass anyway (at least that's how I've always been told to do it).

As for the depth target being effected, I would render it on screen and make double sure that it's not rendering things transparently. If you have one transparent depth value on a pixel that overlaps another transparent one, you end up with a different value that neither of them have... which is of course bad.

I admit I don't know a whole lot about MRT's, so sorry if this post wasn't helpful. However, if you can follow the method above it would save you some memory and an extra rendering pass.

EDIT: oh and also, I can't really use what is described above because I also mix in motion blur with DoF, so I need at least 3 channels (Depth, speedX, speedY)

[Hawkwind]

Thanks, I do renderi the alphas AFTER all the opaques. Unfortunately the
alpha channel of the target is used, so I have to use another target (and also I need accuracy for the depth so I use a R32F format for the depth target).
It just seems that anything alpha which I render is not causing the depth
target to update, and the reason seems tied up with the D3DRS_SRCBLEND
and D3DRS_DESTBLEND values.... if they are set for alpha blending then
the pixel shader write to oC1 ( used as the depth target ) appears not to
happen...

[starstutter]

I have to use another target (and also I need accuracy for the depth so I use a R32F format for the depth target).

hmmmm, I won't argue with you (because i don't know the full extent of what you're trying to do), but does depth of field really need that much accuracy? It seems like 16 bits would be more than enough to cover the rough distances you need for depth of field.


Thanks, I do renderi the alphas AFTER all the opaques. Unfortunately the
alpha channel of the target is used, so I have to use another target

Ah, ok, now I see what you're saying. I used to avoid this problem by copying the alpha information over (without rendering) to another texture. I'm still not totally sure how I did it, but it involved SretchRect() and it just seemed to work out and it was fast. Unfortunatley it becomes insufficient when motion blur enters the picture.

As for the real problem, I'm trying to come up with a checklist in my mind here:
1. Make sure you're not preforming a mistake that would make the values negative
2. Render the depth texture as a partial-screen quad, make the depth info visible by either changing the equasion to pure black or (depth *= .1)
3. Switch the depth rendering over to the primary target (main texture) to make sure there's no confusion between the output, and to make sure it's even outputting at all
4.One possibility might be that you're saying (Output: color.a) and this may not mix with the (R32F) format so well. That one may just be a desperate attempt but (R32F) is really meant to be used in the R channel. Worth a shot I suppose.

As for a solution, I would personally just make this a lot easier on yourself and do an additional rendering pass. There's a lot of advantages to this actualy:
-not everything needs to be rendered in the depth pass, or can be approximated. You can filter these on the CPU
-no dynamic branching
-don't have to filter through a complex vertex / pixel shader
-at any point, you can make easy modifications to include motion blur and one additional post-process of your choice with the remaining channel (HDR format)

As for how much power all it takes, I personally only see a 2 fps drop from an origional of 60 rendering a moderate scene. I just think you're making this a bit more complicated than it needs to be. Although if you're successful and it's faster I'd love to hear about the method.

[Reedbeta]

Does Direct3D provide no way to set different blend factors for different buffers in MRT?

[starstutter]

Does Direct3D provide no way to set different blend factors for different buffers in MRT?
Oh good point, I forgot to bring that up. I can't think of any as of now, but maybe an effect file possibly could make use of this.

[Hawkwind]

Reedbeta - Not on DX9

[Hawkwind]

Thanks for the pointers. At the moment I've 'worked round' it by doing a second render of the alpha mesh with a simple pixel shader that only updates the alpha buffer, I set:
DRS_SRCBLEND = D3DBLEND_ONE
D3DRS_DESTBLEND = D3DBLEND_ZERO
to do this render.
Its not nice, its far from elegant, but it works. My depth of field looks nice and has very little frame rate drop ( I use two passes for a Gaussian seperated on x axis for first pass, y-axis for second pass - and then the 2nd
pass also blends the unadulterated image with this blurred image according to
the distance from a focal point).
This means that I can go home from work now! - hopefully one day I'll find out why I have to do the second render, but for now I keep my job...
Cheers

[starstutter]

hopefully one day I'll find out why I have to do the second render, but for now I keep my job...

glad to help :D