Long compile time

I'm having a long compile time and I think I found out why.

Dose this look right?





See how the brush face is split in small boxes? I dont see why it
would split like that. could a strange brush clipping problem
cause a uber long compile time?

I remember reading some place that every 16 or was it 32 blocks it would break the map up like that.. I also recall it saying where the green lines are on the tools it would break the map there as well as where the brown lines are. Its built into the tools.. I think to help compile times..

Other than that I am not sure why it is doing it.

Those shouldn't cause long compile times, though it it bizarre- I usually get triangular splits :/ And no, your map shouldn't be split up like that every 16/32 units (though there was something about every 1024 blocks or so?) Can you post your compile log?

Mhh I've got that to on all my maps :sad:

as lep said, post the log.

i on the other hand feel it may be more basic. compiles in HL2 cannot be much different than HL1 in the respect of long compiles.

long compiles are cause by one thing, or a cumulative effort of a lot, but its always basically.

1) how large the open areas are.
2) what all can be seen from any given point.
3) the number of surfaces on the area seen.
4) the light, and its effect on the area seen.
5) the improper use of func_?'s

6) a machine to small to compile fast to begin with.

any one or a combination of all these things will boost compile times. if your compile log has no clues as to the reason for the lengthy compiles, its more than likely your mapping style. you may need to rethink how you construct maps. thats not meant offensively. each of us had to learn it. my last maps had many times more architecture, yet compiled faster than my earlier maps. 1, because i built them better and 2, because i had a larger machine by the end, but #2 was only on the last 2 maps, the others were all created on the same machine and still the times reduced as i gained experience.

are you using the default lightmap resolution?

are you using the default lightmap resolution?

No, for most of my floors I'm using 4 or 8.

Here's the strange thing. The huge open area of the map has
always compiled very fast 10 minutes or so. I've added about 6
rooms of various sizes and for the most part they compiled quickly too,
then, out of no where the compile time went from 1 hour or less to 24
hours +.

It gets hung up on leaf vis (I think) and I read that intersecting
brushes cause this, but I havn't found any (well I found about 4 small
ones).

note that the screen shots are done with mat_wireframe 3 so you dont
see the triangles.

[edit] CRAP! I just deleted my log off my clip board and now I cant post it!

but I gave it a look over and, what would you know... it only took 6
hours. So I fixed the compile problem it would seem, but I still
have this face split problem and it hits my fps kinda hard.

I'll do another compile and see how it works out.

<DIV class=quote>
<DIV class=quotetitle>? quoting DrGlass</DIV>
<div class="quotetext">

Here's the strange thing. The huge open area of the map has always compiled very fast 10 minutes or so. I've added about 6 rooms of various sizes and for the most part they compiled quickly too, then, out of no where the compile time went from 1 hour or less to 24 hours +.

</DIV></DIV>

Says really slow

the stuff is cumulative Doc.

you add things to the map, it sees more, it increases compiles. If for some reason you put the added rooms in the wrong places and the map can see them all from the big area, you cause the extra time.

I dunno how reliable the new gizmo is, but with the old HL1, anything you saw with GL_Wireframe 2 your engine was drawing and thats why compile went up.

assume for the moment that the new wireframe works the same way.. what you see in the grids, is what its drawing. and MORE=LONGER.

there may be more than one setting for the new wireframe.. try 1.. and 2 and 3 to see if it has different results.

[edit]

DrGlass said:
I used the batch compiler from this site, so where would the log be?

how was the compile before the batch usage?

the thing about front ends is, if you use to options that clash, or DO THE SAME ACTION they will bork out in utter confusion.. for instance (fast and expert both checked). when you clicked the options in the batch gizmo, did you check to many options?

again, how did it compile before?

</div>

DrGlass said:
Here's
the strange thing. The huge open area of the map has always compiled
very fast 10 minutes or so. I've added about 6 rooms of various sizes
and for the most part they compiled quickly too, then, out of no where
the compile time went from 1 hour or less to 24 hours +.

Says really slow

the stuff is cumulative Doc.

you add things to the map, it sees more, it increases compiles. If
for some reason you put the added rooms in the wrong places and the map
can see them all from the big area, you cause the extra time.

I dunno how reliable the new gizmo is, but with the old HL1,
anything you saw with GL_Wireframe 2 your engine was drawing and thats
why compile went up.

assume for the moment that the new wireframe works the same way..
what you see in the grids, is what its drawing. and MORE=LONGER.

there may be more than one setting for the new wireframe.. try 1.. and 2 and 3 to see if it has different results.

True, but I know the diffrence between a jump in compile time due to
more brush work or elements and a jump due to a probelm. It seems
though that I fixed the problem with the compile time so no
worries. I'm not sure what I did (I went through the map and
optomized it quite a bit so I dont know what one thing fixed it) but it
worked.

read my [edit]

i'm pretty certain that the grid is being generated by the tiling of textures. i don't know that it's really splitting brushes though, because a lot of the lines end at corners without continuing around them.

If VIS is taking ages to run, then you can run VBSP with -glview and then glview.exe straight after it- this will help you troubleshoot areas, and tell you how you can improve visibility with HINT brushes, areaportals and func_brushing objects. Or, you can run the game with mat_leafvis 1 and mat_wireframe 1 and see where your leaves and what you can see from where. BUT, I don't think VIS affects how faces are split- this strange splitting is probably due to your texture choice, or your compile options, or a different lightmap resolution/smoothing groups :/

I used the batch compiler from this site, I didn't check any
boxes. I'm going to compile it again and see if I'm still getting
the problem. I've added some HINTs which should improve the large
outdoor area's speed.

I've used used Nemesis batch compiler for most of the map compiles I've
done, I also use the hammer compiler (when I'm feeling lazy).
Orph, I'm almost 99% sure that I have everything set up right, I'll
post my next log so you guys can check it.

DrGlass said:
Orph, I'm almost 99% sure that I have everything set up right, I'll post my next log so you guys can check it.

then, you have one option left.... you.

its a hard lesson to learn, some never do but learning what works and what does not is all part of the process.

lets hope you get what you desire, long compiles fortunately do not always mean unplayable.

Like fishy said, those boxes on the ground are where the texture
tiles. You can see that in the screens. One of the first
things I figured out when mapping for HL1. was that you can drop
r_speeds by blowing up the textures, so they don't tile as often.
I'm sure if you doubled the textures size and recompiled you would be
getting those squares a quarter of the time. However, I'm not
sure if that would be the cause of longer compile times.

one thing i've noticed is that certain types of lights will make it compile very long. My map took 30 minutes before, then when I added orange lights with brightness 200 in my elevator shaft and set them to "strong pulse noblack", the compile time took a whole hour. My framerate also drops rediculously whenever i look at pulsating lights. Overall i think hl2 just doesn't like pulsating lights.

or perhaps its my computer that doesn't like them?

<DIV class=quote>
<DIV class=quotetitle>? quoting Carcase</DIV>
<DIV class=quotetext>one thing i've noticed is that certain types of lights will make it compile very long. quote]</DIV></DIV>
Assuming HL2 is like HL1.

Textured lighting count as 6 entity lights during compiles. each one increases the compile times accordingly.

Sorry if this was mentioned before (I just scimmed the thread), but
type in mat_wireframe 3, this will show you the actual BSP cuts,
mat_wireframe 1 shows how the engine draws each polygon (triangles).

Sorry if this was mentioned before (I just scimmed the thread), but
type in mat_wireframe 3, this will show you the actual BSP cuts,
mat_wireframe 1 shows how the engine draws each polygon (triangles).

Yeah, those screen shots were shot with mat_wireframe 3. So if
thats the BSP cut that would debunk the texture tile size, right?

Well I tryed to compile the map again and, what would you know, I get a
strange brush error re-load hammer and it tells me that 1 brush wasn't
loaded. Then I save it, re-compile and I get a leak! This
is getting to be a huge head ache. How do I find a brush by it's
number?

How do I find a brush by it's
number?

Ctrl-Shift-G

Those shouldn't cause long compile times, though it it bizarre- I usually get triangular splits :/ And no, your map shouldn't be split up like that every 16/32 units (though there was something about every 1024 blocks or so?) Can you post your compile log?

yea every 1024 line (the red ones) the bsp makes a cut.

---

materialPath: e:\games\steam\steamapps\wereami0@hotmail.com\half-life 2 deathmatch\hl2mp\materials

Loading E:\Games\Steam\SteamApps\wereami0@hotmail.com\sourcesdk_content\hl2mp\mapsrc\dm_cliff.vmf

fixing up env_cubemap materials on brush sides...

0 . . . 1 . . . 2 . . . 3 . . . 4 . . . 5 . . . 6 . . . 7 . . .
8 . . . 9 . . . 10 0 . . . 1 . . . 2 . . . 3 . . . 4 . . . 5 . .
. 6 . . . 7 . . . 8 . . . 9 . . . 10 Processing areas... done (0)

Building Faces... done (0)

Chop Details... done (0)

Find Visible Detail Sides...

Merged 830 detail faces... done (0)

Merging details... done (1)

FixTjuncs...

PruneNodes...

WriteBSP...

done (3)

writing E:\Games\Steam\SteamApps\wereami0@hotmail.com\sourcesdk_content\hl2mp\mapsrc\dm_cliff.prt... done (0)

Creating default cubemaps for env_cubemap using skybox sky_day01_05...

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 (3) (2504851 bytes)

Emitting linux collision data (use -nolinuxdata to disable).

Building Physics collision data...

done (2) (5414778 bytes)

Error! To use model "models/props_lab/Cleaver.mdl"<br style="color: red;">
with prop_static, it must be compiled with $staticprop!<br style="color: red;">
Error loading studio model "models/props_lab/Cleaver.mdl"!

Placing detail props : 0 . . . 1 . . . 2 . . . 3 . . . 4 . . . 5 . . . 6 . . . 7 . . . 8 . . . 9 . . . 10

Writing E:\Games\Steam\SteamApps\wereami0@hotmail.com\sourcesdk_content\hl2mp\mapsrc\dm_cliff.bsp

55 seconds elapsed

1 threads

reading e:\games\steam\steamapps\wereami0@hotmail.com\sourcesdk_content\hl2mp\mapsrc\dm_cliff.bsp

reading e:\games\steam\steamapps\wereami0@hotmail.com\sourcesdk_content\hl2mp\mapsrc\dm_cliff.prt

2342 portalclusters

7031 numportals

0 . . . 1 . . . 2 . . . 3 . . . 4 . . . 5 . . . 6 . . . 7 . . .
8 . . . 9 . . . 10 0 . . . 1 . . . 2 . . . 3 . . . 4 . . . 5 . .
. 6 . . . 7 . . . 8 . . . 9 . . . 10 Optimized: 2754 visible clusters
(0.00%)

Total clusters visible: 772854

Average clusters visible: 329

Building PAS...

Average clusters audible: 698

visdatasize:585830 compressed from 1386464

writing e:\games\steam\steamapps\wereami0@hotmail.com\sourcesdk_content\hl2mp\mapsrc\dm_cliff.bsp

6 hours, 38 minutes, 50 seconds elapsed

[Reading texlights from 'lights.rad']

[45 texlights parsed from 'lights.rad']

Loading e:\games\steam\steamapps\wereami0@hotmail.com\sourcesdk_content\hl2mp\mapsrc\dm_cliff.bsp

13979 faces

4 degenerate faces

1718381 square feet [247446880.00 square inches]

89 displacements

876284 square feet [126184928.00 square inches]

13975 patches before subdivision

101904 patches after subdivision

72 direct lights

0 . . . 1 . . . 2 . . . 3 . . . 4 . . . 5 . . . 6 . . . 7 . . .
8 . . . 9 . . . 10 0 . . . 1 . . . 2 . . . 3 . . . 4 . . . 5 . .
. 6 . . . 7 . . . 8 . . . 9 . . . 10 transfers 3776163, max 393

transfer lists: 28.8 megs

0 . . . 1 . . . 2 . . . 3 . . . 4 . . . 5 . . . 6 . . . 7 . . .
8 . . . 9 . . . 10 Bounce #1 added RGB(95715, 64715,
26379)

0 . . . 1 . . . 2 . . . 3 . . . 4 . . . 5 . . . 6 . . . 7 . . .
8 . . . 9 . . . 10 Bounce #2 added RGB(11863, 7679,
3477)

0 . . . 1 . . . 2 . . . 3 . . . 4 . . . 5 . . . 6 . . . 7 . . .
8 . . . 9 . . . 10 Bounce #3 added RGB(2080, 1429,
700)

0 . . . 1 . . . 2 . . . 3 . . . 4 . . . 5 . . . 6 . . . 7 . . .
8 . . . 9 . . . 10 Bounce #4 added RGB(507, 371, 177)

0 . . . 1 . . . 2 . . . 3 . . . 4 . . . 5 . . . 6 . . . 7 . . .
8 . . . 9 . . . 10 Bounce #5 added RGB(137, 104, 48)

0 . . . 1 . . . 2 . . . 3 . . . 4 . . . 5 . . . 6 . . . 7 . . .
8 . . . 9 . . . 10 Bounce #6 added RGB(40, 32, 14)

0 . . . 1 . . . 2 . . . 3 . . . 4 . . . 5 . . . 6 . . . 7 . . .
8 . . . 9 . . . 10 Bounce #7 added RGB(12, 10, 4)

0 . . . 1 . . . 2 . . . 3 . . . 4 . . . 5 . . . 6 . . . 7 . . .
8 . . . 9 . . . 10 Bounce #8 added RGB(4, 3, 1)

0 . . . 1 . . . 2 . . . 3 . . . 4 . . . 5 . . . 6 . . . 7 . . .
8 . . . 9 . . . 10 Bounce #9 added RGB(1, 1, 0)

0 . . . 1 . . . 2 . . . 3 . . . 4 . . . 5 . . . 6 . . . 7 . . .
8 . . . 9 . . . 10 Bounce #10 added RGB(0, 0, 0)

Build Patch/Sample Hash Table(s)..... Done<1.1161 sec>

0 . . . 1 . . . 2 . . . 3 . . . 4 . . . 5 . . . 6 . . . 7 . . . 8 . . . 9 . . . 10 FinalLightFace Done

Ready to Finish

0 of 0 (0% of) surface lights went in leaf ambient cubes.

ComputePerLeafAmbientLighting: 0 . . . 1 . . . 2 . . . 3 . . . 4 . . . 5 . . . 6 . . . 7 . . . 8 . . . 9 . . . 10

Object names Objects/Maxobjs Memory / Maxmem Fullness

------------ --------------- --------------- --------

models
81/1024
3888/49152 ( 7.9%)

brushes
3539/8192
42468/98304 (43.2%)

brushsides
27425/65536 219400/524288
(41.8%)

planes
9988/65536 199760/1310720
(15.2%)

vertexes
23897/65536 286764/786432
(36.5%)

nodes
5557/65536 177824/2097152 (
8.5%)

texinfos
7700/12288 554400/884736
(62.7%)

texdata
463/2048
14816/65536 (22.6%)

dispinfos
89/0
15664/0 ( 0.0%)

disp_verts
11369/0
227380/0 ( 0.0%)

disp_tris
19072/0
38144/0 ( 0.0%)

disp_lmsamples
3205834/0
3205834/0 ( 0.0%)

faces
13979/65536 782824/3670016
(21.3%)

origfaces
9581/65536 536536/3670016
(14.6%)

leaves
5639/65536 315784/3670016 (
8.6%)

leaffaces
17768/65536
35536/131072 (27.1%)

leafbrushes
6506/65536 13012/131072
( 9.9%)

surfedges
104898/512000 419592/2048000
(20.5%)

edges
62043/256000 248172/1024000 (24.2%)

worldlights
71/8192
6248/720896 ( 0.9%)

waterstrips
1326/32768 13260/327680
( 4.0%)

waterverts
0/65536
0/786432 ( 0.0%)

waterindices
25647/65536
51294/131072 (39.1%)

cubemapsamples
97/1024
1552/16384 ( 9.5%)

overlays
11/512
3872/180224 ( 2.1%)

lightdata
[variable]
18188228/0 ( 0.0%)

visdata
[variable] 585830/16777216 ( 3.5%)

entdata
[variable] 237372/393216
(60.4%)

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/57298 ( 0.0%)

pakfile
[variable]
917535/0 ( 0.0%)

Win32 Specific Data:

physics
[variable] 2504851/4194304 (59.7%)

==== Total Win32 BSP file data space used: 29847842 bytes ====

Linux Specific Data:

physicssurface
[variable] 5414778/6291456 (86.1%)
VERY FULL!

==== Total Linux BSP file data space used: 32757769 bytes ====

Total triangle count: 38602

Writing e:\games\steam\steamapps\wereami0@hotmail.com\sourcesdk_content\hl2mp\mapsrc\dm_cliff.bsp

43 minutes, 28 seconds elapsed

---

Here is the log, I dont see any problems (the cleaver isn't an issue).

I marked the times and some other things. I'm going to jump ingame a play the map over.

Well whether or not we know what the problem is, My best guess would be the lighting. To figure it out for yourself, i would recommend setting each room and hallway to its own vis-group, then turn them all off, and go one by one, inspecting the compile times of each one. if you already know the room thats having problems then start vis grouping objects within that room and turning them all off. try starting the room over (not seriously, just in a sense) have all the entities' vis group turned off, then add each entity until you have narrowed down the problem. thats how I handle finding cluster saw problems and things like that.

though you may want to patch up the leaks with a temporary brush.

Well I dont think I'm getting any more compile problems, I do have some serious lag issues though.

Lots of physics lag is showing up in +showbudget, even in places with
very few physics objects. Do static model's add to physics
lag? would changing their collision to BSP help?

should I start a new thread?

go ahead start a new thread it wont hurt