Send me the map file with the invalid brushes please - I can't fix these problems without test cases! 

I'm doing it now buddy chillax!... :P 

I have a version of my speedmap that hard-crashes the qbsp program in the latest build... (yeah it's that buggy as shit speedmap that I pretty much abandoned in a fit of rage) 

@Fifth: It might be a buggy map, but still interesting to see - I don't want qbsp to crash at all. Send it through if you don't mind. 

I had leaks and collision "holes" on my grid-aligned terrain as well, it often happens with complex non-axial geometry like terrain, because qbsp creates many usless splits everywhere from adjacent planes. Sometimes its just random and you can move geometry around and it becomes better (or worse).
Turn on r_showtris and marvel at the mess of q1bsp.

Is it even possible to make compilers stop splitting everything with everything and keep the original editor geometry, like q3map does, but still maintain q1bsp format compatibility? Why even brush_ents have splits inside an entity. Its already bad enough that splits are every 255 units just for compatibility with 90s software render. Ridiculously inefficient. 

To be honest in that speedmap I had messed around with a few settings in the hope that I wouldn't have to change my method of making terrain (which is somewhat similar to floor lofter method in UT)... it was pure laziness on my part.

Regards to the earlier invisible leaks it was some other bug in a different map (non-terrain).
I do want to make more interesting terrain but it looks like I'll have to make compromises if it's for Quake 1. Even making non-collision geometry and trying to make my own clipping using clip brushes seems to bring its own problems.
Even worse is that Q3 is probably a good game to make maps for in terms of stability and compatibility but it's a multiplayer game, who cares about that? It's good if you want to make a portfolio of work, but if you want to make a fun map to play then you'd get a bigger audience mapping for Doom 1 or 2. 

would it be possible to add in a mode where sunlight is replaced with an array of suns shining at different angles in a sphere? would be a nicer, more consistent (and easier) way of doing fake GI.

the sun array needs to be additive, but the values would need to add up to the final value specified as the sun level, so you'd probably need to make the individual suns in the array emit at maybe 1 or 2 brightness, which means you'd need floating point light values up until you right the results into the map file, at which point it would be safe to round them off. 

@necros: Sure it's possible, but not sure how good it would look for a whole lot more ray traces per surface point. Will put it on the TODO list as something to try out though. 

http://necros.fov120.com/temp/nesp10gi.jpg

Fake GI
Normal Sunlight

This is with 32 suns iirc. 

I had modded light.exe to do this a long time ago, and it does look good. You need a lot of suns for best results, though.

FYI, the mod was really easy -- BJP's "skyambient" already exists and uses a multiple sun method, but gives really flat results, and all you need to do is remove the clamping and make the suns much dimmer (and more numerous) and you'll get something that looks like GI. 

yeah, that's what i did for the above shots. i was hoping for some better integration from someone who knew what they were doing. :)

my version has a severe limitation because light levels are integer values but because of the number of suns, the actual light levels that those suns emit needs to be very low so you would need fractional values for all these low level suns. the end result would still be well over 1.0 so you'd just round the final result (after all the suns have been done, since they are done first) and then you would just light normally with the rest of the point lights. 

With a multithreaded light util the extra traces shouldn't matter. Light is never the bottleneck in map iteration anyway! Those tests look great, necros! 

ever apply clip textures to a func_detail... I just spent about 30 minutes tearing my hair out because of errors. 

Use a Skip texture instead. That gives you an invisible (solid) brush that will cast shadows. 

Remember that projectiles collide with skip brushes but not clip brushes, in case that matters to you. But yeah, if it's not possible to create a clip detail (which isn't a very sensible combination when you think about it) a warning from the compiler might be best. 

I was being lazy when I was making the clip brush that's all... I have no idea what a clip detail brush would accomplish. :P 

Can be used to make a shadow where there is no structure (perhaps as a hint to a secret area?) without having to mess with recessed areas behind a sky texture (as seen in e1m5 where there's a Quake symbol shadow leading to the Quad secret) and then using func_illusion to make a false sky. Seeing as the detail brushes will get merged into the bsp as brushes and not as an entity it helps to keep the entity count down as you don't need to have the func_illusion brush.

The tricky part would be putting it where it won't be noticed by the player because it will of course act like a wall in all respects (with the exception that it won't be drawn on the screen). So it would have to be high enough to not block the players movements and not block a monsters attack in normal circumstances. 

You can use a func_illusionary with _shadow set to 1 and skip texture to make invisible shadow casting brushes without collision. 

Really? 

an invisible collision brush that doesn't cast a shadow? 

Didn't know that about func_illusionary either. 

When you compile with onlyents, switable light styles seem to get broken. I remember this being a problem in older tools that aguirre fixed in his tools. Maybe you could check that one out, Tyrann? 

you need to run light -onlyents after running qbsp -onlyents. This is true for the original tools as well, Ii think. 

I don't remember there being a -onlyents option on the original light. That might be what aguirre added as a fix. I'll take a look. 

-onlyents on light is only supported in aguirre's tools afaik, though for all I know, it maybe have been supported in the original tools. I always used tyrlight before switching over to aguirre's tools though (except for the time I used the WC1.6 compile dialogue... yuck!)