I think (not sure...) that using animating textures on detail brushes causes the compiler to miss out adding the texture to the bsp. I have just been doing some detail stuff on my map, and it seems to do the trick with regard to the compile times, but now I have a missing texture error on map load, which causes FQ to crash :(

Also, I started trying to play with hint and hintskip and am getting some warnings:
WARNING 09: Couldn't create brush face. I will mess around with that and see if I can fix it by recreating the hint brushes and send you the map if I can't. 

 

seems it wasn't the hints, since I removed them anyway.

I also had a few glaring HOM bugs too. Will investigate further soon. Very tired right now so going to bed. 

it was the hint brushes. I will experiment with them later.

The HOM bugs are extremely severe - this is happening in a bare bones version of the map with only the world brushes (no detail), the player start and light on level 4 vis.

vis runs well fast though ;) 

than: Yes, there are secondary shadows which can be reduced using more (but smaller value) ambient lights.
I rather get inspiration from interesting concept art and architecture.

Tyrann: Ah, thats why delay 4 lights produce smoother and brighter result.
And what is delay 5 formula? It's very bleak, have to make light value 100+ to make it noticeable. Cant figure what its useful for. 

Antilight? 

Could it be used to create shadows in a minlight 1000 scene 0_o 

Sorry guys, there was a pretty glaring bug there with the vis util - let me know how you go with the hint brushes as well, since I've only made simple tests for those so far.

2013-04-25 TyrUtils v0.10

* Documentation added for bspinfo and bsputil
* Fix vis bug due to missing vertex copy in v0.9 portal clip changes

Download from disenchant.net. 

Thanks, Tyrann! 

Thank you for the fast update. 

Yeah, I had a small issue when looking at a func_wall through a skip brush that went away with this update. Thanks Tyrann. 

in pretty much all versions. I've been using TreeQ because it doesn't seem to find invisible leaks, I've decided to try and move over to something with more features and I'm getting invisible leaks again. 

I moved to version 10 simply because the pointfile has been fixed, and it's pointing to something that doesn't have a hole in it. 

get it to compile after chopping out a bunch of brushes... honestly though they don't look screwed up to me at all. They all look grid snapped and valid. 

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.