When I compile with VVIS set to normal it stays stuck at 9... and doesn't go to 10.

mal415

L1: Registered
May 2, 2012
4
0
Hi,

I'm having issues compiling my map, it works fine with normal, fast, normal but if I set VVIS to normal it just stays stuck on 9... and doesn't get to 10. It takes about 20 minutes to get to 9... then 20 hours later it still hasn't completed.

I've gone through my map, checked the portal file and everything "looks" fine. But I don't really know vs another map how many of those blue lines are too many. How many items am I allowed to func_detail? Could I do the whole map? What does it do really?

I have 1 pool of water which I've deleted just to see, I've also made all glass solid. It's not a massive map but I have no clue where else to look.

I've already searched for leaks. The map is sealed in a skybox so even with minor leaks they shouldn't be getting out to the void?

I've ran my compile log through the interloppers log analyser and it doesn't find any errors except for saying that vvis is running with -fast. I've done the check for problems in hammer and there's no issues.

I was wondering if someone could have a look at my compile log possibly and check out the numbers to see if anything odd sticks out. I've also converted a lot of items to func_details.

Even if a map was badly optimized how long would it take for a full compile? 21 hours too much? Especially from "9..." to 10?

I'll paste some numbers below I would really appreciate it if anyone could help. Maybe spot something abnormal which would help me figure out where to go.. If it doesn't write it out well I can send it in a PM.

2512 portalclusters 8571 numportals BasePortalVis: 0...1...2...3...4...5...6...7...8...9...10 (2) Optimized: 97072 visible clusters (0.00%) Total clusters visible: 2890908 Average clusters visible: 1150 Building PAS... Average clusters audible: 1303 visdatasize:865479 compressed from 1607680

Setting up ray-trace acceleration structure... Done (1.35 seconds) 11616 faces 1 degenerate faces 3492501 square feet [502920128.00 square inches] 0 Displacements 0 Square Feet [0.00 Square Inches] 11615 patches before subdivision 200141 patches after subdivision sun extent from map=0.000000 159 direct lights

Object names Objects/Maxobjs Memory / Maxmem Fullness ------------ --------------- --------------- -------- models 284/1024 13632/49152 (27.7%) brushes 1839/8192 22068/98304 (22.4%) brushsides 11456/65536 91648/524288 (17.5%) planes 4200/65536 84000/1310720 ( 6.4%) vertexes 16340/65536 196080/786432 (24.9%) nodes 6189/65536 198048/2097152 ( 9.4%) texinfos 2727/12288 196344/884736 (22.2%) texdata 99/2048 3168/65536 ( 4.8%) dispinfos 0/0 0/0 ( 0.0%) dispverts 0/0 0/0 ( 0.0%) disptris 0/0 0/0 ( 0.0%) disp_lmsamples 0/0 0/0 ( 0.0%) faces 11616/65536 650496/3670016 (17.7%) hdr faces 11616/65536 650496/3670016 (17.7%) origfaces 6971/65536 390376/3670016 (10.6%) leaves 6474/65536 207168/2097152 ( 9.9%) leaffaces 15030/65536 30060/131072 (22.9%) leafbrushes 4227/65536 8454/131072 ( 6.4%) areas 4/256 32/2048 ( 1.6%) surfedges 83990/512000 335960/2048000 (16.4%) edges 49292/256000 197168/1024000 (19.3%) LDR worldlights 159/8192 13992/720896 ( 1.9%) HDR worldlights 159/8192 13992/720896 ( 1.9%) leafwaterdata 7/32768 84/393216 ( 0.0%) waterstrips 1170/32768 11700/327680 ( 3.6%) waterverts 0/65536 0/786432 ( 0.0%) waterindices 21465/65536 42930/131072 (32.8%) cubemapsamples 0/1024 0/16384 ( 0.0%) overlays 38/512 13376/180224 ( 7.4%) LDR lightdata [variable] 8504816/0 ( 0.0%) HDR lightdata [variable] 8504816/0 ( 0.0%) visdata [variable] 865479/16777216 ( 5.2%) entdata [variable] 252742/393216 (64.3%) LDR ambient table 6474/65536 25896/262144 ( 9.9%) HDR ambient table 6474/65536 25896/262144 ( 9.9%) LDR leaf ambient 29416/65536 823648/1835008 (44.9%) HDR leaf ambient 29403/65536 823284/1835008 (44.9%) occluders 0/0 0/0 ( 0.0%) occluder polygons 0/0 0/0 ( 0.0%) occluder vert ind 0/0 0/0 ( 0.0%) detail props [variable] 1/12 ( 8.3%) static props [variable] 1/28680 ( 0.0%) pakfile [variable] 213618/0 ( 0.0%) physics [variable] 736899/4194304 (17.6%) physics terrain [variable] 2/1048576 ( 0.0%)

Level flags = 0

Total triangle count: 32899

Object names Objects/Maxobjs Memory / Maxmem Fullness ------------ --------------- --------------- -------- models 284/1024 13632/49152 (27.7%) brushes 1839/8192 22068/98304 (22.4%) brushsides 11456/65536 91648/524288 (17.5%) planes 4200/65536 84000/1310720 ( 6.4%) vertexes 16340/65536 196080/786432 (24.9%) nodes 6189/65536 198048/2097152 ( 9.4%) texinfos 2727/12288 196344/884736 (22.2%) texdata 99/2048 3168/65536 ( 4.8%) dispinfos 0/0 0/0 ( 0.0%) dispverts 0/0 0/0 ( 0.0%) disptris 0/0 0/0 ( 0.0%) disp_lmsamples 0/0 0/0 ( 0.0%) faces 11616/65536 650496/3670016 (17.7%) hdr faces 11616/65536 650496/3670016 (17.7%) origfaces 6971/65536 390376/3670016 (10.6%) leaves 6474/65536 207168/2097152 ( 9.9%) leaffaces 15030/65536 30060/131072 (22.9%) leafbrushes 4227/65536 8454/131072 ( 6.4%) areas 4/256 32/2048 ( 1.6%) surfedges 83990/512000 335960/2048000 (16.4%) edges 49292/256000 197168/1024000 (19.3%) LDR worldlights 159/8192 13992/720896 ( 1.9%) HDR worldlights 159/8192 13992/720896 ( 1.9%) leafwaterdata 7/32768 84/393216 ( 0.0%) waterstrips 1170/32768 11700/327680 ( 3.6%) waterverts 0/65536 0/786432 ( 0.0%) waterindices 21465/65536 42930/131072 (32.8%) cubemapsamples 0/1024 0/16384 ( 0.0%) overlays 38/512 13376/180224 ( 7.4%) LDR lightdata [variable] 8504816/0 ( 0.0%) HDR lightdata [variable] 8504816/0 ( 0.0%) visdata [variable] 865479/16777216 ( 5.2%) entdata [variable] 252742/393216 (64.3%) LDR ambient table 6474/65536 25896/262144 ( 9.9%) HDR ambient table 6474/65536 25896/262144 ( 9.9%) LDR leaf ambient 29416/65536 823648/1835008 (44.9%) HDR leaf ambient 29403/65536 823284/1835008 (44.9%) occluders 0/0 0/0 ( 0.0%) occluder polygons 0/0 0/0 ( 0.0%) occluder vert ind 0/0 0/0 ( 0.0%) detail props [variable] 1/12 ( 8.3%) static props [variable] 1/28680 ( 0.0%) pakfile [variable] 213618/0 ( 0.0%) physics [variable] 736899/4194304 (17.6%) physics terrain [variable] 2/1048576 ( 0.0%)

Level flags = 0

Total triangle count: 32899
 

Freyja

aa
Jul 31, 2009
2,994
5,813
Func_detailing is a hard concept to explain, but I'll try my best.

When you compile your map, the first process, VBSP, cuts your map up into lots of "volumes," or visleaves. It does this by assuming a wall is a border between volumes, and when you load a portal file, each of those blue lines shows a border between these volumes.

VVIS then takes an imaginary player, places them at every point in the map and figures out which, and how many of these volumes they can see standing from that place, and therefore the ones that can't be seen do not have to be rendered, saving processing in the game. The more volumes you have, the longer this process takes. This is the 'portalflow' in your compile.

The problem is, VBSP doesn't know how to split the map very well when it comes down to very small brushes, or brushes on funny angles. A 12 sided cylinder can generate upwards of 50 extra visleaves.

If you make something func_detail, VBSP does not see that when making your map full of volumes. The object just doesn't exist when it comes to this process, it is, for all intents and purposes, invisible. If you func_detailed the aforementioned cylinder, then the large number of visleaves would not be created, and thus when VVIS comes to calculation, it wont have to deal with them, speeding up your compile in general.

However, that means that once in game, because VVIS has told the engine so, if you look at that cylinder, as it was "invisible" in compile, the game will render everything behind it. This is why you do not want to func_detail your entire map. If you do, the game will run extremely choppy due to you being able to "see" the whole map at the same time.

Thus, func_detailing is a fine line between compile time and optimization. As a general rule, anything that is rectangular, and would obscure your whole view from a reasonable distance away (eg, a wall, a building) should be left as world geometry. If it's small, has odd angles or does not hide anything behind it (eg, buildings in the out of play area) then go ahead and func_detail it. Stairs, for example, are small and don't hide much, and should ALWAYS be func_detialed. A map full of stairs can stretch your compile by a few hours, easily.

It's a complex thing to grasp, and unfortunately necessary (Unless your willing to wait days). there's plenty of documentation online though.
 
Last edited:

xzzy

aa
Jan 30, 2010
815
531
The quick way to start to understand how vis compile works is build your map, load hammer, then in the Map menu, click load portal file. This should clutter up the 3D views with zillions of blue lines.

General idea is that blue lines == bad. This isn't entirely true, you need SOME blue lines for the map to run at decent framerates, but you want to avoid areas with a high density of blue lines.
 

MangyCarface

Mapper
aa
Feb 26, 2008
1,626
1,325
The quick way to start to understand how vis compile works is build your map, load hammer, then in the Map menu, click load portal file. This should clutter up the 3D views with zillions of blue lines.

General idea is that blue lines == bad. This isn't entirely true, you need SOME blue lines for the map to run at decent framerates, but you want to avoid areas with a high density of blue lines.

He mentioned having looked at the portal file
 

mal415

L1: Registered
May 2, 2012
4
0
Thanks for your suggestions and tips. From playing around with the map some more tonight I re-created the 3d skybox from scratch and forgot to delete the sky camera at 0 0 0. So I essentially had 2. Did my compile using normal and to my suprise portalflow went by super quick (1min 18 seconds).

So thinking to myself it was the skybox causing problems I deleted the second skycamera at 0 0 0 and tried to recompile again but it's back to it's normal slow speed.. I re-added the skycamera at 0 0 0 and it went back to fully compiling without any issues except that I have 2 cameras so it throws the skybox into the sky instead of being somewhat leveled with the map.

I also tried deleting both cameras and the skybox outside of the map and same issue occurs, it's just back to painfully slow..

Any ideas?
 
Oct 6, 2008
1,947
445
9..10 = could take an hour in hammer

I can't find the link inTf2maps but there's a link to a compile program that works really well outside of hammer and seems to be fairly quick - it also allows you to keep using your machine without the total lock up that hammer has. Use that program.
 

YM

LVL100 YM
aa
Dec 5, 2007
7,135
6,056
Turn off these visgroups and then post some screenshots from around the map:
Water
Displacements
Tool brushes
Entities
World Details
Custom

EDIT: KTB vvis should never take an hour regardless of what your method of compile is. If 9...10 on vvis takes that long you have serious problems or you seriously need to upgrade your 1990s PC.
 

Sergis

L666: ])oo]v[
aa
Jul 22, 2009
1,874
1,257
Thanks for your suggestions and tips. From playing around with the map some more tonight I re-created the 3d skybox from scratch and forgot to delete the sky camera at 0 0 0. So I essentially had 2. Did my compile using normal and to my suprise portalflow went by super quick (1min 18 seconds).

So thinking to myself it was the skybox causing problems I deleted the second skycamera at 0 0 0 and tried to recompile again but it's back to it's normal slow speed.. I re-added the skycamera at 0 0 0 and it went back to fully compiling without any issues except that I have 2 cameras so it throws the skybox into the sky instead of being somewhat leveled with the map.

I also tried deleting both cameras and the skybox outside of the map and same issue occurs, it's just back to painfully slow..

Any ideas?

since the 3dsky is visible at all times or not visible at all, my guess is that areas with 3dskycam dont really care about optimizing vis. its just a guess tho
 
Last edited: