DRD Team

Noticed a bug with line portals and ambient occlusion. The occlusion isn't visible when watching through portals, I've described the problem with screenshots here:
http://imgur.com/a/i4QLQ

Sorry - this is not really a response to the report - just asking though - I am curious, is there a particular reason for using portals in that particular space?

Probably because those two parts and the connected areas cannot coexist in the same space? The portal needs to be somewhere, even if the immediate area does not look like it needs it.

For what it's worth, the reported problem is very easy to see with the file that Kappes Buur posted. http://forum.drdteam.org/viewtopic.php?f=200&t=7469

With Ambient Occlusion on, when you look through the portal there is no ambient occlusion effect on the other side but as soon as you step through it appears.

Graf Zahl wrote:Probably because those two parts and the connected areas cannot coexist in the same space? The portal needs to be somewhere, even if the immediate area does not look like it needs it.

Exactly thats the reason

Ah. Yeah, that was exactly why I asked.

I'm afraid this is a known limitation of the way ambient occlusion is implemented.

The gl_ssao_portals cvar limits how many portals that get ssao applied to them, but that is very costly so it defaults to just 1. If you increase gl_ssao_portals it will most likely draw ssao on both sides. Note that the portal line itself will always be somewhat visible.

Right now it just picks the first portal that GZDoom decides to render, but it might be possible make the limitation less noticeable if the code is modified so that it actively picks the closest portal to the camera.

dpJudas wrote:The gl_ssao_portals cvar limits how many portals that get ssao applied to them, but that is very costly so it defaults to just 1. If you increase gl_ssao_portals it will most likely draw ssao on both sides. Note that the portal line itself will always be somewhat visible.

I tried using Kappes Buur's test map. First I typed gl_ssao_portals just to see what the value was. It was 0 (presumably that's the default for rendering just 1). I changed the value to 1 and immediately the view through the portal in the test map got ambient occlusion.

Given that the whole point of portals is to seamlessly connect two spaces, having a visual clue like this that lets the player know "something's up" strikes me as quite a problem/limitation. Would it be too expensive to have the default for gl_ssao_portals a little higher?

Just out of interest, I tested the following with vid_maxfps set to 0

Standing at the start spot in Kappes Buur's test map with no AO and gl_ssao_portals at 0 or 1:
1352 fps

Switching on AO to high with gl_ssao_portals at 0:
464 fps (bigger drop than I expected - but still way above the default maxfps of 200)

Changing gl_ssao_portals to 1:
296 fps

gl_ssao_portals 1 and AO medium:
356 fps

gl_ssao_portals 0 and AO medium:
545 fps

gl_ssao_portals 1 and AO low:
394 fps

gl_ssao_portals 0 andAO low:
587 fps

Obviously, with maxfps set to 200, I would get 200 fps at any of these settings. AO clearly has a fps hit and raising the gl_ssao_portals value increases that hit but I've been playing with AO on in a lot of complicated maps and not had any frame rate problems. But then my machine is reasonably high spec.

[edit] And just for the sake of completeness, with the test map edited to remove the portal line specials, standing at the start spot with no AO, I got 1588 fps. [/edit]

As your own measurement shows, adding SSAO to a scene is very expensive. At the 4K resolution I've been using with 4x MSAA enabled and bloom, maps like the start of BoA gets into big trouble if you allow it to add SSAO to every portal it can see. It couldn't maintain the 16 ms rendering deadline on my computer, which has a beefy 980 gtx card in it. So I opted for much more conservative defaults and added the low/medium quality versions.

By the way, one of the reasons that 3D developers always use milliseconds instead of FPS to measure things is because your numbers give a somewhat inaccurate idea of how expensive things really are. Converted to milliseconds it looks like this:

No AO: 0.74ms (1352 fps)
AO high, portals off: 2.02ms (464 fps). Cost of AO high was 1.28ms
AO high with portal: 3.37ms (296 fps). Cost 2.68ms. Twice the price of just AO high

As you can see, the FPS doesn't really reveal what the cost was. It makes it seem like the second AO with portal wasn't as bad as the first one, while the actual time spent was exactly twice.

dpJudas wrote:By the way, one of the reasons that 3D developers always use milliseconds ...

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... )

Logically that meant saving 2/3 of nothing...

What's the console command to show more than just FPS? I'm sure there is one but I can't remember or find it.

I also think that a higher standard value would be the better choice.

Enjay wrote:What's the console command to show more than just FPS? I'm sure there is one but I can't remember or find it.

It's shown right along next to the fps value. If you want detailed info about rendering, use 'stat rendertimes', but for overall ms that's not needed.

It was stat rendertimes I was thinking about.

The problem with using vid_fps for ms is that it's almost unreadable and only in whole numbers too. For example, with AO high and portals 1, the ms value is flicking between 3 and 4 (I think) faster than I can really make out.