There has been a great deal of discussion and speculation about what Vis brushes and the Vis compile process do. Much of it is erroneous. It doesn't work the same way for the MOH engine as it did in previous iterrations of the Q2 and Q3 engines. The purpose of the Vis brush is to tell the Vis process to create a view portal (a node in the Vis tree structures). You are telling the Vis process this is a logical break in the view, It will create a view portal for each Vis area. It should result in longer trees and make your compile run slower, but should improve performance, if used intelligently. Using the Vis brush presumes you have a reasonable understanding of what can and can't be seen; and that the area you choose to make a seperate Vis area really can't be seen from everywhere. From the maps people have sent me to check out, these are not concepts many of you understand. Putting a Vis brush around a building that can be seen from everywhere on the map does absolutely nothing other than create breaks in the trees where none would have existed and generate additional leaf nodes. It will frequently result in more vis data. The same applies to hint brushes. The BSP compile process creates trees. A tree is a series of flag settings that indicate what triangles can or can't be seen from various locations on the map. Only structural brushes and entities that are not affected by culling and LOD operations are included in BSP process. The leaves on the tree represent potential breaks in the view and are translated to view portals. The Vis compile takes all view portals and determines what can be seen from one view portal to all others. This process increases in time exponentially with the number of view portals your map has. For example, if you have 2 view portals, portal 1 can see portal 2 and portal 2 can see portal 1 (2 entries). If you have 4 portals, portal 1 can see 2, 3, and 4; portal 2 can see 1, 3 and 4, etc. A total of 12 potential entries. The difference in Vis levels is in the granularity, range and accuracy of the Vis data created. A fast Vis says all portals are visible from all other portals. This sounds disasterous, but given the nature of today's map designs, it may not mean much. The MOH engine (as well as some other new versions of the Q3 engine) perform a lot more real-time rendering than their predecessors and do not rely on Vis data as much. Real-time culling, maxplane and LOD functions have made Vis data less meaningful. UT doesn't use it at all. The engine decides what it will render and uses the vis data to determine how to render it. If it doesn't have complete Vis data, it extrapolates it from surrounding triangles. This is quite a departure from older games where the Vis data determined what was rendered, almost entirely. If you follow the old "Q2 corner shooter" design philosophy and limit your brush count and feature usage, you will realize some significant differences in framerate with increased vis quality. The problem is maps have gotten much bigger and more complex and the compile processes we use have not kept pace. There is still very finite limits to vis data and light patches. We are forced to use a lot more detail brushes than we would have used in the past, making areas of our map visible that may not have been. In addition, most maps contain significant outdoor areas and afford little or no blocking opportunities. Consequently, you won't realize much in the way of framerate savings over fast vis. Detail brushes prevent branches in the BSP tree structure from occuring, so consequently they have no affect on Vis. But they are not without cost. They have no blocking capabilites and still must be rendered in real-time, without the aid of precompiled data. I have one more wrinkle to throw at you. We are accustomed to the engine being able to see over, under and around everything but a blind corner. The MOH engine is a lot more sensitive and directional than what we are accustomed to, particularly up close. What would not have been a blocking brush previously, may now be.