Map Wont Compile at the last part of VVIS!

My Minecraft themed map is very Brush heavy and well I tried func_detailing and every brush that the player cant see is Nodrawed. Everything is on grid and theres no overlapping of brushes that I am aware of. The Compile times have come to around 8-12 hours and I have compiled without all the outside of the map aswell and the Compile times are still overwhelming. I started to use VBCT and this is the Compile log below. Any ideas on what could be causing the problem. Thanks Guys

Computer Specs:
-Intel® Core™ i7-3770K CPU @ 3.50 GHz
-GTX 570

  • MSI Military Class Z77A-GD65
  • 16 GB of RAM

Some Info on the map:

Brushes - 7621
Faces - 45564
PointEntities - 509
SolidEntities - 1269
Unique Textures - 99

**And heres the Compile Log: **

-------------- Start Compile BSP ----------------
VBSP Started, Please Wait!

VBSP: c:\program files (x86)\steam\steamapps\common\Counter-Strike Global Offensive\bin\vbsp.exe -game “C:\Program Files (x86)\Steam\steamapps\common\Counter-Strike Global Offensive\csgo” “C:\Program Files (x86)\Steam\SteamApps\common\Counter-Strike Global Offensive\sdk_content\maps\jb_mountaincraft_v9”

Valve Software - vbsp.exe (Oct 9 2014)
8 threads

materialPath: C:\Program Files (x86)\Steam\steamapps\common\Counter-Strike Global Offensive\csgo\materials
Loading C:\Program Files (x86)\Steam\SteamApps\common\Counter-Strike Global Offensive\sdk_content\maps\jb_mountaincraft_v9.vmf
Map revision 918
fixing up env_cubemap materials on brush sides…
Material ENNERGY/MINECRAFT/WATER is depending on itself through materialvar $bottommaterial! Ignoring…
Material ENNERGY/MINECRAFT/LAVA is depending on itself through materialvar $bottommaterial! Ignoring…
Material eNnerGy/Minecraft/water is depending on itself through materialvar $bottommaterial! Ignoring…
ProcessBlock_Thread: 0…1…2…3…4…5…6…7…8…9…10 (0)
ProcessBlock_Thread: 0…1…2…3…4…5…6…7…8…9…10 (0)
Processing areas…done (0)
Building Faces…done (0)
Chop Details…done (0)
Find Visible Detail Sides…done (0)
Merging details…done (0)
done (1)
writing C:\Program Files (x86)\Steam\SteamApps\common\Counter-Strike Global Offensive\sdk_content\maps\jb_mountaincraft_v9.prt…Building visibility clusters…
done (0)
Finding displacement neighbors…
Finding lightmap sample positions…
Displacement Alpha : 0…1…2…3…4…5…6…7…8…9…10
Building Physics collision data…
done (0) (981573 bytes)
Placing detail props : 0…1…2…3…4…5…6…7…8…9…10
Water found with no water_lod_control entity, creating a default one.
Compacting texture/material tables…
Reduced 5907 texinfos to 1938
Reduced 67 texdatas to 56 (2234 bytes to 1647)
Writing C:\Program Files (x86)\Steam\SteamApps\common\Counter-Strike Global Offensive\sdk_content\maps\jb_mountaincraft_v9.bsp
2 seconds elapsed
CDynamicFunction: Loading library ‘Kernel32.dll’ (75BF0000)
CDynamicFunction: Lookup of ‘TryEnterCriticalSection’ in ‘Kernel32.dll’: 76F32360
CDynamicFunction: Closing library ‘Kernel32.dll’ (75BF0000)

Compile Complete for this module.
VBSP: Compile time: 2 seconds elapsed

-------------- Start Compile VVIS ----------------
VVIS Started, Please Wait!

VVIS: c:\program files (x86)\steam\steamapps\common\Counter-Strike Global Offensive\bin\vvis.exe -game “C:\Program Files (x86)\Steam\steamapps\common\Counter-Strike Global Offensive\csgo” “C:\Program Files (x86)\Steam\SteamApps\common\Counter-Strike Global Offensive\sdk_content\maps\jb_mountaincraft_v9”

Valve Software - vvis.exe (Oct 9 2014)
8 threads
reading c:\program files (x86)\steam\steamapps\common\counter-strike global offensive\sdk_content\maps\jb_mountaincraft_v9.bsp
reading c:\program files (x86)\steam\steamapps\common\counter-strike global offensive\sdk_content\maps\jb_mountaincraft_v9.prt
2504 portalclusters
7533 numportals
BasePortalVis: 0…1…2…3…4…5…6…7…8…9…10 (1)
PortalFlow: 0…1…2…3…4…5…6…7…8…9…

Try throwing in a few skip and hints

Try to cut down on brushes by turning certain parts into props using Propper.
I use this as well to outsmart the brush limits in the map I’m working on, and it works just fine.

One problem however, is that Propper takes some extra attention since the Steampipe update. To get around that issue, see

Another Issue is your Numportals, usually VVIS spazzs out if you exceed 4500 Numportals. Try making a smaller skybox instead of a Hollow cube to reduce Numportals.

Try using func_viscluster(s) maybe? The map seems open enough, so it might be better to throw that in rather than attempting “traditional” means of optimization that won’t do much anyway.

Thanks everyone for the tips. I was actually interested in that prop idea and the func_viscluster as well, gunna try that out and see what the result is.Thanks.

Well little update on the map, I used Propper and dropped my Brush number from 7621 to 6378. I went around the map and looked for things I was able to to func_detail and make into a Prop and was able to bring my numportals from 7533 to 6286. At First the compile was a 12+ hour compile that didn’t finish, and now its exact time for the compile is 1 hour and 2 minutes. I will take that over that long compile any day. I could try and bring it lower but Im tired of messing with this map and would like to just release it since its 99% done anyways. I would just like to thank everyone for there help and for introducing my to a new tool I havent heard of. Now I just gotta create a Radar and pack the BSP and its done. THANKS!

Did you take the advice about viscluster? I had no idea about that for a long time; it literally made my 1-hour compiles into 5 minutes. They were a life saver!

I was going to use them but I didnt trust my ability to use them right so I just skipped on them and did propper. But I think I will try that instead next time for learning purposes.