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. 

When I used TreeQ with -noents it pointed to all the holes in the BSP before it pointed to the outside entities.

Having entities that are accessible to the void is the definition of a leak. So you should probably not have entities outside the map (brush entities are okay, point entities are the problem) 

The point is that I can't verify if it's a bsp leak *or* a void entity if I can't -noents, besides TreeQ and vis aren't signalling problems, just Tyr's latest version. It's all a bit weird to say the least.
Kind of having a problem with degenerating brushes for my terrain too, it's really odd. I'm losing interest in the map now, need to get it working as best as I can so I can move on. 

of using double precision floating point numbers in Tyrann's tools. It snaps vertices to integer coordinates if they are off by less than 0.0001, whereas TreeQ snaps them if they are off by less than 0.001. So if you have two vertices which are off by, say, 0.0005, they will be snapped to the same position by TreeQ, but not by Tyrann's tools. The result could be a microleak I think. 

with microleaks! ;)

I'm using TreeQ atm and I'm still getting weirdness. It's probably due to me using cubes rather than triangles for this tri-soup business. Honestly I'm fairly clueless, but the map seems to be holding up ok... just hope people don't laugh too much at me when I release the .map file!