compile taking an hour!

[rex64]

I am trying to compile my level. All of the sudden it went from like 4 minutes to over an hour. I did not add anything much except water. And I deleted it and it did not help. It does BasePortalVis a little slow. Then supper slow on PortalFlow. I dont think I even have a portal (I do not know what a portal is). I have to end the vvis.exe or whatever to make it finish compiling. The only major error I get in the game is vPhysics Penetration Error.

Here is my compiler text:

** Executing...
** Command: "c:\program files\valve\steam\steamapps\rex64\sourcesdk\bin\vbsp.exe"
** Parameters: -game "c:\program files\valve\steam\steamapps\rex64\half-life 2 deathmatch\hl2mp" "C:\Program Files\Valve\Steam\SteamApps\rex64\sourcesdk_content\hl2mp\mapsrc\dm_fungible_crappy"

Valve Software - vbsp.exe (Jan 19 2005)
1 threads
materialPath: c:\program files\valve\steam\steamapps\rex64\half-life 2 deathmatch\hl2mp\materials
Loading C:\Program Files\Valve\Steam\SteamApps\rex64\sourcesdk_content\hl2mp\mapsrc\dm_fungible_crappy.vmf
fixing up env_cubemap materials on brush sides...
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 (0)
FixTjuncs...
PruneNodes...
WriteBSP...
done (1)
writing C:\Program Files\Valve\Steam\SteamApps\rex64\sourcesdk_content\hl2mp\mapsrc\dm_fungible_crappy.prt...done (0)
Creating default cubemaps for env_cubemap using skybox sky_wasteland02...
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) (326642 bytes)
Emitting linux collision data (use -nolinuxdata to disable).
Building Physics collision data...
done (0) (326642 bytes)
Placing detail props : 0...1...2...3...4...5...6...7...8...9...10
Writing C:\Program Files\Valve\Steam\SteamApps\rex64\sourcesdk_content\hl2mp\mapsrc\dm_fungible_crappy.bsp
7 seconds elapsed
Memory leak: mempool blocks left in memory: 48
Memory leak: mempool blocks left in memory: 4

** Executing...
** Command: "c:\program files\valve\steam\steamapps\rex64\sourcesdk\bin\vvis.exe"
** Parameters: -game "c:\program files\valve\steam\steamapps\rex64\half-life 2 deathmatch\hl2mp" "C:\Program Files\Valve\Steam\SteamApps\rex64\sourcesdk_content\hl2mp\mapsrc\dm_fungible_crappy"

Valve Software - vvis.exe (Dec 15 2004)
1 threads
reading c:\program files\valve\steam\steamapps\rex64\sourcesdk_content\hl2mp\mapsrc\dm_fungible_crappy.bsp
reading c:\program files\valve\steam\steamapps\rex64\sourcesdk_content\hl2mp\mapsrc\dm_fungible_crappy.prt
2147 portalclusters
7879 numportals
BasePortalVis:       0...1...2...3...4...5...6...7...8...9...10 (39)
PortalFlow:          0...1
** Executing...
** Command: "c:\program files\valve\steam\steamapps\rex64\sourcesdk\bin\vrad.exe"
** Parameters: -game "c:\program files\valve\steam\steamapps\rex64\half-life 2 deathmatch\hl2mp" "C:\Program Files\Valve\Steam\SteamApps\rex64\sourcesdk_content\hl2mp\mapsrc\dm_fungible_crappy"

Valve Software - vrad.exe (Mar  8 2005)
----- Radiosity Simulator ----
1 threads
[Reading texlights from 'lights.rad']
[45 texlights parsed from 'lights.rad']

Loading c:\program files\valve\steam\steamapps\rex64\sourcesdk_content\hl2mp\mapsrc\dm_fungible_crappy.bsp
No vis information, direct lighting only.
6433 faces
3 degenerate faces
213519 square feet [30746796.00 square inches]
0 displacements
0 square feet [0.00 square inches]
0 direct lights
BuildFacelights:     0...1...2...3...4...5...6...7...8...9...10 (0)
Build Patch/Sample Hash Table(s).....Done<0.0291 sec>
FinalLightFace:      0...1...2...3...4...5...6...7...8...9...10 (1)
FinalLightFace Done
Ready to Finish
Computing detail prop lighting : 0...1...2...3...4...5...6...7...8...9...10
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                   1/1024           48/49152    ( 0.1%) 
brushes                874/8192        10488/98304    (10.7%) 
brushsides            6237/65536       49896/524288   ( 9.5%) 
planes                4050/65536       81000/1310720  ( 6.2%) 
vertexes             12812/65536      153744/786432   (19.5%) 
nodes                 3803/65536      121696/2097152  ( 5.8%) 
texinfos              1636/12288      117792/884736   (13.3%) 
texdata                 12/2048          384/65536    ( 0.6%) 
dispinfos                0/0               0/0        ( 0.0%) 
disp_verts               0/0               0/0        ( 0.0%) 
disp_tris                0/0               0/0        ( 0.0%) 
disp_lmsamples           0/0               0/0        ( 0.0%) 
faces                 6433/65536      360248/3670016  ( 9.8%) 
origfaces             4083/65536      228648/3670016  ( 6.2%) 
leaves                3805/65536      213080/3670016  ( 5.8%) 
leaffaces             7417/65536       14834/131072   (11.3%) 
leafbrushes           1881/65536        3762/131072   ( 2.9%) 
surfedges            46973/512000     187892/2048000  ( 9.2%) 
edges                25145/256000     100580/1024000  ( 9.8%) 
worldlights              0/8192            0/720896   ( 0.0%) 
waterstrips            440/32768        4400/327680   ( 1.3%) 
waterverts               0/65536           0/786432   ( 0.0%) 
waterindices          8421/65536       16842/131072   (12.8%) 
cubemapsamples           0/1024            0/16384    ( 0.0%) 
overlays                 0/512             0/180224   ( 0.0%) 
lightdata             [variable]      821464/0        ( 0.0%) 
visdata               [variable]           0/16777216 ( 0.0%) 
entdata               [variable]       64304/393216   (16.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/28148    ( 0.0%) 
dtl prp lght          [variable]           1/4        (25.0%) 
static props          [variable]           1/2350     ( 0.0%) 
pakfile               [variable]        9906/0        ( 0.0%) 

Win32 Specific Data:
physics               [variable]      326642/4194304  ( 7.8%) 
==== Total Win32 BSP file data space used: 2887653 bytes ====

Linux Specific Data:
physicssurface        [variable]      326642/6291456  ( 5.2%) 
==== Total Linux BSP file data space used: 2887653 bytes ====

Total triangle count: 17743
Writing c:\program files\valve\steam\steamapps\rex64\sourcesdk_content\hl2mp\mapsrc\dm_fungible_crappy.bsp
4 seconds elapsed

** Executing...
** Command: Copy File
** Parameters: "C:\Program Files\Valve\Steam\SteamApps\rex64\sourcesdk_content\hl2mp\mapsrc\dm_fungible_crappy.bsp" "c:\program files\valve\steam\steamapps\rex64\half-life 2 deathmatch\hl2mp\maps\dm_fungible_crappy.bsp"


** Executing...
** Command: "c:\program files\valve\steam\steamapps\rex64\half-life 2 deathmatch\hl2.exe"
** Parameters: -game "c:\program files\valve\steam\steamapps\rex64\half-life 2 deathmatch\hl2mp" -dev -console +sv_lan 1 +map "dm_fungible_crappy"

 

[Dead-Inside]

I have a feeling you've got a leak or some other serious visability error.

Any AreaPortals or Hint Brushes in there?

 

[rex64]

no and no

I do not have either. What are those? Also, how big of a leak do you have to have to have a problem, and how can I find it?

Also, does grass count as a normal object? Or could that be my problem. The bottom of my room is covered only by grass. The green texture thing.

Also, is overlap ok?

Also, I ran the check map for problems and the only thing it came up with was "There is no player start." I have a bunch of player starts. I even tried adding one with its "hammer" fix-it tool. But it did not help.

 

[Ti133700N]

For the leak thing, that's the opposite. Maybe you did have a leak at first or you didn't have any lights. So Hammer didn't calculate vis (wich is 99% of the time the process that takes longer to complete.) Make sure that you are sealing your level correctly, I mean, don't use a big hollow cube.

Overlap is not ok for brushes, it's ok for displacement maps only.

Post a screenshot of the map in Hammer.

 

[rex64]

1-3 hours normal

So, it is normal for the compileing to take 1-3 hours? Wow! Also, here is a screenshot. How bad are overlaps of brushes (those are like blocks right)? Could that be what is causing it to take so long?

Also, what about enclosing everything in a cube? Would that fix the leak? Also, I could use a skymap cube maybe?

 

[Ti133700N]

Good, so now we can easily see why it takes 1 hour. 1 hour for a complete big map like those official CS Source maps is normal. For this particular map though, the problem is that you enclosed your level with a big cube. If I understand what you want to do, your map would be outside, so you would replace all the big brushes that have that wall/ceiling texture by the skybox texture. Then add walls around the castle so that the player won't go into the sky. You could add a 3D skybox later.

Also brushes overlapping are very bad and yes they can sometime cause long compile time and wierd stuff to be displayed, bad fps. You can overlap displacements and models into brushes though (like you tree).

 

[rex64]

compile

It is still compiling. It has been over 15 hours. vvis.exe is using 100% of processor. I think something is wrong.

 

[Limpet]

If you havent already made all the brushes that you don't need blocking vis func_detail. A good example is those bocks you have on the towers. Also learn how to use hint brushes and maybe use that where the top of your castle like thing ends.
I think making a lot of those brushes that are just making your buildings looks nice func_detail will really help cut down the compile time.

 

[rex64]

blocking

I dont understand. All of my brushes are needed (brushes are the rectangles... you make things out of?) I do not understand what you are talking about in your message at all. Please give me some more help. Thanks.

 

[Raeven0]

He says you have many buildings--cylindrical buildings, no less--that could be made into func_detail entities to improve compile time and performance with no loss in appearance.

Using no other optimization tool but func_detail, you can cut a three-hour compile down to about twelve minutes.

 

[rex64]

disadvantage

What is the disadvantage of using that? Why not make everything func_detail?

 

[Raeven0]

Func_detail, being an entity, doesn't block leaks and doesn't cut up VIS leaves. Blocking leaks is very important, and some interior brushes (the cubes in iceworld, for example) provide very important VIS cuts.

 

[Phisionary]

world geometry (stuff that has not been tied to an entity -- such as a 'func_detail' or 'func_brush', whatever) is necessary to generate bsp 'leaf's.
bsp leafs are little sets of geometry that tells the engine what is visible to the camera (player) while rendering any particular frame. If you have no 'world geometry' (or areaportals, hints, and other helpers) than the compiler might treat two totally seperate rooms like one single area. When you are in one room (in the game) it would render both rooms, even though the other might be completely unseen.
World geometry allows the compiler to seperate these areas, so only what is seen is rendered, speeding frame-rates...
The downside is- complex geometry, especially geometry that is not at right angles (I think) can cause the process to slow way the heck down, maybe even produce incorrect results. So complex geometry (made with sphere, cylinder, arch tools; esp. set to high subdivisions) can really bog it down. These are things that should usually be made into a func_detail. Then the leaf-making process can just ignore the complex geometry.
When the complex geometry is stuff that blocks visibility from other geometrically complex areas (Like inside/outside of a cylindrical building, for instance).... there is no easy answer that I am aware of.

Im no expert, though. If any of this is factually incorrect, please correct me.

 

[rex64]

func_detail

How do I change my tower to func_detail? Thanks.

I looked online, but did not see anything helpful:
http://www.hl2world . com/wiki/index.php/Func_detail

 

[Raeven0]

Select the tower, press CTRL-T, choose func_detail from the Classname menu.

 

[rex64]

already on it

It was already turned to fun_detail by default (the fun_detail is selected as the class, and minimum DX level is default (lowest) maximum is default(highest).

 

[Raeven0]

Yeah, func_detail tends to be the default solid entity, but there's always the possibility that you changed an option (Default SolidEntity Class, in this case) despite the fact that you had no idea what it did

 

[rex64]

well

Well this is bad. I think my level is broke.

 

[Phisionary]

Hmmm, I might be confused, but I think you might be confused.

When you press 'Ctrl-T', this does not merely show what entity your brushes are tied to, it ties them as well. So if you press Ctrl-T and it shows 'func_detail' it isn't because it was already func_detail, it's because that's what it turns it into by default.

Now if I misunderstood you, and you didn't misunderstand Raeven0, I'm sry!
To view the entity currently bound to a brush press 'Ctrl-Enter'

So... if you tried tying a few brushes and it seemed to already be selected, try binding the rest too.

Don't forget to save you map as a new file before you mess around with it much. Save often, save concurrent versions. You'll regret it if you don't, I'll bet.

So, two tests (after you've saved, and saved to a new file). Take big bunches of world brushes and tie them to func_detail. I do this to quickly compile complex maps that I've roughed out geometry for, so compiles should never take more than an hour or so (usually 15 minutes or so on my maps). Framerates will be shit if you do this so this isn't for final map versions, just rough ones you can run around in for shits and giggles....

Second, you could try selecting everything in your map and pasting it to a brand new map file.
Maybe it's just my newbishly bad mapping style, or some odd bug, but sometimes this helps if your map is behaving weird.

GL :thumbs:

 

[Raeven0]

Alt-ENTER, unless ctrl-ENTER works as well.

There's nothing wrong with turning huge chunks of world brushes into func_details as long as you do it intelligently

 

[Mapster]

try grouping everything togeather then compiling

 

[Raeven0]

Grouping is purely a Hammer function and has no effect on the compilation process.

 

[Phisionary]

Alt-ENTER, unless ctrl-ENTER works as well.

My bad. Haven't mapped in a couple weeks, already forgettin the basics :cheese:

 

[lordoftheroot]

My record is 48 hours.

Use the fast mode.

To do this, when it asks you how you want to compile it choose the expert or pro mode and then, one of the options is fast mode. This should bring it down to maybe a half an hour for a normally 2 day compile. Also i have used this for a map of mine and it still looks great. so dont worry about a huge graphics drop.