5. ViewBSP Technical Issues

In this section we are going to tackle some juicy technical BSP tree issues like how to eliminate T-junctions and proliferation of texture coordinates, as well as ViewBSP idiosyncracies and terminology like how we see the distinction between faces and polygons.

This section contains the following subsections:

5.1 T-Junctions and Trace-Vertices
5.2 Texture Coordinates and BSP trees
5.3 Faces vs. Polygons

5.1 T-Junctions and Trace-Vertices

Since the process of BSP compilation usually creates a large number of T-junctions, pixel-dropouts can often be seen when a model is rendered using a BSP tree.

Figure 1 shows three polygons (numbers 1 to 3) comprised of five vertices (A to E). Polygon 1 is defined as ABC, polygon 2 is BCE, and polygon 3 is EDC. Now, there is a T-junction created by vertex E on edge BC. If polygon 1 is indeed rendered as ABC, three edges will be traced (rasterized). But edge BC will be traced in two parts: BE, and EC. This leads to the problem of missing pixels (pixel-dropouts) between the polygons adjacent to edge BC. If, however, polygon 1 is rasterized as ABEC, which makes it essentially a quadrilateral (as far as the edge-tracer is concerned), these pixel-dropouts will not occur. We call E a trace vertex with respect to edge BC of polygon 1 (because it is only necessary for edge-tracing purposes). Note that there will be no additional vertex created, because the already existing vertex E will just be inserted into the definition of polygon 1. Also, E is no trace vertex for polygons 2 and 3, for these polygons it is just a normal vertex which is necessary in any case.
ViewBSP is able to automatically scan all edges for contained vertices that are not already part of them. These vertices are then inserted into the list of vertex-indexes for the concerned polygon to eliminate pixel-dropouts.

5.2 Texture Coordinates and BSP trees

You may have noticed that ViewBSP stores texture coordinates for each face of a model in a *.bsp file, but not for polygons. That is, even if a face consists of many polygons there are no texture coordinates for them! This is the case because ViewBSP represents the mapping of an entire plane by three point-correspondences. If point correspondences between three points on the object and their counterpart in the texture are known, texture coordinates can be calculated for every point on the plane. Actually, the three correspondences can be used to infer an affine mapping from texture-space to object-space (or vice versa). Note that this is only possible if both sets of three points each are non-collinear!
To emphasize: A *.bsp file does not contain explicit texture coordinates for all vertices of a model! Instead, the mapping is specified by three point-correspondences.

5.3 Faces vs. Polygons

There is an important difference between the terms of faces and polygons in ViewBSP: Faces always denote those primitives (polygons) that are specified in the input file. That is, faces are polygons modeled by the user. Each face has material properties, color and texture, for instance. During BSP compilation faces need to be split, yielding polygons. Thus, polygons denote those primitives (polygons) which actually comprise the output model. In the output file, the term face is mainly used to refer to material properties shared by some polygons created by splitting their original face.
Once again: Input polygons are called faces and describe both material properties and actual geometry via vertex index-lists. Output polygons are called polygons but since some of them share the same properties, each polygon belongs also to a specific face. Aside from material properties, polygons being part of the same face also share the same normal vector (they all lie in the same plane!) and texture map parameterization.