🔒 Locked

SetRenderTarget Method

Started by janoside Feb 1, 2006 at 12:16 PM 6 replies 1.8k views

Original Post

Feb 1, 2006 at 12:16 PM

I want to perform post-processing with normal data (for edge detection like in the C++ PostProcess sample). I have a pixel shader that outputs a COLOR0-semantic and a COLOR1-semantic value (for simplicity of debugging I just have the shader output a solid-color constant for both). When I render, I have the default render target set to index 0 and I have called SetRenderTarget to set index 1 to a render-target texture with: the same dimensions and format as the default RT, 1 mip level, and the RenderTarget Usage flag set. Is my understanding correct that the pixel shader should then write the COLOR0-semantic value to the 0-index render target and the COLOR1-semantic value to the 1-index render target? If I comment out the call: SetRenderTarget(1, myRenderTargetTexture), the main render target (i.e. the screen) looks fine, though clearly I don't have the normal data that I want. However, when I do call SetRenderTarget for my 1-index RTT, the screen does not get cleared, though I am still calling Device.Clear(ClearFlags.Target). Does Device.Clear clear all render targets? Anyone see any issues with what I am doing/my understanding of the process? Thanks in advance.

neneboricua19

Feb 1, 2006 at 12:33 PM

As long as you're calling SetRenderTarget on the appropriate surface of your render target texture before you call Clear, there should be no problems. The Clear method will clear the surface of any active render target.

Perhaps you could post a small code snipet of the problem?

neneboricua

janoside

Feb 1, 2006 at 2:44 PM

At initialization I grab the back buffer to make another RT:

backBuffer = this.Device.GetBackBuffer(0);// another Direct3D Surface for the 1-index RTthis.normalSurface = this.Device.CreateRenderTarget(     backBuffer.Description.Width,     backBuffer.Description.Height,     backBuffer.Description.Format,     backBuffer.Description.MultiSampleType,     backBuffer.Description.MultiSampleQuality,     false);

Then during rendering:

this.Device.SetRenderTarget(0, backBuffer);this.Device.SetRenderTarget(1, normalSurface);// clear all the RTs?this.Device.Clear(     D3.ClearFlags.Target | D3.ClearFlags.ZBuffer,     black,     1.0f,     0);// rendering here

Simply commenting out the line:

this.Device.SetRenderTarget(1, normalSurface);

makes rendering work as normal. But with the line active, the screen does not seem to be cleared and does not seem to render my 3d scene. Any suggestions would be greatly appreciated.

sirob

Feb 1, 2006 at 2:51 PM

Well, first off, make sure you set AA off when using MRTs. There was a whole long post about it, and if I recall correctly, it wasn't supported.

Second, it might be a good idea to try only clearing the z-buffer (and stencil, if you use it). Any problems with using MRT wouldn't affect the clear() if you're only clearing the z-buffer. So, any problems you might have with MRTs might not affect the rest of the scene.

Lastly, you didn't mention which version of MDX you are using. MDX2.0 has some issues, so if you're using that I can think of some more things to try.

janoside

Feb 1, 2006 at 3:01 PM

Crap! I didn't know about the AA issue. A lot of what I am doing is designed so that I can do AA-ed rendering with post-processing...so this is not good news.

...

Even worse news is that I just tried it without AA on and it does work. Thanks sirob for the info. I think this is the first time I have been foiled by an unsupported feature; it is really frustrating knowing that I can't fix it. I suppose I could render in two passes, but I'm not sure the performance hit will be worth it.

If anyone has an suggestions about how to do this I would love to hear them. In the meantime I guess I will look at rendering in 2 passes.

Thanks again

jollyjeffers

Feb 1, 2006 at 4:06 PM

Some hardware does support AA'd render targets iirc. I haven't tried it, but it's possible that using IDirect3DDevice9::CreateRenderTarget() with the level-0 surface of an IDirect3DTexture9 might work to get you an AA'd render target that you can feed into a post-processor.

The other option is to use IDirect3DDevice9::StretchRect() - my understanding is that in most cases it should be hardware accelerated, thus the hit shouldn't be too bad. You can copy from a multisampled render surface to a texture and feed the texture into the post-processor.

A final thing to try is dig around the ATI and Nvidia developer site - I've got a vague memory of seeing some samples about how to achieve post processing and AA on more recent GPU's.

hth
Jack

jamesw

Feb 1, 2006 at 8:48 PM

I can't think of a way to do it in one pass (and obviously giving up AA is unacceptable). One thing that occured to me though, is that if you eventually want to implement some depth based effects you can render the antialiased color in the first pass, and then use multiple targets to render normal and depth data in the second pass. This is still better than not having multiple render targets at all.

janoside

Feb 1, 2006 at 9:21 PM

Thanks a lot for all the input, I really appreciate it.

Quote:
The other option is to use IDirect3DDevice9::StretchRect()

I am already using this to get my color RT AA-ed (which I did get from NVidia's developer site, and I recommend it if anyone is interested), the problem is now that I want to render my color RT simultaneously with a Normal RT and a depth RT, all AA-ed.

Quote:
Some hardware does support AA'd render targets iirc

My 6800 does not support multiple simultaneous AA'd RTs, but strangely enough it does not throw an exception, it just renders incorrectly, which is very annoying (not that a DirectX exception would be much better :))

jamesw, you make a great point. I can render my color RT with AA enabled, then render a second pass with as many simultaneous RTs as my hardware can handle...maybe this won't be as much of an issue as I thought.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.