I haven't had chance to look at the clip entity snapshot, sorry Tyrann (I solved it by messing around with brush shapes, ironically I might not even need it now since I have expanded my idea).

Anyway, is there any way of getting water to not be fullbright? Is it possible to get them to accept light and shadow? 

slime and lava too... maybe lava should always be fullbright, but then why not just use _minlight to achieve this? 

I believe (and someone correct me if I'm wrong) that they are handled by the engine and not the compiling tools as far as fullbrights are concerned. The only thing that gets done by compilers is to create a vis\bsp portal (not unlike a hint brush) unless you use -wateralpha (or whatever that command is in some qbsp programs) to make it transparent which simply removes the portal and in some cases takes away the fullbright. 

what quaketree said. engine is responsible for the 'lighting' of water (and sky). 

Tyrann: you are awesome.

just in case you didn't know. 

Doesn't -transwater affect performance? 

It does insofar as it makes the water surface not block visibility, so everything beneath it is being rendered whereas it would've been visblocked if compiled with opaque water. Depends on how much additional detail there is underwater. 

Hmmm, it may just work - it looks like the software engine might actually render the lightmaps if the light util generated them. Not sure about glquake. Surface subdivision might cause problems. I'll try an experiment. 

Yeah, it appears it can't be done with tools changes alone. Oh well. 

Cheers for looking into it! I still haven't checked out the latest snapshot... probably will do for the next map since everything is stable and I'm close to finishing... 

Tyrann, do you think that it's possible to make a *liquid do what a sky can do in regards to sunlight only upwards instead? Particularly ones that start off with *slime and *lava? At least then it would make some visual sense that they are fullbright. Obviously they would need .lit support and wouldn't be on by default. Maybe put it in the worldspawn. _mangle support might be nice if someone wants to do something funky in their maps. Just a thought. 

Yeah, I've been thinking about making it possible to set a global lighting level to emit a glow from lava/slime/water surfaces - separate values for each type though. Wouldn't be directed via mangle, but using sample points along the liquid surface.

Shouldn't be too hard but would want to make sure of consistent light levels above and below the water and will need to see how much performace impact it has. 

No mangle is fine, I was just thinking that someone might find some uses for that somewhere down the line is all. Thanks for the answer. 

Maybe you could allow users to set up a file called surfacelights.txt or something that contains a list of textures that should emit light? Maybe it could be defined in a worldspawn key? In addition, having separate support for _lavalight etc. in the worldspawn would be cool. It gets a bit messy if you want to support multiple textures and use different colours, attenuation formula etc. Perhaps it could be set up in a text file? 

I had used Q1rad worked well, the effect was cool, then it broke when the map got large. Maybe light emitting textures could be done with a separate util then appended to the light map. Keep the light program on target without adding more complexity to it.

My ability to write code is limited to cut and paste so ignore me as needed. 

The version of the tools I'm using doesn't support -noambient to disable sounds applied automatically to skyboxes/water volumes etc... I've resorted to using the vis compiler that is coupled with quake adapter worldcraft. Is there a commandline option I am missing on your version? 

Yeah, had it on my todo list but had not gotten around to it yet. You can be my beta tester!

tyrutils-0.6-46-g9c8cbfd-win32.zip 

Not sure this is always desirable. Is there a way to turn off shadow casting for brush entities? It may seem like a weird request but I have a moving platform on top of a kind of cylinder and I don't want the mover to cast a shadow under it. BTW, I've made good usage of _minlight for brush entities, it's a nice addition :) 

the vis I'm using has options for -noambient, -noambientslime, -noambientlava etc etc. 

Brush model shadows should be off by default - they should only cast a shadow if you have added the "_shadow" key.

Those noambient options are what I just added to vis in the snapshot linked above. 

I did open the file and only look at the changelog, not the main text :P 

I've had a look at it. The -noambient switches work, but I get CutNodePortals_r: New portal was clipped away messages now that weren't there with TreeQBSP, also it's now saying I have a leak again even though I had fixed all my leaks in TreeQ. Could do with a -noents option so that I can use pointfile to find whatever is causing the problem (the pointfile particles are all outside the map again, grrr!) 

Try adding -particles 1000000 to the quake engine command line just in case you're running out of particles for the pointfile. 

It's not that, it happened with the previous version too. It just displays a line of particles completely outside the map.
When I used TreeQ with -noents it pointed to all the holes in the BSP before it pointed to the outside entities. I'm probably going to stop farting around with different compilers for this map now otherwise I'm never going to get it finished :P
(I have like 3 other maps I have started and need to get done too) 

Ah, ok - I thought you meant it was not pointing at an entity at all. I'll look at adding that option.