DRD Team

Be aware that stat rendertimes is not free. The frequent CPU timer calls it needs will show in a minor performance loss on larger maps.

I didn't really think about that but it makes sense.

Graf Zahl wrote:That seems to get lost with a few people. Entryway of PrBoom+ is a good example who once bragged that REJECT brought a 3x performance boost in one of his tests (from 400 fps to 1200 fps... )

Indeed, it is a classic mistake to make. Even did it myself early on until I realized that FPS is not linear time.

This particular discussion is a very good example of why it matters though. I forgot to mention that the time used by an AO pass is constant (1.28 ms on Enjay's machine). You can't even express that in FPS as the total time depends GZDoom scene render time as well.

To really describe the cost of the SSAO pass, imagine that we set as goal that GZDoom is allowed to spend 8 ms totally on rendering the scene (120 fps with AO off). That then gives 8 ms for AO if we are going for the 16 ms deadline (60 fps). As we know each pass takes 1.28 ms, we have room for 6 AO passes. One is spent for the main scene, so that's 5 additional portals we can pick to add AO to. With this math, any 5 portal scene that drops below 120 FPS with AO off will now drop below 60 FPS with AO on. That nicely illustrates just how costly it is.

Indeed, that's a good illustration. It's a shame that it isn't easier to get a milliseconds value though without a calculation but understandable given that the numbers would change so rapidly.

I'd still suggest raising the default for gl_ssao_portals to 1 though. With the present default, any and every portal viewed will show this problem if the user has AO switched on. At least raising it to allow 1 additional portal to be shown with AO means that simple single portal constructions would work as intended. I suspect that would cover most of the uses where a simple, invisible portal is needed to make a seamless transition from one place to another (such as the one Torm posted)

Would it be possible to calculate the screen boundaries of a portal? After all the entire portal shape is available as wall polygons which are needed to draw the stencil. Of course it'd mean running the transformations in software but if you know the maximum extent of a portal you wouldn't have to process the entire screen.

I see no reason why it shouldn't be possible. In theory, it just needs to reduce the screen quad used in the pass to only be the portal extents. Maybe extended by one SSAO kernel size so that all it samples from is also copied. It should improve performance significantly.

Just an addendum, I'm sure this is not unexpected and probably known about already too but I just noticed that the same thing happens with mirrors, i.e. the reflection in a mirror has no AO but if you raise the gl_ssao_portals value it does. Presumably the view in a mirror is effectively a portal?

Indeed it is, on the renderer side it is handled by mostly the same code. Anything that combines rendering from two distinct viewpoints is implemented as a portal, even normal skies.

Are camera textures different? They don't seem to show AO (as far as I can tell - I don't have a good example with a really big, hi-def camtex set up) and gl_ssao_portals doesn't seem to make any difference there.

SSAO is part of the screen postprocessing, so it's not surprising that camera textures won't get it as they get rendered into a texture.

OK, thanks that makes sense. It's not a problem (not for me anyway) I was just interested.

I noticed that OA portal option has been added. On the one hand it works well, on the other hand it's buggy because it considers a skybox portal as first portal which it shouldn't. Skyboxes shouldn't use any occlusion at all.

Yes, that is a bug. I'm a bit busy at the moment, but I'll try take a look at when I find a little time.

No need to hurry, just take the time you need

Haha, is that your way of saying Jan 18 till Feb 28 should be enough time?