Investigating the "Wider is Better" VIS Anomaly

(April 22, 2018)

Mappers have been chasing the shortest possible compile times since they've been mapping, but rarely has brush thickness been part of their focus. An article on the abandoned Quake Workshop 2 site claims just that: thicker brushes makes for shorter VIS times. It's known as the "Wider is Better" theory, and according to their site, it's generated more emails and debate than anything else they've posted.

Question is: could something so arbitrary really affect your compiles?

Overview

The "Wider is Better" theory originated from a man named Gene Jones, known under the name sk_imaginos in the community. His first Quake level, a deathmatch level by the name of "Death by the Dozen" and packaged in with the 1996 Aftershock for Quake add-on, was originally built in a copy of UltraEdit, a text editor.

As Imaginos' original story goes, in the process of remaking this level in Worldcraft, he hadn't realized that Worldcraft's default grid size was at 32 units, rather than 16 units. When he went to compile the level, instead of the half-hour the original took to compile, this new version had taken 22 seconds. Reportedly, after much experimentation, he was able to pin this down to the thickness of the outer walls of the level, as the insides of both levels were identical. When he shared his findings in the #quakeed IRC channel, he was derided, even by a pseudonymous John Carmack and American McGee. He ended up convincing both after getting them to compile both versions of the level for themselves.

The original story is suspect for a variety of reasons:

• Imaginos reports that the rebuilt "Death by the Dozen" was actually larger than the original "thin" build, while still taking less time to compile fully, even at -level 4 VIS and -extra light.
• By all accounts, the remade Death by the Dozen has never been published; the only build in existence is the original UltraEdit build, as linked here.
• Worldcraft's default grid size, even going as far back as Worldcraft 1.1, was 16 units, not 32 units.
• The supposed archive containing both copies of the level were not posted with the original article. Logs for this chance encounter with Carmack and McGee were also not posted, casted off as having been "a coupla years ago, now".
• John Carmack and American McGee were not known to have used fake names at any point in their correspondence with fans. Carmack does not use IRC. Even without these facts, Carmack and McGee's existence in this story to begin with comes off rather transparently as a way to build credibility, colloquially referred to as the "my uncle works at Nintendo" effect.
• A claim towards the end of the article is that the levels in Quake II took advantage of the "Wider is Better" theory and were primarily composed of 64 unit thick brushes. A simple decompile of base1.map shows this to be patently false. The thickness of walls and ceilings fluctuates between 8 and 48 units. 16 unit thick brushes are quite common.

A smaller and easier-to-miss detail are the time discrepacies when referring to sk_realistik's map, which Imaginos rebuilt with the "Wider is Better" theory in mind after the original took an inordinate amount of time to VIS completely. Independent research shows this map to have been 2fort_sk, with Imaginos listed as the co-author. Conveniently, the map source for it is also not available.

Imaginos, in his article, says the "Wider is Better" 2fort_sk took ten minutes to fully compile, while adding up the times for all three tools listed in the readme puts the time at ~25 minutes. The article says the original build took four days and counting to VIS, while the readme puts the original VIS time at 36 hours and counting. Why would Imaginos need to exaggerate the compile time?

The reaction from the Terrafusion Discord was much the same as the reaction Imaginos had reportedly gotten in the article:

[12:39 PM] lunaran: what an amazing coincidence!
[12:39 PM] lunaran: was romero there too?
[12:39 PM] lunaran: in the shadows
[12:39 PM] Mariteaux: yeah and petersen
[12:40 PM] Artistical: I think Tom Hall did it.
[12:40 PM] Artistical: id just didn't know it.
[12:40 PM] Artistical: But HE did.
[12:40 PM] lunaran: guy says that bsp, vis, and light all got faster
[12:40 PM] Artistical: Pffffff
[12:40 PM] Artistical: Why would LIGHT get faster? Makes no sense.
[12:40 PM] lunaran: and this borderline 4chan greentext is still the only place I have ever read this 'tip'
[12:41 PM] Artistical: He sounds like the kid that told you his uncle worked at Nintendo.
[12:41 PM] lunaran: other mappers on func have taught each other tons of things and this has never been among them
[12:41 PM] lunaran: ahahah yeah I knew that kid too
[12:42 PM] Artistical: "Both under assumed names".
[12:42 PM] lunaran: his uncle gave him all the games including ones that weren't out yet but you couldn't come over to play them this weekend because this weekend my dad is taking me on a trip to brazil and and and
[12:42 PM] Artistical: Hahahahaha
[12:42 PM] lunaran: now that kid is the president.
[12:42 PM] Artistical: omg, yeah.
[12:42 PM] Artistical: I surmise this as Quake community pasta. That's it.

Of course, all the lies in the world could not bring down an independently-verifiable conclusion. In the interests of overthinking an article written before some of the Quake community was even conceived, we decided to test out the "Wider is Better" theory using both existing maps and a new map, rebuilt just as Imaginos instructs in his article.

Establishing the test environment

Modern build environments are too fast for the effects of the "Wider is Better" theory to be noticeable. As a result, an artificial, slower environment, simulating a machine of the era, was needed instead. In our case, it wasn't a matter of targeting a specific clock speed, but rather slowing the compile down enough that any radical changes in compile time would be noticeable.

A Windows XP virtual machine was set up under VirtualBox with both the original id-sourced compilers and a Win32 build of ericw-tools 0.18.1, the de facto Quake compilers of the scene today. VirtualBox does not allow the clock speed of the machine to be limited arbitrarily; instead, the percentage of the targeted clock speed, ~500MHz, was calculated out from the total clock speed of the test machine, 3.2GHz, and set as the performance cap. In theory, this should limit the machine to about the desired clock speed. Nothing was running on the virtual machine aside from a stock install of the OS and the compilers.

This environment is still leagues faster than the build environments under which Imaginos built "Death by the Dozen", but again, slow enough that, if the "Wider is Better" theory were to radically affect the compile time, it would be noticeable. In the absence of an older machine, this is an acceptable substitute.

Preliminary testing: id's levels

Three levels were used in the preliminary round of testing, all sourced from John Romero's dump of the original level sources: E1M1 ("The Slipgate Complex"), E1M8 ("Ziggurat Vertigo"), and E3M2 ("The Vaults of Zin"). Two other levels were to be used in testing, E2M7 ("The Underearth") and E3M5 ("The Wind Tunnels"), but had brushwork too messy to be manipulated.

The methodology of these tests is simple. Using TrenchBroom, each level had the outer walls, ceilings, and floors extruded outward (into the void) to 32 units. The original article said the insides of the levels were unchanged. For American McGee's levels, which were often built to a grid size of 32 units, we slimmed their outer walls to 16 units. All levels were leak-free and not a single entity was changed or moved around. The two versions of each level were then compiled through the virtual machine using both sets of compilers.

After it was found that the compiler-reported times were inaccurate, often by a matter of minutes, a stopwatch was used instead. As for our results:

A few things to note about the above table:

• On the original compilers, the thick E1M1 took almost a full minute longer to VIS than the thin version, while LIGHT took a minute-and-a-half less time. Remember that the insides of the levels were unchanged and all brushes were extruded out into the void. A strange occurrence indeed, but a point against the "Wider is Better" theory.
• On the contrary, the thick E1M1 took nine seconds fewer to VIS using ericw-tools than the thin version. Thick E1M8 also showed a minor speedup using ericw's VIS. E1M8 was the only level in testing the original compilers to VIS faster in its thick version than in its thin version.
• Despite a large number of brushes changing thickness in E3M2, both versions of the level took almost the same amount of time across all tests.
• Across the board, ericw's LIGHT took a negligable amount of time in each test. ericw's LIGHT and the original implementation of LIGHT share almost nothing in common, with ericw's LIGHT using Embree to do its raytracing and ignoring the BSP tree altogether, so this makes sense.

Something suggested during testing was to check the portal file of all six maps. The amount of visportals in each map are listed in the table below.

A theory was posited that the innards of the levels were disturbed in some manner, hence the fluctuation in the number of visportals. Even still, no clear pattern emerges. The thick build of E1M1 took less time to VIS using ericw-tools despite having more portals.

Further testing: custom levels

Using the id1 maps proved inconclusive, so building a custom level served as the second test. Imaginos puts forth the following testing criteria in his article:

How can YOU find out? Make a level - Q1 - Q2 - doesn't matter - just do it.

Not some lame three-rooms-connected-with-a-corridor bullshit, but a LEVEL. Multiple stories, big, expansive halls and rooms - just do it (as Nike was fond of saying) - TWICE.

Our test level ended up being two rooms connected to one another, with a side hallway in a pseudo-deathmatch layout. Despite this, they're both multi-level and are filled with tiny little candle fixtures that gave VIS trouble even in our modern build environment. This would be ideal for our tests. (Note that we didn't say this was a good level.)

Once again, the only differences between the two levels are the thickness of the outer walls. After some initial confusion where the original tools took func_group entities as real brush entities and didn't include them in the portal file, these were our metrics.

VIS actually did take noticeably less time on the thick version than the thin version, but only using the original tools. With ericw-tools, damningly, both maps took the exact same amount of time to VIS—56 seconds.

Visportal count for both levels:

Conclusion

There are a few areas where the tests could've gone wrong:

• The simulated build environment. Imaginos was building under a Win9x architecture with a processor much slower than even our simulated environment. We unfortunately do not have real hardware with period-appropriate specs to test the theory. We've provided a link to our test maps if you do happen to have such hardware and would like to try for yourself.
• Human error. As noted, the only changes being made were changes to the outer walls. This very well could've affected the internal playing area of the level, thus invalidating the data. The chance for this, especially with the custom level, is relatively slim, however.

Using the original build of the compile tools, the "Wider is Better" theory proved true two times, false one time, and inconclusive one time. Given how shaky the data is for the id1 levels (and given their construction, many things could be affecting the numbers), we rule the "Wider is Better" theory plausible...again, if you're using the original compilers. There is no good reason to use the original compilers nowadays.

Using ericw-tools, the "Wider is Better" theory also proved true twice and proved inconclusive twice. The gains using ericw-tools were much smaller than the gains when using the original build tools, but the thicker version did prove faster to VIS half of the time. With the same considerations, we rule the "Wider is Better" theory plausible using a modern set of compilers as well.

Of course, here's why it doesn't matter...

A modern build environment is many, many times faster than the original environment under which Imaginos first built "Death by the Dozen". While large levels can still take a few minutes to build (in extreme cases, hours), good construction and good usage of func_detail will always speed up visibility calculations to a much greater degree than brush thickness.

As for why the "Wider is Better" theory works, no one can say for sure. It's only in the initial stage of QBSP that brushes have any thickness whatsoever; after this, the void faces are culled, leaving behind surfaces with no thickness at all. Theoretically, brush thickness should have no effect on VIS, and yet, sometimes it does.