• Advertisement
Sign in to follow this  

Strange render target glitch - deferred lighting

This topic is 2653 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi,
I though it would be interesting to implement deferred lighting using C#/D3D9 (I want this app to have independence from XNA).
I've basically got it up and running, but can't seem to pin down the cause of some visual artifacts. When I compute lighting in the lighting pass, I use MRT's to write out diffuse/specular into separate buffers. Unfortunately, the render target bound to the 1th MRT index shows weird artifacts that flicker about - I'm interested to know if anyone has come across this problem. Interestingly, I use MRT's to simultaneously encode the depth and normal buffers in a prior render pass - both render correctly without these glitches.
Any help would be greatly appreciated!

help!

Share this post


Link to post
Share on other sites
Advertisement
I did give that a go - when I step through the pixel shader, correct values seem to be output on both COLOR0 and COLOR1. For an 'artifact pixel', the shader seems to be computing the right value - somehow it's just not appearing as it should in the render target - any ideas??
This really has me stumped :-(

Share this post


Link to post
Share on other sites
I know this kind of problem. Exactly that.
There are two possibilitys to solve this which I know.

From my research I found out that only the first bound rendertarget has this issue. Maybe it's different in your case, but you can try one of this:

- Swap the MRT order. Put the non-working to the end and put a working one to the front. If that works it would be the best.

- If that fails, try to leave a gap in the rendertargets. Don't bind the first one and shift everything back one slot. This isn't a nice solution, I know, but when it works...

I had a topic about this: http://www.gamedev.net/community/forums/topic.asp?topic_id=576785
Thats where I found out the second solution I told you here. It works, but as I said in my last posting there I wasn't very pleasant with it. So I did more research and found out about that swapping-trick. Hopefully this works for you, too.

Edit: No, wait. Just swapping them wasn't the solution. I forgot it! [sad]
Damn, I'll take a look at my code again to find out what I did.

Share this post


Link to post
Share on other sites
Hi thanks for your idea,
Suppose I was writing the diffuse color to RT0, and specular to RT1, do you suggest I flip it so that diffuse->RT1, specular->RT0?
I tried that, what I found was that the glitches occur independently from my shader code - it seems to be something deeper in the API/drivers (?)
I wondered if it was a problem with depth testing. I disabled depth testing but still no success.
I'm a little confused about your other idea - are you saying that I should write to RT0 and RT2 instead of RT0 and RT1?
Thanks
Dacre

Share this post


Link to post
Share on other sites
Quote:

do you suggest I flip it so that diffuse->RT1, specular->RT0?


Yes, it could work. I remember doing so, but I could be wrong. Looking through my code I see the same slots bound as they were in my other thread. Maybe you're lucky.


Quote:

I'm a little confused about your other idea - are you saying that I should write to RT0 and RT2 instead of RT0 and RT1?


No, not that way. Here is a quote from my thread:
Quote:

As a temporary solution (I'm not very pleased with it) I shifted the MRTs one slot to the right. So this:

ID3D11RenderTargetView* RTViews[ 3 ] = { TerrainNormals->RenderTargetView, TerrainDepth->RenderTargetView, TerrainLayers->RenderTargetView};




became this:


ID3D11RenderTargetView* RTViews[ 4 ] = { NULL, TerrainNormals->RenderTargetView, TerrainDepth->RenderTargetView, TerrainLayers->RenderTargetView};




And I have no flickering at all with this.


That means: Bind slot 0 to NULL, bind your other two rendertargets to slot 1 and 2.
Then, in your shader don't use slot 0, (COLOR0 I think in DX9...) but use COLOR1 and COLOR2.

You should look then how much that decreases your performance. Sometimes a gap in the rendertargets can be bad for it. If it isn't a problem you may leave it like that.

Share this post


Link to post
Share on other sites
Those artefacts suggest to me that maybe you have a render state set wrong. My first guess would be to try disabling z testing, stencil testing, and alpha testing.

Share this post


Link to post
Share on other sites
Hi,
it looks like I can't set render target 0 to null in c#/d3d9 - when I do this I get an exception (?)
I'll experiment with the render state before the lighting pass - I'll let you know how things go,
thanks for your help
Dacre

Share this post


Link to post
Share on other sites
Hi, I tried disabling stencil/depth - I think I've found the problem - I was clearing the depth buffer during the normal/depth encoding/scene rendering pass to ensure that foreground geometry was always seen in front of the scene's skybox - i commented out the background rendering code and i no longer seem to get the glitches! thanks for you help
Dacre

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement