User:Pinsplash/Random Research

From Source Entities
Jump to navigation Jump to search

func_lod: is it worth it?[edit | edit source]

The camera never moves during or between benchmark tests to prevent the surrounding geometry from hurting perf more than it already does.

These are the results of 20-second benchmarking tests taken while looking at 982 individual func_lod 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.

  • Opaque (not faded at all): 209 FPS
  • Translucent (partially faded): 152 FPS
  • Transparent (invisible): 258 FPS

After this, the entities were all combined into one single func_lod. The FPS was 252 in all three states.

I then converted the brushes into 982 func_brushes. The FPS was 167. Reasons for this huge discrepancy are beyond me, and spending time changing the func_brushes 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, func_lod seems rather worthless, but the example scenario is extreme and not realistic. As a more realistic scenario, I chose a view of three func_lods in d1_canals_01 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 func_detail and world geometry.
  • If it's partially faded, it can be even worse than it being fully visible. Tip: How quickly the brush fades can be controlled with the lod_TransitionDist convar.
  • It isn't until the func_lod is fully hidden that performance is actually improved compared to func_detail 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[edit | edit source]

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 point_viewcontrol shifted the camera from looking at a corner, to looking at the whole map, over 100 seconds.

  • At lightmap scale 16, texture scale .25, FPS decreases sharply as the view goes from a corner to a whole cube.
  • At lightmap scale 5 (as low as VRAD would compile), texture scale .25, FPS was mostly the same in the beginning, but spent most of its time a bit lower than lightmap scale 16.
  • Lightmap scale 64, texture scale .25 is only slightly better than lightmap scale 16.
  • At lightmap scale 16, texture scale .015625, FPS decreases in a fashion more linear than logarithmic. FPS had a much less drastic range, only roughly 425-375 compared to 500-350. FPS was higher overall, probably due to mipmapping.
  • At lightmap scale 16, texture scale 4, FPS decreases in a very linear manner, and stays higher than it did in any other test, just grazing the 500 mark.
  • At lightmap scale 64, texture scale 4, FPS is able to hit 600, as it should be.
  • At lightmap scale 512, texture scale 512, FPS is practically constant through the entire map.
  • This test is again at lightmap scale 512, texture scale 512, but with nodraw cylinders on the floor to make random cuts in the geometry and increase the amount of polys that must be rendered. Doing this created lightmap discontinuities, so I assume part of this performance drop falls on luxels too.

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?[edit | edit source]

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[edit | edit source]

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[edit | edit source]

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[edit | edit source]

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. The same happened with zero areaportals. The fact that no amount of portals caused a measurable change seems to imply something about areaportals which is beyond me.

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[edit | edit source]

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.