VIS
From Blood Wiki
(Difference between revisions)
m |
Twinchenzo (Talk | contribs) |
||
| (8 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| − | |||
{{need screenshot}} | {{need screenshot}} | ||
| − | {{grammar}} | + | {{grammar checked|darth}} |
| − | VIS stands for visibility | + | VIS (stands for ''visibility'') - name of a map compilation phase during which and data is created and used for visibility checking. VIS can be estimated as a group of areas called portals with each portal having a link to all other postals visible from it. If entity standing in a portal that is visible from a portal of current eye position, it will get drawn. |
| − | VIS | + | ===Building VIS=== |
| + | VIS portals are created during BSP stage, links are established during VIS stage. | ||
| − | + | Structural brushes will define a shape for portals to fill. This process sometimes is called 'breaking VIS' because by nature it is breaking space for visible and not visible zones. All entities (including [[BModel|bmodels]]]) are meant to be changed/removed at any time, so they are always excluded from portals creation. The only entity that breaks VIS is [[func_group]]. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
====Leak==== | ====Leak==== | ||
| − | + | VIS requires the map to be internally sealed so it can distinguish what part of the map is inside and what is outside. When some inner part of the map is connected with void, the map is leaked. When a leak occurs, the tools cannot know which part of the level is inside, and which part is outside, and portals cannot have visibility data generated. | |
| − | + | Most notable mistakes leading to leak: | |
| − | + | * Small gaps between brushes leading to a void | |
| − | + | * Detail brushes and entities being used as structural walls (they are not blocking VIS) | |
| − | + | * Entities placed outside of the map hull | |
| − | {{tip| | + | When map compiler detects a leak, it will stop making portals and cast an error. Map editor will show the spot where leak was occured. |
| + | {{tip|Map compiler is using entities to determine what map part is inside. If your map have no entities, compiler will cast a leak error because it cannot decide what part of the map is inside.}} | ||
===Optimizing VIS=== | ===Optimizing VIS=== | ||
| + | It is important that portal tree is balanced. It should be detailed enough to make accurate culling, and it should be small enough to have less RAM overhead and small processing time (VIS helps to save some processing time, it should not be allowed to take that time for its own processing). Optimizing portals is one of tasks map designer should care of: | ||
| + | * Mark small brushes that should not break VIS as detail (Detail brushes are opposed to Structural) | ||
| + | * Place hint brushes that will make additional portals for more accurate culling | ||
| − | + | == Console variables == | |
| − | + | {{cvar|r_lockvisibility|disables visibility updates so you can walk around and inspect what is visible from locked position.}} | |
| − | + | {{cvar|r_drawportals|draw portal surfaces in different colors.}} | |
| − | + | {{cvar|r_novis|Disable visibility info (whole level will be drawn).}} | |
| − | + | {{cvar|r_useportalculling|Improve framerate of r_novis by using portal culling. Still not as good as precompiled visibility data, but it is helpful on complex maps. A value of 2 will force portal culling even if VIS data is presented, which improves framerate on maps without too much complexity but hurts on complex maps.}} | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | VIS data is | + | |
| − | + | ||
| − | + | ||
| − | VIS | + | ==Tutorials== |
| + | * [[Tutorials:Understanding a VIS and Hint brushes|Understanding a VIS and Hint brushes]] | ||
==See also== | ==See also== | ||
* [[PVS|Potentially visible set]] | * [[PVS|Potentially visible set]] | ||
| − | |||
__NOTOC__ | __NOTOC__ | ||
[[Category:Glossary]] | [[Category:Glossary]] | ||
[[Category:Darkplaces engine]] | [[Category:Darkplaces engine]] | ||
| + | {{finished}} | ||
Latest revision as of 17:09, 8 October 2012
This page requires a screenshot or video of the subject
Want to make one?
Want to make one?
VIS (stands for visibility) - name of a map compilation phase during which and data is created and used for visibility checking. VIS can be estimated as a group of areas called portals with each portal having a link to all other postals visible from it. If entity standing in a portal that is visible from a portal of current eye position, it will get drawn.
[edit] Building VIS
VIS portals are created during BSP stage, links are established during VIS stage.
Structural brushes will define a shape for portals to fill. This process sometimes is called 'breaking VIS' because by nature it is breaking space for visible and not visible zones. All entities (including bmodels]) are meant to be changed/removed at any time, so they are always excluded from portals creation. The only entity that breaks VIS is func_group.
[edit] Leak
VIS requires the map to be internally sealed so it can distinguish what part of the map is inside and what is outside. When some inner part of the map is connected with void, the map is leaked. When a leak occurs, the tools cannot know which part of the level is inside, and which part is outside, and portals cannot have visibility data generated. Most notable mistakes leading to leak:
- Small gaps between brushes leading to a void
- Detail brushes and entities being used as structural walls (they are not blocking VIS)
- Entities placed outside of the map hull
When map compiler detects a leak, it will stop making portals and cast an error. Map editor will show the spot where leak was occured.
Tip: Map compiler is using entities to determine what map part is inside. If your map have no entities, compiler will cast a leak error because it cannot decide what part of the map is inside.
[edit] Optimizing VIS
It is important that portal tree is balanced. It should be detailed enough to make accurate culling, and it should be small enough to have less RAM overhead and small processing time (VIS helps to save some processing time, it should not be allowed to take that time for its own processing). Optimizing portals is one of tasks map designer should care of:
- Mark small brushes that should not break VIS as detail (Detail brushes are opposed to Structural)
- Place hint brushes that will make additional portals for more accurate culling
[edit] Console variables
r_lockvisibility : disables visibility updates so you can walk around and inspect what is visible from locked position. r_drawportals : draw portal surfaces in different colors. r_novis : Disable visibility info (whole level will be drawn). r_useportalculling : Improve framerate of r_novis by using portal culling. Still not as good as precompiled visibility data, but it is helpful on complex maps. A value of 2 will force portal culling even if VIS data is presented, which improves framerate on maps without too much complexity but hurts on complex maps.
