VERC: Mitered Corners: The Undying Myth Last edited 1 year ago2022-09-29 07:55:12 UTC

All too often, new mappers are told that mitering (or angling) the corners of brushes together will help to reduce r_speeds and is a general sign of good construction. In the long-term, however, it's closer to a bad habit than a beneficial one.
User posted image
User posted image
Some time ago I came across a tutorial that offered up these two images, claiming that the one on the left was a sign of poor or sloppy design and the one on the right a sign of clean, well-thought out design. This got me thinking. "Am I a poor and sloppy designer?" I of course wanted to think not, but this tutorial clearly stated I was.

I read on further. The basic argument for doing things this way was centered around two assumptions. 1) Mitering corners helps clean things up for the mapper and 2) Mitering corners helps to reduce wpoly counts on exterior corners. At this point, I noted a few misconceptions about this method.

I wrote a tutorial of sorts about this for my website about a year ago, but removed it due to what appeared to be a lack of interest. I still have seen some confusion about the benefits (if any) of mitering corners in map geometry, and feel that this is something that should be available as a public resource. Most of this article focuses on the "Mitering corners reduces w_poly counts" myth, but I'll cover a couple other issues with this method as well. Let's begin.

Myth: Mitering corners decreases w_poly

Back when I first saw the article I referred to earlier, I had been going back through the original Half-Life maps for reference for a Half-Life Deathmatch map entitled Sector A, which I released in July of 2001. While examining a ceiling area in Anomalous Materials, I noted the following:
User posted image
Note how the light appears on the concrete bar in the center of the picture. You can barely make out the gl_wireframe lines crossing the borders of the brushes. Obviously there has to be a brush in the center of the bar, as the blue light would not be possible otherwise (we'll forgive Valve for the blatant texture misalignment - this time. ;) )... yet note that the side of the bar remains a single polygon. This forms the first basis of debunking the decreased w_poly myth. Note the following two images as well, I'll be referring back to them in a second:
User posted image
User posted image
The argument for mitering corners to reduce w_poly comes from the assumption that each face as seen in the editor will correspond to a face in-game. When constructing the outside of a 90 degree angle between 2 brushes, it seems logical to assume that the face left 'hanging off' on one side will add to the polycount. This is simply not the case. The CSG process quite frankly doesn't care what faces are on what brush. It's more concerned about the texture properties themselves. The faces that lie flat against each other or the void are culled anyway, and what faces remain are combined wherever possible - assuming that these faces share the same texture, texture scale, and texture offset(s). In the 2 example images above, I created 2 solids - One consisted of a single brush, the other 1024 tiny brushes which shared the same texture properties. Rather than 1025 wpolys, the in-game result was 2 wpolys. This same result can be seen in the image from Anomalous Materials used earlier. Only in rare circumstances will texture splits fall along the "overlap" area between two non-mitered brushes, and in that case it's likely as a result of the standard 240-unit face splits seen on all textures. These splits would occur anyway, mitered or not.

Pseudo-Myth: Mitering corners keeps a map clean and neat

This is a statement that is only true part of the time. For smaller, simpler maps, this is often the case. It's easy to see where brushes split and fit with each other. However, as maps become more and more complex, this becomes less and less useful. In large and complicated maps, mitered areas won't necessarily fully line up with each other. In other areas where overlaps are present, the added angled lines may actually clutter the view moreso. This is by no means a reason to not miter your brushes, but keep this in mind as your levels become more and more complex.

Fact: Mitering corners increases plane counts

As Half-Life advances and levels created become more and more intricate, more and more original compiler limits are reached before mappers even finish their maps. One of the more deadly limits to large maps is the ever-so-feared planes limit. While tools are now being developed to optimize level plane counts, it's usually a good idea to still design with low plane counts in mind, as the plane-reducing tools may not always cut enough to be within the limit.

The problem arises from the way planes are derived. Each face in the map lies on a plane. This includes faces normally culled at compile-time by CSG. This means that the angles created at the intersections of brushes will each add their own plane. Faces across the map do share planes, but by placing faces unnecessarily at an angle, you create additional planes which are highly unlikely to line up anywhere else in the map. Note that not mitering corners will result in proper plane alignment every time. Again, this is a much more minor point, but still one that can be of concern.

So, wait... Should I never miter anything?

Of course, there are always times where this comes in handy. The most common application involves wrapping textures around angles - You simply can't get textures to line up around 90 degree corners without doing so. Using less steep angles is also critical for wrapping textures as smoothly as possible around other curved and beveled geometry.

Mitering, as with all other construction techniques, has its place and use, but it is not the godsend it is often claimed to be. The goal of this is not to say "never miter" or "always miter," but rather point out some of the pros, cons, and myths about this technique, leaving you the designer to decide how (if at all) this technique best fits you. Happy mapping.
This article was originally published on Valve Editing Resource Collective (VERC).
The archived page is available here.
TWHL only publishes archived articles from defunct websites, or with permission. For more information on TWHL's archiving efforts, please visit the TWHL Archiving Project page.

Comments

You must log in to post a comment. You can login or register a new account.