资料备查

[S-22]

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.

Q:You say Detail has no affect on VIS then how come a map with 2,100,000

wont compile but if you go in and detail a couple of say round objects or something that has a lot of pieces to it and come out, with no other changes

and recompile the VIS may be anywhere from 100,000 to 200,000 or more lower

and now you have a map that is 2,000,000 or 1,900,000 and it will compile

A:I think we have a symantics issue here. It is not the presence of detail brushes that reduces your vis count, it's the removal of structural brushes. Detail brushes are ignored, hence they have no (adverse) affect on vis.

Actually, to be entirely correct, vis doesn't see any brushes, it sees view portals.

Q:Hey bro do you have the know on the vis_leafgroup entitie in mohaa?The m4l0 map uses em and my pal wombat said even though he doesnt understand them they greatly reduce compile time. Thing is they target each other and its wierd.

So if you know about em please blah me

Hey your the greatest may the whole world smile on you

A:Sumo, great to here from you again! Unfortunately vis/leafgroup is unique to MOH and I can't find any documentation for it. I've tried it and I also have no idea what it's doing or why. But, come back soon, anyway.

Q:Some questions...

What's the difference between vis and hint brushes?

Can I overlap playerclip brushes with regular ones? And what other utility brushes am I allowed/not-allowed to overlap?

How do I make closed doors block vis like in v2?

Would it really affect anything if I have mixed fence masks? I don't want to use extra brushes if I don't really need to.