Firebinder's Test Chamber

1. TEXTURE SCALE ON LARGE OBJECTS

This experiment consists of simply altering the scale attribute for the textures applied to each interior surface of the test chamber, then checking the r-speeds on the resulting map.

Texture Scale Setting	FPS	WPOLY	EPOLY
1.00 (Baseline)	70+	24	0
0.50	30+	54	0
0.10	4+	864	0
2.00	70+	6	0

The results illustrate that each time a texture must replicate itself (tile) to cover a given brush surface is essentially another polygon, and it adds to the WPOLY value. The effect is geometric - halving the scale actually increases the total number of World Polys by up to a factor of 4.

What's going on here?

During the compile process all visable faces are divided into triangular polygons that make up the WPOLY number. Changing texture scale also changes the maximum polygon size, increasing WPOLY. There is much more to it than that, however, as the following several experiments will demonstrate. Conclusions are finally reached in Experiment 8 .

2. TEXTURE SCALE ON SMALL OBJECTS

For this experiment I added a small box on the floor of the room. The box was 12x12x12, and covered with the C1A0_LABFLRD texture. For this test I varied the texture scale only on the box. The texture scales on the rest of the test chamber were set to 1.00 .

Box Texture Scale Setting	FPS	WPOLY	EPOLY
1.00 (Baseline)	60+	16 to 29	0
0.10	60+	16 to 29	0

Although the texture scale was reduced to .10 it had no effect on r-speeds.

You may note that the WPOLY numbers now appear as a range. The box blocks the view of some of the polygons in the room so that they do not need to be rendered (and don't add to WPOLY). The number of polys blocked depends on where you stand in the room. Remember that for most discussions of r-speeds, it is the high number that matters.

What's going on here?

Each face of a brush must consist of at least one polygon, no matter how small that face is. If the polygon after scale reduction is still large enough to cover the brush face without tiling, it will not effect WPOLY.

3. TEXTURE ALIGNMENT

For this experiment I shifted all textures by 32 on both X and Y, deliberately misaligning all of them. Then I checked the r-speeds. The box in the previous experiment was removed.

Setting	FPS	WPOLY	EPOLY
Correctly Aligned Textures (Baseline)	70+	24	0
Misaligned Textures	70+	24	0

No effect on r-speeds at all. Apparently the only thing wrong with misaligned textures is that they look bad.

What's going on here?

During the compile the engine does not consider texture alignment in placing polygons.

4. MITERED BRUSH JOINTS

For this experiment I used the Vertex Alignment to adjust all of the joints between brushes so that they were "mitered" as shown here:

Supposedly this reduces the number of brush faces and thus improves WPOLY.

Setting	FPS	WPOLY	EPOLY
Default Brush Joints (Baseline)	70+	24	0
Mitered Brush Joints	70+	24	0

As you can see, it didn't seem to make any difference at all.

Ah - but what about corners that face the other way? For this used two brushes to form a corner that faced the oposite way, first using a butt joint (below left), then using a mitered joint (below right). Both brushes were kept 1 unit away from the other brushes in the room.

The results:

Setting	FPS	WPOLY	EPOLY
Butt joint corner	70+	22 to 28	0
Mitered joint corner	70+	22 to 28	0

Again, no effect at all. Mitered joints appear to be a lot of work for no return in terms of R-speeds.

What's going on here?

During the compile process the engine discards all unseen faces, and breaks the remaining surfaces up into polygons based entirely the visable flat planes. These polygons ignore the underlying brushwork. But there is a big "if":

IF the textures on one side of a butt joint are not fully and exactly aligned with each other, then there WILL be an extra face created

Mitered joints may also be useful for visual effects, in getting a texture to look right as it goes around a corner.

5 . BRUSH CONTACT

A suggestion for reducing r-speeds I've seen at several sites is to move any detail brushes (buttons, posters, furnishings, etc.) so that they separated from other brushes by 1 unit. Basically make them float out of direct contact with all other brushes. To test this I created a box 64x64x64, covered it with the C1A0_LABFLRD texture, and placed it on the floor of the Test Chamber. then I tested the r-speeds with the box in direct contact with the floor, and again with the box floating 1 unit above the floor.

Setting	FPS	WPOLY	EPOLY
Box Directly On Floor (Baseline)	50+	14 to 29	0
Box Floating Above Floor	50+	13 to 26	0

How about that, it works! About a 10% improvement.

What's going on here?

Each point at which a vertex touches a face will cause the brush face to be split into at least one additional polygon. If the vertex is not in direct contact, however, this does not occur. The Polygon Reduction Methods article over at Valve ERC describes this effect in more detail.

Return to Top	Site Map
Respawn Frames		Frag Frames