User:Pinsplash/Random Research

func_lod: is it worth it?
These are the results of 20-second benchmarking tests taken while looking at 982 individual entities, which is close to the effective brush entity limit of approximately 1024. The state of the brushes (opaque/translucent/transparent) was controlled by changing the fade distance itself, as it was found that moving the camera caused more of the surrounding environment to render which had a very large performance impact. The game being used is Half-Life 2. After this, the entities were all combined into one single. The FPS was 252 in all three states.
 * Opaque (not faded at all): 209 FPS
 * Translucent (partially faded): 152 FPS
 * Transparent (invisible): 258 FPS

I then converted the brushes into 982 es. The FPS was 167. Reasons for this huge discrepancy are beyond me, and spending time changing the es in any way to "optimize" them is out of my scope for now. I did try a few other brush entities:
 * func_lod: 209 FPS (fully opaque)
 * func_brush: 167 FPS
 * func_illusionary: 149 FPS
 * func_tank: 148 FPS
 * func_detail: 254 FPS (same result for world brush)

At this point,  seems rather worthless, but the example scenario is extreme and not realistic. As a more realistic scenario, I chose a view of three s in  which are used for hiding some roof geometry and a staircase.
 * Opaque (not faded at all): 111 FPS
 * Translucent (partially faded): 111 FPS
 * Transparent (invisible): 113 FPS

Conclusion: No.
 * It does render (and... process?) faster than other brush entities, somehow, when it's not faded at all, but still slower than and world geometry.
 * If it's partially faded, it can be even worse than it being fully visible.
 * It isn't until the  is fully hidden that performance is actually improved compared to  or world geometry, though that benefit is minimal.
 * Tech was probably different back in the day in ways which made func_lod a useful tool, but now it's irrelevant.

Margin of error: For a static image, 20 seconds is plenty of time. ±1 FPS.

Texel and luxel performance
After finishing my func_lod tests, I had one more question: How could a simple cube-shaped test map see FPS range so much? I stripped it of everything. 6 sides, 2048 units high and across, lightmap scale 16, texture scale .25 (the texture being used is dev/dev_blendmeasure2) gave me 200 FPS looking at as most of it as I could at once, and 580 FPS staring down at a corner.

The images below show how FPS changed as a shifted the camera from looking at a corner, to looking at the whole map, over 100 seconds.

It's what you would expect: less luxels and texels means higher FPS, but the benefit is minimal most of the time unless you're texturing like it's 1999, blah blah blah.

Areaportals: how much is too much?
It's a known fact that, like occluders, areaportals have a threshold where using them actually hurts performance rather than help it... but what is that point? I've thought of four different ways areaportals might reach that point: too many on the screen at once, being on the screen but not hiding many objects, too many areaportals appearing to overlap, and the vis areas created by portals being too complex.

Too many on screen
Areaportals have a non-zero cost. Eventually the cost of tracing has to add up on its own. I tried making a set of 32 completely useless areaportals in my empty test map, and Half-Life 2 went from 495 FPS to 423, down 72. Another 32 portals brought it down to 408. Then I gave them one object to trace against: 405 FPS

Not hiding enough things
Okay... what if we give them a lot of things to trace against, which they can't unrender? I then gave the 64 portals 60 things to trace on, almost 4000 traces per frame. This gave me 330 FPS. A compile of the map with all the props but none of the areaportals yielded 396 FPS. That's 66 frames lost on processing areaportals. This scenario is unrealistic though, as having 64 areaportals onscreen at once is ridiculous. So I made it only one portal against 61 objects, and the FPS was back to the 420 area (haha). I then did one more compile where the single areaportal easily hid all the objects (in previous tests, they were all visible the entire time). This gave me 548 FPS, which is actually higher than the initial benchmark because the portal also happened to derender some of the environment. Welp, off to eliminate that for future tests.

Too much overlap
I've been told in the past that overlapping areaportals can cause noticeable lag, with reportedly as little as four portals. I tried up to 32 overlapping areaportals and the results were a consistent 660 FPS without props and 515 with props. This includes tests with zero areaportals. The fact that no amount of portals caused a measurable change seems to imply something about areaportals which is beyond me. However, see below...

It should be noted that the reason for such a big discrepancy compared to earlier tests is because in sections 1 and 2 the testing space had regular textures inside it with lighting on them and were additionally cut up by geometry which was being used to support the first 64 areaportals, and in this section I changed the area to be completely void of anything at all with nodraw textures on everything.

Area is too complex
A hypothetical, more obscure cause of areaportal lag would be an area having too many portals containing it for it to be a viable option. I felt like such a thing might explain why the TF2 map Nucleus lacks areaportals in places it could possibly use them well. So I made a room with 12 portals on one end, and a single one on the other and recorded FPS while only looking out through the single portal. FPS did not change depending on how many portals there were on the other side of the room. Also while making this room I apparently accidentally made a rare case where having multiple sides of an areaportal brush exposed is magically okay to do. Cool.

So yeah, areaportals do have limits, but I can't think of any real map that comes close to them, so it seems pretty unrealistic to say you should worry about it.