It is no volumetric fog though, just plain fog that applies everywhere (depending on the engine). It also looks very different in different engine implementions. Can add a lot of atmosphere but don't rely do much on it because of those issues. Test your map in at least fitz, darkplaces and aguirre's glquake. 

no info_command needed

info_command can be used when you only want it foggy in certain areas - ie. turning it on & off as the player progresses through the map ('in vein' for an example) - which i think is what ricky meant. obviously doesn't work if you only want fog on the floor or in pits a la q3 

I stupid - I've been using an info_command for global fog! I used it with triggers in thehand.bsp go get red fog in an arena, and feint grey fog in the rest of the map ;)

My current project has some fog, and im using an info_command for global fog there too. Maybe I should change it to worldspawn 

volumetric fog, or something like it, should go on the list I think. Let's see how the bsp format thing ends up.

Not now, of course. 

has a colored fog in tree colours in the option console. 

> But who really created that ?
> mh, aguirre, i'm confused about this..

As far as I'm concerned it remains primarily Aguirre's work; it is still his light tool after all; all I did was add colour support to it. But full credit for the original tool belongs to the original author.

> why not called it version 1.4?

I don't want to "take over" the tool (I'm not a tools guy for starters!); the original is still Aguirre's and if some day he releases an updated version then the next version number is his and his alone to take. This is release 2 of a fork of his 1.43, and nothing more. 

I think the tool's readme has a list of authors / inspirations. 

I was just joking.

If i had been really smart, I would have wrote 1.44, or 1.5 or whatever.
I'm even not smart enough to get a coloured fog, or it would have been in worldspan with a colored light.

But that's not fog. Still fun to see it in Telejanos. 

..I add worldspawn fog in a map and then a user play it in a no-fog engine ?

or much better if a user play it also adding a 2nd fog from options/menu in engines such TomazQuake/Telejano ?? 

Why did you cross post? 

Does using Fog do anything to engine performance? I'm guessing not, but would be fairly neat if it could make some larger areas run faster :E 

Normally fog has no effect on performance because the calculation of what is visible is performed by the VIS tool, which has no knowledge of fog levels. Somewhere (although I can't recall where) there is a version of VIS which you can instruct to mark everything beyond a certain distance as not visible, and this could be used in conjunction with fog in the way that you suggest. I'm hoping someone can fill in the blank of which version of VIS supports this. 

aguirre's vis has the -visdist # option that considers anything beyond that distance and invisible. 

Indeed.. It can be helpfull in huge map, unless the player decide to change the fog setting right ? 

I'd guess if they change the fog setting it'll just look cack as stuff will be cut off anyway, they can't change what the vis tells it to draw. 

i haven't really found it helpful at all. :(

i mean, on paper it sounds amazing but in practice, there's a lot more limitations to it.

first of all, it can't really be used for huge outdoor areas. if a visible face is disabled you see the void behind it. if a player hasn't turned off the old style glquake HOM void effect, that's what they'll see.
if they do have gl_clear on, stock glquake is birght red, iirc.
fitzquake and it's children have the r_clearcolor but this means your fog has to exactly match (or near enough) the palette colour.
also, when faces are enabled or disabled, it's instantaneous and quite jarring, even if the area is nearly fogged in. bits of the map just pop in and out.
finally, not all engines handle fog the same way, especially regarding density. so in one engine, you might have it set so you can't (or only barely) see geometry popping up but another engine the density might only be half.

mostly what i've found it useful for is when working on a map that isn't very vis friendly (semi outdoors, for example) so that a quick vis doesn't really change all that much. when you've got 20k wpoly, setting visdist to even a huge number like 2048 can still help out a lot. 

Well VIS times are still long but the multiple threads is awesome :D Wish I had a better CPU.

btw since this thread has some explanation stuff going, can someone explain the uses for 'Skip'? 

Any skip textured face gets removed by the skip tool, pretty much. It's useful with some hacks involving water etc. Unless that wasn't what you meant. 

Skip use falls into two categoies. One use is to reduce visible surfaces and so improve framerates. You would do this if there are surfaces that are always just out of view of the player but which vis decides need to be rendered. VIS always(bugs aside) errs on the side of rendering borderline cases. It's quite hard to actually find useful places for this - surfaces that are just touching the skybox but would never be seen by the player unless they cheat and fly is the closest I can think of a common use case.

Using it on func_wall (or similar) entities gives a better use-case as they don't have the 'outer-face-culling' that the world does. If you look at a hollowed out room in the world, the outside faces are removed because the player can never see them (assuming the world is sealed). However, if you build a door which opens vertically, the sides of the door are never culled even if they are hidden by the doorframe at all times. This is understandable because in general the compiler doesn't know anything about where your door will move to. You can put skip on those surfaces that you know you will never reveal.

You can also do this with the back faces of a func_wall embellishment which you embed in one of the walls of your level. Taking this idea to the extremes gives an idea I've never seen attempted but might be worthwile:
You want to connect two arched doorways by a section of 'trisoup' natural rock, but you find that the intersection of the curves and the rocks is creating far too many cuts and complex geometry which will be a nightmare to vis.

You then try the following: convert the entire rock section connecting the two arches into a func_wall, using skip textures employed in two complimentary ways to help you out. Firstly you create a simplified box outside your rocks, constructed of skip textures in order to seal the leak you just created without costing any polygons. Secondly you convert all the outer surfaces of your new rock tunnel func_wall to skip textures since they are no longer culled automatically.

Like I say, it's a speculative idea I've never seen employed. It would surely cut down on VIS time in that area. It might reduce polycounts in the area as the arches and rocks no longer cut each other up. However the func_wall construction would no longer have true visibility calculations, it would be rendered all-or-nothing which may cause overdraw in the areas where some rock was previously culled, so the saving depends on how much cutting used to occur. You might also get flicker and hall-of-mirrors if the func_wall is too large, which sometimes makes the engine too 'conservative' in rendering them. Lighting func_walls is also harder.

So that's the framerate saving it offers. There are also a number of gimmicks you can use it for. It can be employed in a similar way to clip brushes, but with the added effect of blocking projectiles as well as the larger objects clip blocks. This can help monsters walk over broken ground, but it stops grenades dropping through which can look odd. You can use it to create 'glass' as well, although it is probably best to do that with a func_wall rather than a world brush - VIS treats skip as if you can't see through it, and so might cull the other side of the glass as out of sight if you fully seal the pane with a world brush. 

and so might cull the other side of the glass as out of sight if you fully seal the pane with a world brush.

not only that, but it would remove the faces between the frame and the window brush so that there would be a band of void running around the inner edge of the window frame.

i've been using skip routinely in the bluelit map i'm working on. those 45 degree trim brushes are all func_wall with skip behind. sadly, i have forgotten to skip the backside of the func_walls so i will need to go back over them all.

sometimes, however, it's good not to skip an area. for example, if you had a flat wall with a func_wall covering only a small portion of it, it would be better not to skip the area behind the func_wall because it would cause the remaining bits of the flat brush behind it to be split up into multiple faces.

You want to connect two arched doorways by a section of 'trisoup' natural rock, but you find that the intersection of the curves and the rocks is creating far too many cuts and complex geometry which will be a nightmare to vis.

yes, this also has the bonus of sometimes getting rid of troublesome clipping problems.
brush expansion depends on the brushes next to the one being extruded. this can sometimes make a neighbouring brush to mess up the extrusion leading to invisible walls or just plain bumpiness.
the brush expansion is handled separately on a func_wall. if it was absolutely necessary, you could split up your trisoup into individual func_walls but usually it's enough to simply convert a small portion. 

Thanks for the explanation guys :)

I think I can probably find a fair few places to use such a feature around fiddly details that are behind clip brushes. 

Interesting idea, using skip like caulk basically. 

um, however, isn't that borderline obsessive - how much vis time will it really save? Also, mh's engine runs even the craziest maps at very good frame rates, so this might be unnecessary as engines evolve and computers / gpus become more powerful. 

Well my full vis time is getting over the 3 hours mark (not that my machine is particularly brilliant) and the map is barely half finished...

Well, my fault for going for a big outdoor area I suppose. Next time I'll just make isolated rooms and teleport the player between them! :p