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!
