Compile Stopped at "9..." /10

Dario D.

Spy
Joined
Nov 30, 2004
Messages
710
Reaction score
0
Last time I did a full compile on my map, it took about 9 hours, and completed.

This time, Ive been compiling for about 38 hours, and VVIS.exe has been stuck at:

1...2...3...4...5...6...7...8...9...

for about 24 hours, and the CPU useage is still at %100.

Is this normal? Will it ever finish? Each digit in the number-line takes incrementally longer and longer to complete, but this last one [9...], has been taking almost 24 hours.

I don't want my CPU to fry, but I don't want to compile all over again, either. The map is 100% done; this is the final full-compile.
 
tip: learn how to group every single thing in the map. also, everything that is a brush that is not used as a wall, floor or ceiling should be a func_detail.
The skybox is also vital to make vvis go faster.
if your map looks like this:
_______
| |
| o |
|______|

o being the brushes and such, and the rest being the skybox, it will take forever to compile.

EDIT: bah, my illustration got fudged up, but you'll hopefully get my point.
 
Alright, thanks. Will do. Gonna stop the compile now (DOS batch compiler).
 
I get that alot. its not a error as much as it is a good suggestion to optmize the map (as named above). If you were to wait long enough it would finish. just have to wait a bit longer.
 
zeOx said:
tip: learn how to group every single thing in the map. also, everything that is a brush that is not used as a wall, floor or ceiling should be a func_detail.

1: Grouping objects? Do you mean Vis Groups, or actual grouping?

If you mean actual grouping, what does it do?

2: I often decide to leave the larger decorative brushes solid (and not func_detail), so that they can remove more surface area on the BSP they are covering (less to render).

Example, in the center of the plaza there is a large flat of concrete on the street. I want this to be solid BSP, so that it will "remove" the street surface beneath it, so there's less to render. I don't want too much surface space active at one time, to cut back on lightmaps and normal/cube-mapping in the scene.

Do I have it backwards?
 
Dario D. said:
1: Grouping objects? Do you mean Vis Groups, or actual grouping?

If you mean actual grouping, what does it do?

Neither VisGroups nor grouping affect compilation in any way (unless the VisGroup is invisible...). He's probably referring to making, for instance, a convex corner out of one brush instead of two that meet.

Dario D. said:
2: I often decide to leave the larger decorative brushes solid (and not func_detail), so that they can remove more surface area on the BSP they are covering (less to render).

Example, in the center of the plaza there is a large flat of concrete on the street. I want this to be solid BSP, so that it will "remove" the street surface beneath it, so there's less to render. I don't want too much surface space active at one time, to cut back on lightmaps and normal/cube-mapping in the scene.

It depends on how large the concrete slab is. If it's small enough for the players to see over, then you're hurting yourself by forcing the surrounding area's leaves and faces to be split some six or more times as much. If players can't see over it except by jumping, it can be a world brush provided you use hint brushes to ensure that no leaves become taller than it is.
 
Ah, I see. Okay, thanks.

Ennui said:
good god man, optimize.
Oh, I have; believe me. The map used to take almost 2 hours to do a Quick Compile. Now it only takes 32 minutes. And, incase you haven't seen it (sig), it's a visual mojo, that's extremely challenging to zone properly (it's my first Source map, so I did 90% of construction without thinking about zoning and occlusion, not thinking it would actually become a problem).

But I'm working on it... :cheers:
 
Back
Top