I have a map with 17 turrets. The turrets are based on the p2editor's turret instance with the addition of a proxy trigger output to fire when the turret is killed. These triggers are connected to a math_counter which, in turn, triggers when all turrets are killed.

However, making these 17 connections between the turrets and the math_counter dramatically slows down the ThreadComputeLeafAmbient step of vrad. Without these connections, the vrad process takes approx 2 mins. When the connections are made, the vrad process time jumps up to 7 mins.

Does anybody know why adding the connections impacts vrad and what can be done to improve it?

Does making some of the connections increase vrad time by a little, or is it all or nothing? Does the math_counter trigger any lighting changes? I'm not sure if the compiler is smart enough to ignore non-triggerable named lights, but I can't think of what else would cause it.

Vrad has NOTHING to do with entities. All it does is bake lights on surfaces with math that I don't understand. It's really odd this is happening, maybe because the bsp is bigger when entering rad. :/

I sgreed that I can't see any reason why vrad should be slowing down with the addition of these connections - so it must be some other effect I'm seeing. I'll try and get some time over the comming weeks to experiment and attempt to track down the reason.

vrad only calculates lighting on surfaces (and props). Based on the surface's lightmapgrid size (that tells how detailed/blurred the lighting should be) it can take some time. Named lights calculated twice (on/off state brigthness that adds to the sutrrounding when switched or even if not switched). When the brightness of a surface is determined, then vrad calculates light bounces multiple times, so not directly lit surfaces are lit too. Its the lightmap size that can drastically increase vrad compile time, or big named night entities (especially with huge radius) or environment lighting, or lot of prop with selfshadow and "disable shadows" disabled. No other things can increase vrad time that much. Also, triggers etc are nut ran while compiling, some even a superbig and slow script and lots trigger cant affect vvis or vrad.
So if you not misread the compiling (maybe its not vrad that takes that long time) then I'm also really interested what can cause it! And share your findings!

Generally vrad should be the slowest of the three compile steps.
And as DaMaGepy said, the biggest influences on it:
- Named lights.
All compiled twice, in on and off state. And if there's more named light every combination is calculated; so if you have three named lights all the following combinations are calculated:
off/off/off
off/off/on
off/on/off
off/on/on
on/off/off
on/off/on
on/on/off
on/on/on
So basically adding a few named lights can dramatically increase the compile time.
(using hard falloffs can somewhat reduce this but still, keep in mind named lights can significantly increase compile time)

• lots of props
  We have a map in portal stories where the geometry and all is rather simple, but there are just so many props that need to be lit that the compiling of the map takes a very strong computer still over 2 hours. At least 105 minutes of this are occupied by vrad.

• lightmap scales
  By lowering the lightmap scales you can increase the shadow quality, but it costs compile time and your file size can blow up if you bring it down too far on too much surfaces.