VIS - Revision history

Twinchenzo at 14:09, 8 October 2012

2012-10-08T14:09:43Z

Twinchenzo at 14:09, 8 October 2012

2012-10-08T14:09:31Z

Twinchenzo at 14:09, 8 October 2012

2012-10-08T14:09:11Z

VorteX at 06:01, 3 September 2012

2012-09-03T06:01:55Z

VorteX: /* Optimizing VIS */

2012-09-03T05:27:26Z

‎Optimizing VIS

VorteX: /* Optimizing VIS */

2012-09-03T05:27:03Z

‎Optimizing VIS

VorteX at 09:37, 10 August 2012

2012-08-10T09:37:18Z

VorteX at 09:37, 10 August 2012

2012-08-10T09:37:00Z

VorteX at 15:37, 9 August 2012

2012-08-09T15:37:19Z

VorteX at 09:50, 9 August 2012

2012-08-09T09:50:42Z

@@ Line 1: / Line 1: @@
 {{need screenshot}}
 {{grammar checked|darth}}
-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 (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.
 ===Building VIS===

@@ Line 1: / Line 1: @@
 {{need screenshot}}
 {{grammar checked|darth}}
-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 (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.
 ===Building VIS===

@@ Line 1: / Line 1: @@
 {{need screenshot}}
-{{grammar}}
+{{grammar checked|darth}}
-VIS stands for visibility. Its a name of map compilation phase, and data created during this phase 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 (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.
-===Building the VIS===
+===Building VIS===
-Vis portals is created during BSP stage, links are established during VIS stage.
+VIS portals are created during BSP stage, links are established during VIS stage.
-Structural brushes will define a shape for portals to fill. It is sometimes 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]].
+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====
-VIS requires map to be internally sealed. So it can know what part of the map is inside, and what is outside. When some inner part of the map is connected with void, map is leaked. When a leak occurs, the tools cannot know which part of the level is inside, and what part is outside, and portals cannot have visibility data generated.
+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 map hull
+* 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.}}
 ===Optimizing VIS===
-It is important that portal tree should be 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 us to save some processing time, we should not allow it to take that time for its own processing). Optimizing portals is one of task map designer should care of:
+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
@@ Line 26: / Line 26: @@
 {{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 helps on complex maps. A value of 2 will force portal culling even if VIS data is presented, which improves framerate on maps witout too much complexity but hurts on complex maps.}}
+{{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.}}
 ==Tutorials==

@@ Line 21: / Line 21: @@
 * 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
 ==Tutorials==

@@ Line 18: / Line 18: @@
 ===Optimizing VIS===
-It is important that portal tree should be 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 us to save some processing time, we should not allow it to take that time for its own processing). Optimizing portals is one of task map designer should care of.
+It is important that portal tree should be 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 us to save some processing time, we should not allow it to take that time for its own processing). Optimizing portals is one of task map designer should care of:
-−
-Things map designer can do to optimize VIS portals:
 * 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

@@ Line 2: / Line 2: @@
 {{need screenshot}}
 {{grammar}}
-VIS stands for visibility. Its a name of map compilation phase, and data created during this phase and used for visibility checking. VIS are one of most notable optimisations for games, it provides opportunity to cull off any stuff that is not visible from a particular position. For large levels, this will cut off from processing more than 90% of stuff.
+VIS stands for visibility. Its a name of map compilation phase, and data created during this phase 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 can be estimated as a group of areas called portals with each portal having a link to all other postals visible from it. In real code this is of course not that simple. All map surfaces and objects will have a portal they are standing at.
 ===Building the VIS===
-VIS data being created at BSP stage, the first stage of map compilation. During this phase portals are created, but have no links (so they are dont know what portals are visible to them).
+Structural brushes will define a shape for portals to fill. It is sometimes 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]].
-−
-All gometry with solid material will define a shape for portals. Defining a shape sometimes 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 VIS creation. The only entity that breaks VIS is [[func_group]].
-−
-There is two types of VIS breaking:
-* Solid break - a wall that is blocking anything behind it
-* Portal break - a corridor corner, creating new portal
 ====Leak====
 Stub!
 ===Optimizing VIS===
-It is important that VIS portal tree should be balanced. It should be detailed enough to make accurate culling, and it should be small enough to have small RAM overhead and small processing time (VIS helps us to save some processing time, we should not allow it to take that time for its own processing). Optimizing VIS tree is one of task map designed should care of.
+Things map designer can do to optimize VIS portals:
+* Mark small brushes that should not break VIS as detail (Detail brushes are opposed to Structural)
-Things map designer do during optimization of VIS:
+* Place hint brushes that will make additional portals for more accurate culling
 * Mark brushes that should not break VIS as detail
-* Place hint brushes in order to make new joint VIS breaks for more accurate culling
-−
-Optimizing VIS is one of the tasks map designer should care about.
-−
-===Using VIS===
-VIS data is used by engine client part to control [[PVS]], which is used for rendering culling and network culling.
-−
-Engine's server part is using VIS for checking AI visibilitry and explosions;
-VIS data is also used during LIGHT stage for faster lightmap tracing.
+==Tutorials==
 ==See also==
 * [[PVS|Potentially visible set]]
 __NOTOC__
 [[Category:Glossary]]
 [[Category:Darkplaces engine]]