Does having many brushes increase VRAD compile time?

No expert here but does having more faces increase VRAD compile time?
For Example:

Note: these all have nodraw on the unseen faces, I just believe the top is clipped wrong.

Edit: the bottom picture is clipped half way for the texture.

The one on the bottom is correct. There are less T-Junctions so it would speed up compile time. also why is it clipped horizontally half way? either way whats at the bottom is the best. as for your question, it depends, vrad compiles are based on lightmaps and area portals. as well as light sources. So If I had ONE mega huge brush with small lightmaps, it would take a bit, but If I had a dozen smaller brushes, with larger lightmaps, it would take less time.

I clipped it because the top and bottom are two different textures. I forgot to mention that haha.

And thanks for the response, my compile was starting to take way to long on vrad.

Keep in mind. Convex surfaces screw up area portals. Concave are just fine. Also for the more open areas, you can use func_viscluster to speed up compile.

Knowing how to optimize WHILE mapping has really decreased the compiling times for when I map, when I just started mapping, a small map could take forever to compile (as in, hours), while now, I’ve never had a map that takes longer than 3-4 minutes to compile. One thing that comes in mind is to use nodraw while making the brushwork, then nicely attach your texture to the faces you are using.
Oh and, lots and lots of func_detail.

Since you have a large outdoor map, you need to increase the lightmap scale on surfaces where shadows aren’t cast, or the shadow detail isn’t really important. Places like the inside of tunnels, roofs of buildings, roads and grass are the best places to start.

The only thing this really does is make is extremely difficult to navigate outside the level in the 3D portal. All exterior faces of the level are automatically removed regardless of the texture during compile time, unless of course the map has a leak.

The top one could easily be minimized to 4 brush segments, as opposed to the current 10.

The second one is fine and the compile times for it can be split easily by just converting it to a func_detail.

[editline]24th April 2012[/editline]

Also trying to minimize the amount of brushes you use is good practice, whilst it’s not so likely you’ll hit it, the engine does have a limit on the amount of brushes you can have.

Thanks, I fixed it already and I was able to compile.

the compiler has to figure out what to remove, that takes time in itself.
Also, its a piss-ton easier to navigate Nodraw then a ton of repeating / bad looking textures in a level.

Also, it isn’t always easy to figure out what the compiler will “Decide” to remove when mapping high-levels or places with any complex geometry, so no-draw IS highly recommended.

also, It doesn’t clip any func_detail geometry. So it’s wise to use it when making a complex func_detail object

Uh, no.

vbsp decides what is the inside of the level by doing a trace from all entities to try and make it out to the void. Anything that is deemed void is removed, simple as that. In most cases on properly designed levels, this takes less than 5 seconds, regardless of which texture is on the exterior of the map.

I’ve looked at the source code for the compile tools, there is no priority over what faces are removed in the void.

Any func_detail that has a face that’s abutting to a world face is deleted.

I stumbled across this thread whilst bored, just a pointer here I don’t think you understand the issue with t-juncs…

T-juncs aren’t going to affect the length of your compile time massively, unless they cause it to fail all together.