Re: Ambient occlusion and dynlight shaders with point light math
Posted: Fri Oct 14, 2016 18:53
The more I think about the portal issues, the more I'm reaching the conclusion that my current solution is never going to work well. I probably have to change the portal rendering so that the full opaque scene is rendered first, then ssao, then translucent on top. If this can be achieved it also opens up other possibilities such as doing deferred lighting for the dynamic lights and so on.
While looking at the code related to stencils I'm noticing there are two classes doing stencil things. There's GLPortal and then there is FDrawInfo. What is the second one using it for?
I'd like to change the code so that each portal is filled with its own stencil value. From what I can tell it is already sort of doing this. What I'd like to change is that it does this the same way as the software renderer: draw opaque stuff first while marking wall and flat portal windows. By using depth tests it should be possible to mark the exact shape of the portals, giving each portal its own unique stencil reference value.
Then, in the second step it would grab the first portal, enable stencil test for the portal's reference value and draw its opaque scene. Then mark child portal walls and flats in it with its own stencil values. Continue recursively like this until the entire scene has been drawn with depth data intact and all portals visible in the stencil buffer at the same time.
At this point it will do the SSAO and put that on top of the scene.
Drawing the translucent stuff is done after this by drawing the portals back to front. This should be possible to do by filling each child portal window with the stencil value of its parent while filling in depth data to seal a child (same algorithm as it uses today for the entire scene - we just postponed the fill basically). That will allow all translucent stuff to clip correctly.
Do you see any problems with this approach?
While looking at the code related to stencils I'm noticing there are two classes doing stencil things. There's GLPortal and then there is FDrawInfo. What is the second one using it for?
I'd like to change the code so that each portal is filled with its own stencil value. From what I can tell it is already sort of doing this. What I'd like to change is that it does this the same way as the software renderer: draw opaque stuff first while marking wall and flat portal windows. By using depth tests it should be possible to mark the exact shape of the portals, giving each portal its own unique stencil reference value.
Then, in the second step it would grab the first portal, enable stencil test for the portal's reference value and draw its opaque scene. Then mark child portal walls and flats in it with its own stencil values. Continue recursively like this until the entire scene has been drawn with depth data intact and all portals visible in the stencil buffer at the same time.
At this point it will do the SSAO and put that on top of the scene.
Drawing the translucent stuff is done after this by drawing the portals back to front. This should be possible to do by filling each child portal window with the stencil value of its parent while filling in depth data to seal a child (same algorithm as it uses today for the entire scene - we just postponed the fill basically). That will allow all translucent stuff to clip correctly.
Do you see any problems with this approach?