Waiting 10 minutes for a 3MB map to compile... Normal?

[HellJumper]

Hey all,

After making an utterly fail map as my first map, I set off to work on my second map. Obviously, the first map is always the box-crappy map anyone makes right off the bat (cause really... we find a map maker and we are like "Cool! I can make maps!" and then we make a box map).

But anyway,
I was just wondering if compiling a map about 3MB (the BSP file) should take about 10 minutes to compile. The map runs perfectly fine, so I don't think there are any errors, but it always takes a long time on the red part below. If anyone can tell me if there is something I'm doing wrong, or something that is inefficient, that would be amazingly helpful.

Thanks!

This is the compile window:

** Executing...
** Command: "c:program filessteamsteamappshelljumper777sourcesdkbinorangeboxbinvbsp.exe"
** Parameters: -game "c:program filessteamsteamappshelljumper777team fortress 2tf" "C:Program FilesSteamsteamappshelljumper777sourcesdk_contenttfmapsrcctf_FacilityMakesure"

Valve Software - vbsp.exe (May 19 2009)
2 threads
materialPath: c:program filessteamsteamappshelljumper777team fortress 2tfmaterials
Loading C:Program FilesSteamsteamappshelljumper777sourcesdk_contenttfmapsrcctf_FacilityMakesure.vmf
fixing up env_cubemap materials on brush sides...
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 (1)

FindPortalSide: Couldn't find a good match for which brush to assign to a portal near (832.0 266.0 38.1)
Leaf 0 contents: 
Leaf 1 contents: CONTENTS_GRATE CONTENTS_TRANSLUCENT 
viscontents (node 0 contents ^ node 1 contents): CONTENTS_GRATE 
This means that none of the brushes in leaf 0 or 1 that touches the portal has CONTENTS_GRATE 
Check for a huge brush enclosing the coordinates above that has contents CONTENTS_GRATE 
Candidate brush IDs: Brush 13247: 


FindPortalSide: Couldn't find a good match for which brush to assign to a portal near (73.0 149.0 32.5)
Leaf 0 contents: CONTENTS_GRATE CONTENTS_TRANSLUCENT 
Leaf 1 contents: 
viscontents (node 0 contents ^ node 1 contents): CONTENTS_GRATE 
This means that none of the brushes in leaf 0 or 1 that touches the portal has CONTENTS_GRATE 
Check for a huge brush enclosing the coordinates above that has contents CONTENTS_GRATE 
Candidate brush IDs: Brush 13247: 


FindPortalSide: Couldn't find a good match for which brush to assign to a portal near (73.0 250.0 37.5)
Leaf 0 contents: CONTENTS_GRATE CONTENTS_TRANSLUCENT 
Leaf 1 contents: 
viscontents (node 0 contents ^ node 1 contents): CONTENTS_GRATE 
This means that none of the brushes in leaf 0 or 1 that touches the portal has CONTENTS_GRATE 
Check for a huge brush enclosing the coordinates above that has contents CONTENTS_GRATE 
Candidate brush IDs: Brush 13247: 


FindPortalSide: Couldn't find a good match for which brush to assign to a portal near (73.0 358.0 32.5)
Leaf 0 contents: CONTENTS_GRATE CONTENTS_TRANSLUCENT 
Leaf 1 contents: 
viscontents (node 0 contents ^ node 1 contents): CONTENTS_GRATE 
This means that none of the brushes in leaf 0 or 1 that touches the portal has CONTENTS_GRATE 
Check for a huge brush enclosing the coordinates above that has contents CONTENTS_GRATE 
Candidate brush IDs: Brush 13247: 


FindPortalSide: Couldn't find a good match for which brush to assign to a portal near (73.0 386.0 37.5)
Leaf 0 contents: CONTENTS_GRATE CONTENTS_TRANSLUCENT 
Leaf 1 contents: 
viscontents (node 0 contents ^ node 1 contents): CONTENTS_GRATE 
This means that none of the brushes in leaf 0 or 1 that touches the portal has CONTENTS_GRATE 
Check for a huge brush enclosing the coordinates above that has contents CONTENTS_GRATE 
Candidate brush IDs: Brush 13247: 

Processing areas...done (0)
Building Faces...done (0)
FixTjuncs...
PruneNodes...
WriteBSP...
done (0)
writing C:Program FilesSteamsteamappshelljumper777sourcesdk_contenttfmapsrcctf_FacilityMakesure.prt...Building visibility clusters...
done (0)
Creating default LDR cubemaps for env_cubemap using skybox materials:
   skybox/sky_day01_01*.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_01*.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) (131465 bytes)
Error! prop_static using model "models/props_interiors/vendingmachinesoda01a.mdl", which must be used on a dynamic entity (i.e. prop_physics). Deleted.
Error loading studio model "models/props_interiors/vendingmachinesoda01a.mdl"!
Placing detail props : 0...1...2...3...4...5...6...7...8...9...10
Compacting texture/material tables...
Reduced 1384 texinfos to 705
Reduced 24 texdatas to 20 (682 bytes to 597)
Writing C:Program FilesSteamsteamappshelljumper777sourcesdk_contenttfmapsrcctf_FacilityMakesure.bsp
5 seconds elapsed
  4.125119 -22.390100 0.000000
  4.125119 -17.237074 0.000000
  4.987925 -15.519400 0.000000
  4.125119 -15.519400 0.000000
make_triangles:calc_triangle_representation: Cannot convert
  4.125119 -22.390100 0.000000
  4.125119 -17.237074 0.000000
  4.987925 -15.519400 0.000000
  4.125119 -15.519400 0.000000
make_triangles:calc_triangle_representation: Cannot convert
  4.125119 -15.532100 0.000000
  4.125119 -10.379075 0.000000
  4.987925 -8.661400 0.000000
  4.125119 -8.661400 0.000000
make_triangles:calc_triangle_representation: Cannot convert
  4.125119 -15.532100 0.000000
  4.125119 -10.379075 0.000000
  4.987925 -8.661400 0.000000
  4.125119 -8.661400 0.000000
make_triangles:calc_triangle_representation: Cannot convert

** Executing...
** Command: "c:program filessteamsteamappshelljumper777sourcesdkbinorangeboxbinvvis.exe"
** Parameters: -game "c:program filessteamsteamappshelljumper777team fortress 2tf" "C:Program FilesSteamsteamappshelljumper777sourcesdk_contenttfmapsrcctf_FacilityMakesure"

Valve Software - vvis.exe (May 19 2009)
2 threads
reading c:program filessteamsteamappshelljumper777sourcesdk_contenttfmapsrcctf_FacilityMakesure.bsp
reading c:program filessteamsteamappshelljumper777sourcesdk_contenttfmapsrcctf_FacilityMakesure.prt
 833 portalclusters
2628 numportals
BasePortalVis:       0...1...2...3...4...5...6...7...8...9...10 (1)
[COLOR="Red"]PortalFlow:          0...1...2...3...4...5...6...7...8...9...10 (1618)[/COLOR]
Optimized: 2236 visible clusters (0.00%)
Total clusters visible: 233889
Average clusters visible: 280
Building PAS...
Average clusters audible: 673
visdatasize:159415  compressed from 186592
writing c:program filessteamsteamappshelljumper777sourcesdk_contenttfmapsrcctf_FacilityMakesure.bsp
26 minutes, 59 seconds elapsed

** Executing...
** Command: "c:program filessteamsteamappshelljumper777sourcesdkbinorangeboxbinvrad.exe"
** Parameters:  -game "c:program filessteamsteamappshelljumper777team fortress 2tf" "C:Program FilesSteamsteamappshelljumper777sourcesdk_contenttfmapsrcctf_FacilityMakesure"

Valve Software - vrad.exe SSE (May 19 2009)

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

Loading c:program filessteamsteamappshelljumper777sourcesdk_contenttfmapsrcctf_FacilityMakesure.bsp
Setting up ray-trace acceleration structure... Done (2.31 seconds)
2909 faces
1 degenerate faces
1003856 square feet [144555328.00 square inches]
144 Displacements
13666 Square Feet [1967925.38 Square Inches]
2908 patches before subdivision
52188 patches after subdivision
sun extent from map=0.000000
60 direct lights
BuildFacelights:     0...1...2...3...4...5...6...7...8...9...10 (26)
BuildVisLeafs:       0...1...2...3...4...5...6...7...8...9...10 (24)
transfers 3500053, max 490
transfer lists:  26.7 megs
GatherLight:         0...1...2...3...4...5...6...7...8...9...10 (0)
	Bounce #1 added RGB(172746, 165475, 155366)
GatherLight:         0...1...2...3...4...5...6...7...8...9...10 (1)
	Bounce #2 added RGB(50628, 49215, 45754)
GatherLight:         0...1...2...3...4...5...6...7...8...9...10 (0)
	Bounce #3 added RGB(17290, 17320, 16189)
GatherLight:         0...1...2...3...4...5...6...7...8...9...10 (1)
	Bounce #4 added RGB(6268, 6557, 6199)
GatherLight:         0...1...2...3...4...5...6...7...8...9...10 (0)
	Bounce #5 added RGB(2360, 2584, 2463)
GatherLight:         0...1...2...3...4...5...6...7...8...9...10 (1)
	Bounce #6 added RGB(909, 1040, 996)
GatherLight:         0...1...2...3...4...5...6...7...8...9...10 (0)
	Bounce #7 added RGB(355, 423, 406)
GatherLight:         0...1...2...3...4...5...6...7...8...9...10 (1)
	Bounce #8 added RGB(140, 174, 166)
GatherLight:         0...1...2...3...4...5...6...7...8...9...10 (0)
	Bounce #9 added RGB(56, 71, 68)
GatherLight:         0...1...2...3...4...5...6...7...8...9...10 (1)
	Bounce #10 added RGB(22, 29, 28)
GatherLight:         0...1...2...3...4...5...6...7...8...9...10 (1)
	Bounce #11 added RGB(9, 12, 12)
GatherLight:         0...1...2...3...4...5...6...7...8...9...10 (0)
	Bounce #12 added RGB(4, 5, 5)
GatherLight:         0...1...2...3...4...5...6...7...8...9...10 (1)
	Bounce #13 added RGB(1, 2, 2)
GatherLight:         0...1...2...3...4...5...6...7...8...9...10 (0)
	Bounce #14 added RGB(1, 1, 1)
Build Patch/Sample Hash Table(s).....Done<0.0393 sec>
FinalLightFace:      0...1...2...3...4...5...6...7...8...9...10 (14)
FinalLightFace Done
0 of 0 (0% of) surface lights went in leaf ambient cubes.
ThreadComputeLeafAmbient: 0...1...2...3...4...5...6...7...8...9...10 (30)
Writing leaf ambient...done
Ready to Finish

Object names       Objects/Maxobjs  Memory / Maxmem  Fullness 
------------       ---------------  ---------------  -------- 
models                  19/1024          912/49152    ( 1.9%) 
brushes                358/8192         4296/98304    ( 4.4%) 
brushsides            2304/65536       18432/524288   ( 3.5%) 
planes                1262/65536       25240/1310720  ( 1.9%) 
vertexes              4144/65536       49728/786432   ( 6.3%) 
nodes                 1755/65536       56160/2097152  ( 2.7%) 
texinfos               705/12288       50760/884736   ( 5.7%) 
texdata                 20/2048          640/65536    ( 1.0%) 
dispinfos              144/0           25344/0        ( 0.0%) 
disp_verts            3600/0           72000/0        ( 0.0%) 
disp_tris             4608/0            9216/0        ( 0.0%) 
disp_lmsamples       44864/0           44864/0        ( 0.0%) 
faces                 2909/65536      162904/3670016  ( 4.4%) 
hdr faces                0/65536           0/3670016  ( 0.0%) 
origfaces             1508/65536       84448/3670016  ( 2.3%) 
leaves                1775/65536       56800/2097152  ( 2.7%) 
leaffaces             3314/65536        6628/131072   ( 5.1%) 
leafbrushes           1079/65536        2158/131072   ( 1.6%) 
areas                    2/256            16/2048     ( 0.8%) 
surfedges            19412/512000      77648/2048000  ( 3.8%) 
edges                10523/256000      42092/1024000  ( 4.1%) 
LDR worldlights         60/8192         5280/720896   ( 0.7%) 
HDR worldlights          0/8192            0/720896   ( 0.0%) 
leafwaterdata            0/32768           0/393216   ( 0.0%) 
waterstrips            231/32768        2310/327680   ( 0.7%) 
waterverts               0/65536           0/786432   ( 0.0%) 
waterindices          3438/65536        6876/131072   ( 5.2%) 
cubemapsamples           1/1024           16/16384    ( 0.1%) 
overlays                 0/512             0/180224   ( 0.0%) 
LDR lightdata         [variable]     3832448/0        ( 0.0%) 
HDR lightdata         [variable]           0/0        ( 0.0%) 
visdata               [variable]      159415/16777216 ( 1.0%) 
entdata               [variable]       36228/393216   ( 9.2%) 
LDR ambient table     1775/65536        7100/262144   ( 2.7%) 
HDR ambient table     1775/65536        7100/262144   ( 2.7%) 
LDR leaf ambient      8158/65536      228424/1835008  (12.4%) 
HDR leaf ambient      1775/65536       49700/1835008  ( 2.7%) 
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/11302    ( 0.0%) 
pakfile               [variable]      212819/0        ( 0.0%) 
physics               [variable]      131465/4194304  ( 3.1%) 
physics terrain       [variable]       15278/1048576  ( 1.5%) 

Level flags = 0

Total triangle count: 7562
Writing c:program filessteamsteamappshelljumper777sourcesdk_contenttfmapsrcctf_FacilityMakesure.bsp
1 minute, 44 seconds elapsed

** Executing...
** Command: Copy File
** Parameters: "C:Program FilesSteamsteamappshelljumper777sourcesdk_contenttfmapsrcctf_FacilityMakesure.bsp" "c:program filessteamsteamappshelljumper777team fortress 2tfmapsctf_FacilityMakesure.bsp"

 

[Shmitz]

Since most of your time is being spent on the vis stage, it looks you need to be using a lot more func_detail entities. Basically, if it's not a major floor, ceiling, or wall, you should make it func_detail. This is particularly true for any geometry that has odd angles, like cylinder or cone structures, but equally as important for small things that don't really block line of sight, like support beams.

 

[TracerDX]

That's a leak. A very weird one. I've seen those messages when I have a leak, but for some reason VBSP ain't reporting it as such.

Edit. In specific:

FindPortalSide: Couldn't find a good match for which brush to assign to a portal near (73.0 149.0 32.5)
Leaf 0 contents: CONTENTS_GRATE CONTENTS_TRANSLUCENT
Leaf 1 contents:
viscontents (node 0 contents ^ node 1 contents): CONTENTS_GRATE
This means that none of the brushes in leaf 0 or 1 that touches the portal has CONTENTS_GRATE
Check for a huge brush enclosing the coordinates above that has contents CONTENTS_GRATE
Candidate brush IDs: Brush 13247:

 

[krik3t]

http://rvanhoorn.ruhosting.nl/optimization.php?chapter=intro

If you want to understand why it takes so long and what to do for it, just read this great guide. It's really long but it's "must-read" guide.

 

[TracerDX]

Not to be shrewd, but the way that guy explains things makes my head explode. And I understand PVS systems... For what the author claims as "University" level tutorial, he really leaves alot of details of "how it works" out.

 

[Yourself]

Not to be shrewd, but the way that guy explains things makes my head explode. And I understand PVS systems... For what the author claims as "University" level tutorial, he really leaves alot of details of "how it works" out.

During VBSP, every world brush face that doesn't belong to an entity is considered as a splitting plane for the BSP. Some faces are prioritized over others (if it's anything like Q3, it'll prioritize axis-aligned faces) for splitting first, but will eventually split along every brush face that's "inside". Complex brushes cause a lot of splits (and splits also divide other faces in two if they intersect the splitting plane). These splits are what slow down compilation during VBSP and are largely unnecessary since they do nothing to help determine what's visible, since they leave a lot of visleaves (leaves in the BSP which are not inside a brush). This will also end up slowing down VVIS compilation, since there are many more visleaves and many more portals to examine. The optimization site goes through techniques to reduce these effects.

If you take a look at some of the Valve maps, you'll notice that they use a lot of hint brushes, which entice VBSP to break the map up into rectangular blocks rather than weird shapes which could be caused by diagonal faces on brushes.

 

[TracerDX]

>.> I know how PVS works.

Anyways, I don't think hint optimization is a problem here. Its probably a lack of func_detail, as said already.

I retract my earlier statement about a leak, as I found out that error I quoted can be generated without a leak.

 

[HellJumper]

Since most of your time is being spent on the vis stage, it looks you need to be using a lot more func_detail entities. Basically, if it's not a major floor, ceiling, or wall, you should make it func_detail. This is particularly true for any geometry that has odd angles, like cylinder or cone structures, but equally as important for small things that don't really block line of sight, like support beams.

How do I use func_details? Do I just select a wall for example and right click "tie to entity" and turn it into a detail?

Will this affect my map in anyway?

Thanks!

P.S. I do have a pipe that runs underneath the map, but the only way I thought of doing it was to make a wall and use displacement to curve it into two halves and then stick them together. Is there an easier way to do this?

 

[TracerDX]

If its not a wall, or the floor, or the ceiling it should probably be a func_detail, anything you can see around/over/under. Basically, you want the shape non-detail geometry to be as simple as possible. This way the vis process has less to do. func_details are solid and look the same as regular brushes, but they do not define the hull of the map, so func_detailing an outer wall will cause leaks. func_detailing inner walls will circumvent the purpose of VIS all together. It also effects how your polygons are cut out of the brushes, in a good way.

And Yes, tie to entity will do it. func_detail is the default for a reason. Its probably the most common entity, next to prop_static.

As to the displacement pipe. If it works and looks good, then go for it. Though I'd personally use 4 displacements so I can sew them all.

 

[HellJumper]

If its not a wall, or the floor, or the ceiling it should probably be a func_detail, anything you can see around/over/under. Basically, you want the shape non-detail geometry to be as simple as possible. This way the vis process has less to do. func_details are solid and look the same as regular brushes, but they do not define the hull of the map, so func_detailing an outer wall will cause leaks. func_detailing inner walls will circumvent the purpose of VIS all together. It also effects how your polygons are cut out of the brushes, in a good way.

And Yes, tie to entity will do it. func_detail is the default for a reason. Its probably the most common entity, next to prop_static.

As to the displacement pipe. If it works and looks good, then go for it. Though I'd personally use 4 displacements so I can sew them all.

Wow thanks! This was really helpful. What exactly is a leak? I was having a weird problem that I can't even begin to explain, but when I made the walls on the right and left of the spawn room func_details everything worked out perfectly.

The pipes have a flat bottom which is why I used three =P

 

[Cameron:D]

A leak if there there is nothing to seal the inside of the world from the outside void.
The only think that blocks this is world geometry, displacements entitys and props don't. To see if you have a leak, go Map>Load Pointfile, and the red line will go from an entity out through the hole.

 

[Open Blade]

A few things I have learned to help long compile times. And these are biggies.

When I finished Shabbytown, compile time was 6 hours. I had a ton of func_detail but the problem was that it essentially is one huge open skybox area. Hammer hates really big open areas. It really is best to segment your map into smaller areas. For example, if you have an open area, funnel it to a building and then if you want, on the other side you can once again start another large open area. Try your best to stay away from super massive large open areas.

Yes, func_detail is super important. I remember once I had a smaller map that compiled in like 2 minutes. I went back and did some work and it then took 2 hours. I was shocked. Went back in and somehow I had one staircase that got removed from func_detail to world brushes and that one staircase was the culprit. Turned it back to func_detail and bam, back to 2 minutes.


This payload map I am working on is twice the size of Shabbytown and it compiles fully in 9 minutes, that's everything VBSP, VIS, RAD. 3 larger open areas all separated by pass through areas such as buildings or caves (anything you can seal with skybox) and then I have areaportals throughout. Yet to put in my larger hint brushes but I have them in some doorways and window areas.

 

[Yourself]

When I finished Shabbytown, compile time was 6 hours. I had a ton of func_detail but the problem was that it essentially is one huge open skybox area. Hammer hates really big open areas. It really is best to segment your map into smaller areas. For example, if you have an open area, funnel it to a building and then if you want, on the other side you can once again start another large open area. Try your best to stay away from super massive large open areas.

Good examples of how Valve did this are multi-stage maps like Dustbowl and Goldrush. Even each stage is broken up into two distinct open areas. Alleyways and canyons are also good ways to separate open areas while staying outside and not losing sight of the sky (look at stage 3 of Dustbowl or Goldrush, they both contain narrow areas connecting two rather open areas).