DRD Team

Ugh, that looks like you are experiencing the 'striped ssao' depth sampling artifact from the early ssao test builds. I thought I had managed to fix that for good. Which screen resolution, multisample, and ssao quality settings are you using?

The FPS drops even with SSAO completely off? That must mean using a texture as a frame buffer attachment is more expensive than I expected. I'll improve the PR to only use textures when SSAO is enabled.

Screen size was 1920x1080, it happened with all 3 quality settings.

How do we proceed with this? My personal opinion is to use actual normals, even if that means some possible artifacts on models.

Sorry, I've been a little side tracked with the QZDoom thing. I'll try do the fixes for this PR soon.

About normals, the SSAO pass reconstructs them based on the depth buffer. When googling around I'm not getting clear answers if it has be an actual normal, a face normal, or any will do. I am going to try do some tests in my own engine where I already have a deferred lighting pass with actual normals.

In any case, switching to actual normals involves two things: 1) get normal data to main.fp via vertex attributes, 2) add another color buffer output with the normal data in it. The second part is easy because it already outputs the fog stuff in a color buffer, so its just more of the same there (a couple of more lines in the renderbuffers class).

dpJudas wrote: In any case, switching to actual normals involves two things: 1) get normal data to main.fp via vertex attributes, 2) add another color buffer output with the normal data in it. The second part is easy because it already outputs the fog stuff in a color buffer, so its just more of the same there (a couple of more lines in the renderbuffers class).

Yes, I am already working on it. I wanted to get some bugs and PRs out of the way first before starting. I guess the biggest showstopper here would be voxels. They will have to be handled differently if we want to go the normal route.

Excellent. I'll update the SSAO PR so that it reads the normals from a gbuffer outputted by main.fp. The pull request will still use face normals, but with a couple of lines changed in main.fp it can be switched over to the vertex attribute normals (for when your part is ready).

For voxels, I suggest just using any remotely valid normal for now. Then make the final decision for what we do depending on how that visually looks. At least for me it's a bit too abstract at this point.

For the time being I just keep treating voxels as sprites, i.e. they are uniformly lit by anything near enough. I'm going to have to keep that lighting method for sprites anyway so no big deal. It's probably best to disable SSAO for them, too, unless a better solution can be found and implemented.

I'll only pass valid normals and enable per-pixel lighting for walls, flats, wall sprites, flat sprites and models.

Maybe voxels can be drawn as the first thing in the translucent pass? SSAO doesn't affect the sprites because they are added to the scene after the SSAO pass has run.

No. Voxels are drawn in the model pass. They need proper depth buffer treatment. Right now I'm just setting their normal to (0,0,0).

They can still use and write depth data after the ssao pass, it just means they won't be present when ao is applied. Either way, setting the normals to (0,0,0) sounds good.

Obviously ultimately they should have proper normals, but for a first step I need it to get working.

So my plan is:

1. Generate normals for walls and flats. That should be sufficient to get your SSAO stuff and correct dynamic lighting to work.
2. Generate normals for models and flat and wall sprites. Generating the normals here is simple, but to use them with dynamic lights may be tricky because I need to create proper light lists to make this work. Right now I do not have a good idea how to do this efficiently. So for the first version these will also have zero normals and won't process per-pixel lighting.
3. Find a better solution for voxels.

1. will be available later today, the others may take a bit longer.

Can you point me to the code you once wrote to do proper dynamic lighting with your extrapolated normals? I can't find it right now. I guess this can speed up my progress a bit.

I parked that code on my point light branch: https://github.com/dpjudas/dpDoom/blob/ ... sl/main.fp. Note that this code assumes the dynamic light and pixelpos values are in eye space coordinates. It shouldn't be too hard to change, but just for your information.

I committed my work. For now I removed the specular code, the current shader always uses the simple attenuation with normals.
For the coordinate fudging you applied I used something else and try to keep the lights away from their floor and ceiling planes. A good universal solution does not seem possible with 10 years of possibly problematic definitions out in the wild.

Excellent! I'll try see if I can speed up the progress on my PR - seems you're ahead now.