User:Pinsplash/Reoptimizing maps

From Source Entities
Jump to navigation Jump to search

CSGO: Nuke[edit | edit source]

Nuke aggressive portals.png
Nuke bad occluder.png
No wonder they need VMPI.
Nuke fps compare 1.png
Nuke fps compare 2.png

I'm making an edit of this map, so I've been getting a good look at how this funky map tries to keep you from lagging.

Areaportals[edit | edit source]

Every opening has an areaportal on it. Every. Single. One. The map is pretty fine in this regard, but there are a few huge portals outside the play space in the Outside area which hide almost nothing at all. I had no clue what they're for and deleted them. There's a single areaportal over the windows to an inaccessible room in Tunnels. It does have a lot going on in it, so a portal on it seems warranted.

Doors throughout the map have their areaportals open all the time. They could be changed to be closed at the appropriate times, if the OnBreak output wasrealthanksvalve. (Later note: While working on this map once again, I remembered that areaportals have a keyvalue that lets them be linked to the state of a door. This also accounts for breaking, which was what I originally was worried about when I mentioned the OnBreak output. The original point stands; the areaportals on doors can be improved.)

Func_detail[edit | edit source]

Func_detailing is done well in this map. It's basically as good as you can get it.

The scaffolding on B Site was detail, but I made it world again so that player models wouldn't render through it.

Occluders[edit | edit source]

Most occluders in the map are around the main part of the building and hide things around corners and on the roof pretty well. One in CT Spawn is pretty useless because there's an areaportal right next to it doing the same job. This occluder does catch just a few things the portal doesn't, but the benefit is still marginal from any angle. One near Roof was replaced with an angled hint, and then a different occluder.

An occluder in T Spawn was replaced with a set of areaportals.

Hints I added did make the occluders less useful than before, but the delta wasn't worth the extremely bloated compile, so I ended up extending the occluders surrounding A Site to catch even more objects than they previously did. It might work even better than the hints.

Hints[edit | edit source]

Of course, what is a Valve map without 50 useless hints? ...Oh, sorry, 270. There is not a single angled hint in the entire map. There are countless hints accomplishing nothing due to the areaportals everywhere. (Remember, areaportals are like moving hints, so if you have a hint brush touching an areaportal, really consider if it's a good hint.) I know bashing Valve gets old, but damn is it easy. Valve put nodraw blocks inside Silo for obvious reasons, but it's almost as if they forgot about these, because there are occluders there as well...

I deleted all the original hints because it was simply too much to comb through. I placed 25 hints, most of them based off the "U-bend" thought process they speak of in tutorials, and accomplished what Valve did in about one thirteenth of the brushes. This resulted in VVIS finishing at least 5000% faster. I wish I was wrong.

Other[edit | edit source]

Many props render at illogical times due to poor static prop combining. I spent more than one week trying to fix this problem only. I examined the combined props in Hammer and rebuilt them using their original props. It was unfun. I mostly limited myself to rebuilding props which intersected the floor separating A site and B site, and even then I didn't rebuild every single one because the work was extremely tedious. I was going to recombine the props to reduce the draw calls, but I encountered a fair bit of difficulties and was too fed up with them to bother. All this hassle would have been avoided if Valve had compiled Nuke with -staticpropcombine_considervis, but they did not, so I'm gonna give Valve a fat F- here for combining like idiots. Combining should always consider vis. I've also noticed that VBSP puts props in very counter-intuitive groups in general. For instance, there's an airduct prop in Garage which was combined into a different group than all of the smaller props which surround and literally touch it. You can see this if you go into Secret and look up with mat_wireframe 1. This experience has left me with questions though: If the optimal combining technique is on a per-room basis, exactly how relevant are areaportals? Remember that in CSGO, players are automatically culled when they're fully behind world geometry. How do you qualify or quantify the appropriate amount of granularity? Also, what exactly is the cost of 708 new models that have to be loaded into memory?

In any case, FPS testing showed that rebuilding the props was not worth it. This was a lot of time gone down the drain. At this point, I copied most of my existing changes to the VMF over to a fresh decompile of Nuke.

The way Valve cut their walls up for adding windows and doors is terrible to work with and adds more brushes than needed. This was easy to fix. The skybox brushes were also a total mess. Some of this work was lost when I copied everything to a new VMF.

There were no func_visclusters, at least in the decompile(?) I added one above the main building's roof, which catches a good number of worthless leaves, but won't exactly save the compile time.

Like I said earlier, players in CSGO are automatically culled by world geometry they're behind, so I did put some extra nodraw blocks inside larger models and didn't give them any accompanying hints.

Result[edit | edit source]

Compiling[edit | edit source]

I compared a compile of this edit to Nuke to a compile of a fresh, unedited decompile of Nuke. My version had 1846 portalclusters and 5004 numportals, while the original decompile had 4132 portalclusters and 13805 numportals. VVIS took 52 minutes on the edited map, and on the original, it took over 48 hours, and it didn't even reach 90% before I gave up on compiling it. That's at least 55 times as fast.

VRAD took about 8 hours on the edited version, using the standard final compile settings. I didn't even bother testing it on the original decompile.

Performance[edit | edit source]

Performance was worse. When tested, FPS of the original Nuke was almost always better than the FPS of the reoptimized Nuke. In many places, the edited Nuke has objects being rendered when they absolutely shouldn't. As in, the areaportals simply aren't behaving how they should. I have two theories: decompiled areaportals still aren't as good as they're meant to be even after BSPSrc's recent 1.4 update, or hinting matters to areaportals more than is typically thought. Ascertaining that will be for another time. I'm ready to move on from this project.

So, have I made a better Nuke? Apparently not, but perhaps it's the best version of Nuke available to the community. Some time in the future I might figure out what's making the areaportals acting weird, or Valve will fix the prop combining, or Valve will love my hinting so much that they steal it without credit.

In case you're interested in seeing the changes for yourself, here's the files.

Nuke fps compare 3.png Nuke fps compare 4.png Nuke fps compare 5.png