VVIS Taking Forever? How to Cut Your Compile Time

VVIS runs for hours when your map contains too many visleafs and portals. The most common cause is detail geometry built as world brushes. Turn everything that does not block the view over a large area into func_detail. This lowers the number of portals and usually cuts the calculation time dramatically.

What VVIS actually calculates

VBSP cuts the interior of your map into visleafs. These are convex pieces of space bounded by the faces of world brushes. Wherever two visleafs touch, a portal is created. VVIS then calculates which visleafs can see each other through these portals. The engine uses the result in game to skip rendering areas that are not visible.

The effort does not grow evenly with the size of the map. With every additional portal, the number of combinations that have to be checked grows disproportionately. That is why a single badly built hall can cost more time than everything else combined. How the three compile tools relate is explained in the article on VBSP, VVIS and VRAD.

Reading the portal count in the log

At the start, VVIS prints two numbers before the actual calculation begins. The following example shows the layout:

 842 portalclusters
2302 numportals
BasePortalVis:       0...1...2...3...4...5...6...7...8...9...10 (3)
PortalFlow:          0...1...2...3...

numportals is your most important measurement. There is no fixed threshold, because the calculation time also depends on the processor and the room layout. What matters is the comparison: note the number before a change and after it. If it drops clearly, you are on the right track.

The long phase is PortalFlow. As long as more digits appear there, VVIS is still working and has not frozen. The article on reading a compile log shows how to interpret the remaining lines.

Why too many portals are created

• Details as world brushes: Every face of a world brush can cut the space further. Pillars, stair steps, window frames, trims, railings and furniture made of brushes produce many tiny visleafs this way.
• Angled and round shapes: Cylinders, arches and rotated brushes cut the space at particularly unfavourable angles.
• Large open areas: In a wide outdoor space almost all visleafs see each other. VVIS still has to check every combination.
• Unnecessary hollow space: A giant box around the map or vast air spaces above the play area increase the volume that gets cut up.
• Too many hints: Every hint brush adds cuts and therefore portals.

Fixes in order of impact

1. Convert details. Select the brushes, press Ctrl+T and choose func_detail. The rule of thumb: only what seals the map or blocks the view over a large area stays a world brush, meaning outer walls, floors, ceilings and dividing walls between rooms.
2. Simplify the hull. Build rooms from straight, simple world brushes and put the visible shape in front as func_detail. Round walls and arches never belong in world geometry.
3. Use props and displacements. Models and displacements do not cut the space. Build terrain as a displacement with a simple brush underneath that uses tools/toolsnodraw.
4. Group open areas. With func_viscluster you mark a volume in which everything sees everything else anyway. VVIS treats the visleafs inside as mutually visible and skips checking them one by one.
5. Place hints deliberately. A hint brush uses tools/toolshint on the cutting face and tools/toolsskip on all other sides. Only place one where a specific cut really improves visibility, for example at a corridor corner.
6. Check the result. Via Map → Load Portal File, Hammer displays the portals of the last compile. In game, mat_leafvis 1 shows the visleaf you are currently standing in; the command needs sv_cheats 1.

For step 1, keep in mind that func_detail does not seal. If you convert an outer wall by accident, VBSP reports a leak. What to do then is covered in the article on fixing the map leak error.

What -fast does and when it makes sense

With the -fast parameter, VVIS skips the precise calculation and only delivers a rough result. In Hammer this matches the "Fast" setting under "Run VIS". The compile finishes quickly, but in game the engine considers far more to be visible than can actually be seen. The frame rate suffers.

A map you publish or sell needs the full calculation. If it only completes in reasonable time with -fast, that points to a structural problem and is no reason to keep the shortcut. You will find more measures for the frame rate in the article on optimizing GMod map performance.

If VVIS still takes a long time

• Compile individual sections with the cordon tool and compare numportals. That reveals the area producing the most portals.
• Load the portal file in Hammer and look for places where the lines become very dense. Forgotten detail geometry is almost always found there.
• Check whether the log also contains warnings or errors. You can paste a compile log into the Map Scanner. It detects root causes, follow-up errors and matching fixes in VBSP, VVIS and VRAD logs.

FAQ

How long should VVIS take?

There is no fixed value. A cleanly built map is usually done in minutes, and very large maps take correspondingly longer. If VVIS runs for hours, the reason is almost always the geometry and not the hardware.

Can I simply skip VVIS?

For quick tests, yes. For a release, no, because without visibility data the engine renders the entire map at all times. On larger maps the frame rate then collapses.

Do areaportals shorten VVIS time?

No. Areaportals work at runtime and hide areas in game that cannot be seen through an opening. They improve the frame rate but do not solve a compile problem.

Does func_detail make the map slower in game?

No, as long as you use it correctly. However, func_detail does not block visibility. Walls that separate two rooms therefore have to stay world brushes, otherwise the engine renders both rooms at the same time.