fps anomaly in my WIP

[geegee]

These two images should have near identical fps.  

Working with layers, I exported a layer to a new map.  The layer had only one door opening to the rest of the larger map, so the exported map only needed one blocking brush to seal leaks.  This door is directly behind the player in the pics.  th_1.jpg is from the exported map, lucy_1.jpg is taken after I remerged the maps.  The visportal works, is outlined red, and I get the identical result when I put a blocking brush over it just to check.  There's still a 16fps drop.

I've been working on optimizing the area and had increased fps from 10-15 to 45-50 in one problem area with little or no hit to the aesthetics, by turning off shadows and making a fake ambient occlusion of sorts with stretched "dirt" decals (I do all my work in DR and don't have a modeling program with the texturing tools).  That area is on the opposite side from the player (in the pic) and the fps in that area is identical in both abstract and merged maps.  As it should be!  It's only in the area of the pics where there's the discouraging fps drop problem.  And discouraging it is!  

Does anyone know what's going on here, and how I can fix it?  (pics of showtris and showshadows seem identical)

[duzenko]

Realistically we can't diagnose it by screenshot

There's a number of possible checks to do, you could start with r_showSmp and r_fboresolution, but the easy way is to upload the minimal reproducible test map for someone to investigate

[peter_spy]

First of all, these counts are super high for what's visible on screen: 3k draws, million tris, 156k shadow tris for simple geometry. Also, the number of views increases from 3 to 5, so it might mean you have a material with cubemap or a mirror? Just a guess.

[geegee]

r_showSmp = 0  in both maps

r_fboresolution = 1 in both maps

I worked on abstracting a small test map (leak...leak...leak... ahhh, finally) and it shows the no difference in fps at the place where above it's 50 vs 34, and the identical fps moving forward, but taking a few paces back to where the player is touching the door there's a 10fps difference.  If proximity is causing it, in the WIP there's a busy (but totally isolated) area to the left as the player moves forward.  

I think I'll try moving the entire layer area to a more isolate position with 2 or 3 switchback visportals to further isolate it.

Thank you muchly for all your kind replies.   

 

[geegee]

@peter_spy

No mirrors in my WIP and no cubemaps in the area.  Though I don't understand how that could impact on the issue since as I said, the areas with 34 vs 50 fps are IDENTICAL.  As I said, separated by a closed visportal (red), and the anomaly persists even when I put in a worldspawn blocking brush.  The area's where I do have cubemaps aren't problematic.  The counts may be "superhigh", but they're IDENTICAL in both pics.  The geometry is quite complex and what you see on screen isn't the whole picture. 

[duzenko]

23 minutes ago, geegee said:

r_showSmp = 0  in both maps

r_fboresolution = 1 in both maps.   

 

r_showSmp 1 - what prints?

r_fboresolution 0.5 - fps changes?

 

[geegee]

r_showSmp 1 - FFFFFFFFF...........
both maps

r_fboresolution 0.5 - 50fps ->100fps
                                - 35fps ->80fps

[duzenko]

r_showSmp FFF hints that the CPU can't handle the scene complexity

 

[peter_spy]

1 hour ago, geegee said:

The counts may be "superhigh", but they're IDENTICAL in both pics.  The geometry is quite complex and what you see on screen isn't the whole picture. 

Well, not exactly, in the second shot the number of subviews is higher, number of draws and tris is a bit lower, but the video memory is higher. That would imply that something else is being rendered too, as it uses more textures/materials. No idea why that would bring down the fps so hard. Out of curiosity, what would cause so many drawcalls and such huge triangle count in this simple looking scene? Are these pillars and grooves made with geometry?

[geegee]

@duzenko

I found the problem.  In my layer map there is no skybox.  I drop a skybox in and it has that radical effect on fps.  The sky is only seen thru' windows on the ceiling of the only area where there's a big drop in fps.  The skybox is the one with full moon overhead, stars and wispy clouds.  I'll take the sky out of the scene and do something different.

I know, the geometry is complex - not up to the standards of my personal critical critic.  But ~50 fps in a couple spots is now the lowest of the area so my optimizations have worked and the game seems to play fine.  

[peter_spy]

IIRC a skybox is always rendered, that would also explain the increased number of subviews and higher texture memory use.

[geegee]

No, a skybox isn't always rendered, which is why when I swapped portal_sky with caulk in my now problem free WIP, the fps problem vanished.  Because the area is sealed - closed by visportals - and if there are no portal_sky textures in a sealed area the caulk will display as what looks like flat black.  Put one portal_sky texture in the sealed area and the caulk will display as sky.