and indicate which brushes (line numbers) cause problems Incan probably give you a hint on what is going on exactly. 

I know exactly where the weird brushes are in the current iteration of the map, but it's stable and vising properly (except if you noclip to the bottom there are tiny little rooms between the brushes).
Honestly it's just the way I've done the terrain. I'm not redoing the whole thing a third time as triangles now, it would probably drive me to murder. I thought of another possible way of doing the terrain just as I went to sleep last night but again I just want to get the map out as long as it vis's right now. 

But it would still be useful for me to see where what TB shows you differs from what QBSP will produce. 

you an email with the file with an explanation. 

On one map world brushes dont showing up (if they are compiled at all, not sure)- only funcs show up;
other compilers (txqbsp, hmap) compile same map fine.

Func_detail usage creates pretty much broken PVS.

Made in Netradiant. 

confirmed: happens when you move brushes between ents involving func_group, moving back to world doesnt help - they still dont get compiled, but moving to other funcs makes them appear.

As said, other compiler do fine
netradiant 

and probably cause netradiant leaves empty brush ents in .map

"classname" "func_group"
}
// entity 230
{ 

@slapmap: Weird. Can you send me a .map which shows the problem? 

This is something in bjp tools that I always used. Your light says it is not supported, though the lighting doesn't seem very different.

Also, I had an error about a missing face if I used light after newskip, but not when I used bjp light. Does your bsp support skip now, because if it does, I guess I can probably just switch. I'll probably want it for detail brushes anyway :)

_selfshadow and _shadow are awesome though! Thanks! 

sent 

@slapmap: Thanks for the test maps. Should be fixed now - try the new snapshot

@than: Yeah, my qbsp supports skip but I only just looked at newskip now and realised that it has water/slime/lava skip as well. That shouldn't be too hard to add. Will look at what is going on with lighting newskip'd maps... 

@than: does this give the expected results?

tyrutils-0.6-52-g4625245-win32

It's not 100% identical to the bjp tools when it comes to treatment of "local minlights", but it should otherwise just make minlights additive. 

thanks for that. I'll try to test it as soon as I can. 

I tried -anglescale (and -anglesense) 0.01 and 0.99 and sunlit area looks identical. Shouldn't it be dimmer with higher value or faces hit at non 90deg? 

@slapmap: oops, missed setting the sunlight variable from the command line. This should fix it:

tyrutils-0.6-53-gee2dc38-win32.zip 

does this actually work? I was experimenting the other day with setting it to really high amounts to see the effect... and even at "-gate 100", there is nothing apparent. My assumption would be that this would make the map very dark with harsh cutoffs. Am I confused on how this works? (I understand that it's intended to be used with very low settings)

Using the released 0.6 tools. 

should work - only affect 1/x, 1/x^2 lights though. Doesn't affect lights with the default linear falloff. 

Updated to affect linear lights as well in the next release (which I should do soon). 

Updated to affect linear lights as well in the next release (which I should do soon). 

Hmm, I still get no visible difference, even took screenshots - nothing. Sunlight is even no matter what value I use http://imgur.com/4GNXAzC

I use "light -anglescale 0.xx mapname.map"
to compile.



Again, thanks for quick updates 

I get a clear difference here - what keys are in your worldspawn entity?

-anglescale 0.5 (default)

-anglescale 0.0 

"light" "10"
"_sunlight" "110"
"_sun_mangle" "300 -65 0" 

@slapmap

Those keys look okay. Just check the light.exe output and make sure you're running version 0.6-53-gee2dc38. Otherwise, if you email the .map to me I'll try it here and see if I can tell what's going on. 

Would it be possible to have separate vis for water,slime and lava? This way you could have a controllable form of occlusion culling to help keep r_speeds low. 

r_wateralpha applies to all fluids, so you'd need to have some engine cvar that applies only to water in order to use that properly, otherwise you'd get HOM effects on the lava and slime that were blocking vis if their surface transparency was using the wateralpha setting :/