🎉 Celebrating 25 Years of GameDev.net! 🎉

Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!

Light Indexed Deferred Lighting: Artefacts during shading pass

Started by
9 comments, last by AndreyVK_D3D 2 years, 4 months ago

Hi!

I have ported Light Indexed Deferred Lighting from Original Demo: to Direct3D12 Version and OpenGL core profile version

I have bug during final shading pass for Direct3D12 version:

Direct3D12 Light Indexed Deferred Lighting bug

And OpenGL Version with some modification:

1) Scene With simple mesh

2) Simple light source animation

3) Also I tested an optional Direct3D clip control mode

OpenGL Light Indexed Deferred Lighting

I Guess may be Problem with Depth Bound Test. I need fixing for Direct3D12 only. I can provide additional information

Hov to fix it ?

3DGraphics,Direct3D12,Vulkan,OpenCL,Algorithms

Advertisement

The problem seems to happen only where many lights affect the surface? So maybe just some buffer overrun?

Hi @joej thank you for your reply.

JoeJ said:

The problem seems to happen only where many lights affect the surface? So maybe just some buffer overrun?

Yes, problems happens during affecting multiple lights to pixel

But I dont't know about buffer overrun. Lights source geometry is drawing to RGBA8 RenderTarget. What Burrer do you mean?

3DGraphics,Direct3D12,Vulkan,OpenCL,Algorithms

AndreyVK_D3D said:
What Burrer do you mean?

I just thought you would do something like making a list of lights per tile, and this could break if the list becomes too large.
I forgot how indexed deferred is meant to work. You could explain, but you would only get some other guesses in return. ; )

JoeJ said:
I just thought you would do something like making a list of lights per tile, and this could break if the list becomes too large.

Light Indexed Deferred Lighting(LIDR) doesn't use Light list per tile/cluster like as Forward+/Cluster Shading

JoeJ said:
I forgot how indexed deferred is meant to work. You could explain, but you would only get some other guesses in return. ; )

  1. Draw Scene to Depth buffer
  2. Draw light source geometry(Sphere for Point lights for example) to RGBA Render Target. Each Light source is packing as light Index using bits operation.

1) DepthTest ON/Depth Write OFF. This stage is using constant Blending (D3D12_BLEND_ONE, D3D12_BLEND_BLEND_FACTOR) with 0.25, 0.25 0.25 0.25 params https://docs.microsoft.com/en-us/windows/win32/api/d3d12/nf-d3d12-id3d12graphicscommandlisomsetblendfactor​​ So, We can mix only 4 Lights per pixel.

2) Light sources should be clipped using Stencil or Depth Bounds Test(I Use DBT)

3. Final shading pass: Extract 4 light Indices from RGBA Read Each Light source from ConstantBuffer and calculate final color.

3DGraphics,Direct3D12,Vulkan,OpenCL,Algorithms

AndreyVK_D3D said:
So, We can mix only 4 Lights per pixel.

And so you get artifacts if more lights affect it, and there is nothing you can do to fix it, i guess?
Did read a bit in this paper, which seems to confirm this limitation: https://github.com/dtrebilco/lightindexed-deferredrender/blob/master/LightIndexedDeferredLighting1.1.pdf

In the paper they propose to do a second pass if such cases happen, mentioned in the section ‘Light Index Packing - CPU sorting’. But that's heavy cost, and the same problem comes back if light count exceeds 8.

Maybe some stochastic solution could be worked out as well, so the artifacts become temporal noise and at least acceptable. Though, some Forward+ would be both easier and more robust i think.

I also saw @mjp used the technique to compare performance. Maybe he can comment when he comes by…

https://therealmjp.github.io/posts/light-indexed-deferred-rendering/

JoeJ said:
In the paper they propose to do a second pass if such cases happen, mentioned in the section ‘Light Index Packing - CPU sorting’. But that's heavy cost, and the same problem comes back if light count exceeds 8.

Ok, This is an important information.

JoeJ said:
Maybe some stochastic solution could be worked out as well, so the artifacts become temporal noise and at least acceptable. Though, some Forward+ would be both easier and more robust i think.

Yes, I want to swith to more modern Technique like as Forward+/cluster shading. But I want to know about this artefacts.

JoeJ said:
I also saw @mjp used the technique to compare performance. Maybe he can comment when he comes by…

Yes, I read this article long times ago during researching LIDR.

Thank You.

3DGraphics,Direct3D12,Vulkan,OpenCL,Algorithms

FYI what I implemented in that old blog post was what (later) became known as Forward+. At the time to me it seemed like a variant on light indexed deferred rendering since you were building lists of lights in screen space (just per-tile instead of per-pixel) and so I called it by that name. But I think I was the only one to make that connection, and soon after the Forward+ name came around and took over.

Hi, @mjp Thank you for information.

3DGraphics,Direct3D12,Vulkan,OpenCL,Algorithms

This topic is closed to new replies.

Advertisement