BuildVisLeafs: 0

Hello, this is my first post in the mapping section.

I have made plenty of maps in the past and am well versed with Hammer Editor but I have never encountered this issue before… :confused:

This is the first time I’ve tried to make a map as large as the source engine can handle.
Length & Width i’ve moved the boundaries all the way to the grid and moved it in 128 units, I’m not getting the error that tells you you’ve got a brush outside the maximum size of the source engine so that’s not the problem.

Time to compile. Compile time is extremely fast ~5min for a map this large


BuildFacelights:     0...1...2...3...4...5...6...7...8...9...10 (86)
BuildVisLeafs:       0


VisLeafs hit 0 and the compiler stops :frowning:
I am able to load into the map but obviously it has not fully compiled as there is no lighting or visleafs.

First I thought I didn’t have enough ram to compile a map this large so I had a friend with 12gb try and they ran into the same problem…

Any suggestions???

Full Compile Log:



** Executing...
** Command: "C:\Program Files (x86)\Steam\steamapps\common\Counter-Strike Source\bin\vbsp.exe"
** Parameters: -game "C:\Program Files (x86)\Steam\steamapps\common\Counter-Strike Source\cstrike" "C:\Users\kklouzal\Downloads\dx_rp_occupation_3.vmf"

Valve Software - vbsp.exe (Jun 18 2013)
4 threads
materialPath: C:\Program Files (x86)\Steam\steamapps\common\Counter-Strike Source\cstrike\materials
Loading C:\Users\kklouzal\Downloads\dx_rp_occupation_3.vmf
ConVarRef mat_reduceparticles doesn't point to an existing ConVar
Could not locate 'GameData' key in c:\program files (x86)\steam\steamapps\common\counter-strike source\cstrike\gameinfo.txt
Patching WVT material: maps/dx_rp_occupation_3/dev/dev_blendmeasure_wvt_patch
Patching WVT material: maps/dx_rp_occupation_3/nature/blenddirtmud003a_wvt_patch
fixing up env_cubemap materials on brush sides...
Material glass/glasswindowbreak070b is depending on itself through materialvar $crackmaterial! Ignoring...
Material glass/glasswindowbreak070b is depending on itself through materialvar $crackmaterial! Ignoring...
Material glass/glasswindowbreak070b is depending on itself through materialvar $crackmaterial! Ignoring...
Material glass/glasswindowbreak070b is depending on itself through materialvar $crackmaterial! Ignoring...
ProcessBlock_Thread: 0...1...2...3...4...5...6...7...8...9...10 (1)
ProcessBlock_Thread: 0...1...2...3...4...5...6...7...8...9...10 (1)
Processing areas...done (0)
Building Faces...done (1)
Chop Details...done (0)
Find Visible Detail Sides...
Merged 454 detail faces...done (0)
Merging details...done (0)
FixTjuncs...
PruneNodes...
WriteBSP...
done (3)
writing C:\Users\kklouzal\Downloads\dx_rp_occupation_3.prt...Building visibility clusters...
done (1)
Creating default LDR cubemaps for env_cubemap using skybox materials:
   skybox/sky_day01_08*.vmt
 ! Run buildcubemaps in the engine to get the correct cube maps.
Creating default HDR cubemaps for env_cubemap using skybox materials:
   skybox/sky_day01_08*.vmt
 ! Run buildcubemaps in the engine to get the correct cube maps.
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 (1) (1893267 bytes)
Placing detail props : 0...1...2...3...4...5...6...7...8...9...10
Compacting texture/material tables...
Reduced 4931 texinfos to 3109
Reduced 226 texdatas to 176 (9766 bytes to 8026)
Writing C:\Users\kklouzal\Downloads\dx_rp_occupation_3.bsp
16 seconds elapsed

** Executing...
** Command: "C:\Program Files (x86)\Steam\steamapps\common\Counter-Strike Source\bin\vvis.exe"
** Parameters: -game "C:\Program Files (x86)\Steam\steamapps\common\Counter-Strike Source\cstrike" -fast "C:\Users\kklouzal\Downloads\dx_rp_occupation_3"

Valve Software - vvis.exe (Jun 18 2013)
fastvis = true
4 threads
reading c:\users\kklouzal\downloads\dx_rp_occupation_3.bsp
reading c:\users\kklouzal\downloads\dx_rp_occupation_3.prt
7362 portalclusters
21674 numportals
BasePortalVis:       0...1...2...3...4...5...6...7...8...9...10 (53)
Optimized: 913118 visible clusters (2.06%)
Total clusters visible: 44389648
Average clusters visible: 6029
Building PAS...
Average clusters audible: 7347
visdatasize:12852563  compressed from 13663872
writing c:\users\kklouzal\downloads\dx_rp_occupation_3.bsp
1 minute, 15 seconds elapsed

** Executing...
** Command: "C:\Program Files (x86)\Steam\steamapps\common\Counter-Strike Source\bin\vrad.exe"
** Parameters:  -game "C:\Program Files (x86)\Steam\steamapps\common\Counter-Strike Source\cstrike" -noextra "C:\Users\kklouzal\Downloads\dx_rp_occupation_3"

Valve Software - vrad.exe SSE (Jun 18 2013)

      Valve Radiosity Simulator     
4 threads
[Reading texlights from 'lights.rad']
[2 texlights parsed from 'lights.rad']

Loading c:\users\kklouzal\downloads\dx_rp_occupation_3.bsp
Setting up ray-trace acceleration structure... Done (3.55 seconds)
38860 faces
4 degenerate faces
42741408 square feet [6154762752.00 square inches]
4 Displacements
20280 Square Feet [2920448.00 Square Inches]
38856 patches before subdivision
978786 patches after subdivision
74 direct lights
BuildFacelights:     0...1...2...3...4...5...6...7...8...9...10 (166)
BuildVisLeafs:       0
** Executing...
** Command: Copy File
** Parameters: "C:\Users\kklouzal\Downloads\dx_rp_occupation_3.bsp" "C:\Program Files (x86)\Steam\steamapps\common\Counter-Strike Source\cstrike\maps\dx_rp_occupation_3.bsp"



From my experience sometimes when buildvisleafs is stuck when Vrad is compiling, it’s usually due to unoptimized lightmaps. From your post, it sounds like you have a large map. So try raising the lightmap scale on faces where players won’t see them or hardly notice them.

How much? The default is 16, There really isn’t too much to the map currently, 1 spawn building and a huge open area to fly aircraft and drive tanks.

Holy fucking shit.

Take this, its dangerous to go alone.

I already use pretty much all of those performance techniques, I am well versed with Hammer I’ve just never tried to compile a map of this magnitude although I know it is possible.

I’m just going to try to cut the lightmap scale in half and see what that gets me… I can upload the .vmf file if someone wants to take a look/compile it themselves. The map is nothing special, a couple prefabs which I edited for optimization a good sized water area for NeuroNaval lots of open space for NeuroTanks and a large ceiling for WAC.

I suppose if this doesn’t work i’ll make a new map and just create the boundaries as large as they are now and see if it compiles then start making it smaller and smaller which I really don’t want to do.

There is a reason why you have been compiling on fast and there is a reason why your map will not compile. If you tried to run VVIS at normal, it would take days to compile. There is absolutely no reason why your numbers in VVIS should be xbox huge.

You state that there isn’t much on the map, but I somehow doubt that on the basis of vvis alone.

VRAD wont finish because once it gets to the front of the compile line it sees what VVIS was up against and just goes ‘nope.’

VRAD.gif

https://dl.dropboxusercontent.com/u/7633313/1340686723402.gif

Please do put up the VMF or at least show us some in hammer pictures. There is no way you made a map that ‘doesn’t have much on it’ with numbers like that in VVIS, unless you’re doing something horrendously wrong. Just because you can complete a compile on fast vis doesn’t mean its a good idea.