Jump to content

  • Log In with Google      Sign In   
  • Create Account

#ActualHodgman

Posted 20 June 2013 - 12:23 AM

I believe the basic algorithm for deferred lighting is render light pass to RT -> Copy RT to existing light buffer (texture) -> Send existing light buffer to pixel shader -> render next light combining existing light to RT, repeat.  
 
Copy to texture is necessary because in XNA when you reset the render target to RT you wipe out the contents of that RT (unless you're preserving contents, which I don't want to do).

That's not at all the standard algorithm -- there shouldn't be a need for any copying of data around; it sounds much more like an XNA-specific workaround.
Why don't you want to preserve the contents of your render targets when binding them? It sounds like all your copying is just manually implementing/emulating this "preserve contents" behaviour...
 
n.b. on PC, a "preserve contents" operation will be absolutely free, because XNA is built on D3D9, and D3D9 does preserve the contents of render targets.
This behaviour of XNA only exists to make it behave like the 360, which by default doesn't preserve the contents of render-targets when binding them, and does require a copy operation.

 

I'm not experienced in XNA, but the standard algorithm simply renders each light pass to the same RT using additive blending, so that every light gets added over each other. No copying or passing previous results into each new light involved.


#1Hodgman

Posted 20 June 2013 - 12:17 AM


I believe the basic algorithm for deferred lighting is render light pass to RT -> Copy RT to existing light buffer (texture) -> Send existing light buffer to pixel shader -> render next light combining existing light to RT, repeat.  
 
Copy to texture is necessary because in XNA when you reset the render target to RT you wipe out the contents of that RT (unless you're preserving contents, which I don't want to do).
That's not at all the standard algorithm -- there shouldn't be a need for any copying of data around; it sounds much more like an XNA-specific workaround.

Why don't you want to preserve the contents of your render targets when binding them? It sounds like all your copying is just manually implementing/emulating this "preserve contents" behaviour...

 

n.b. on PC, a "preserve contents" operation will be absolutely free, because XNA is built on D3D9, and D3D9 does preserve the contents of render targets.

This behaviour of XNA only exists to make it behave like the 360, which by default doesn't preserve the contents of render-targets when binding them, and does require a copy operation.


PARTNERS