Investigating the "Wider is Better" VIS Anomaly

(April 22, 2018)


  1. Overview
  2. Establishing the test environment
  3. Preliminary testing: id's levels
  4. Further testing: custom levels
  5. Conclusion
  6. Of course, here's why it doesn't matter...

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.

Death by the Dozen

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:

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.

2fort_sk

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.

Back to top

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.

Back to top

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.

E1M1, in its original state The 'thick' E1M1, with outer brushes extruded

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:

E1M1 (thin) E1M1 (thick) E1M8 (thin) E1M8 (thick) E3M2 (thin) E3M2 (thick)
QBSP (original) 9s 9s 3s 3s 4s 4s
VIS (original) 118s 165s 66s 45s 5s 6s
LIGHT (original) 150s 68s 57s 60s 32s 34s
QBSP (ericw) 9s 8s 4s 4s 6s 6s
VIS (ericw) 79s 70s 17s 12s 5s 5s
LIGHT (ericw) 10s 9s 8s 9s 8s 7s

A few things to note about the above table:

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.

E1M1 E1M8 E3M2
"thick" build, original 3,098 1,358 1,136
"thin" build, original 2,998 1,412 1,099
"thick" build, ericw 3,336 1,406 1,378
"thin" build, ericw 3,253 1,530 1,365

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.

Back to top

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.)

Our custom level, built to tax VIS

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.

Thick Thin
QBSP (original) 3s 3s
VIS (original) 76s 100s
LIGHT (original) 3s 3s
QBSP (ericw) 4s 4s
VIS (ericw) 56s 56s
LIGHT (ericw) 7s 6s

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:

Thick Thin
original 2,543 2,609
ericw 2,779 2,860

Back to top

Conclusion

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

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.

Back to top

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.

Another shot of Death by the Dozen. Charming, isn't it?
↓ Download Wider is Better Test Maps (does not come with compilers) ↓

Back to top

< Back to index