Water, Air, Life.
Tricks for outdoors settings

Water
Running water
Water is nice, waterfalls are nice... The problem is: waterfalls are not water.Sounds dumb? Yet think about that: what turns a brush into water is only the fact its faces have a texture whose name starts with "*". On the other hand, waterfalls should display an animated texture representing water flowing down, and the prefix for animated texture names is "+0", "+1", etc.
Of course the same texture name cannot be prefixed by "*" and "+" at the same time, which is why water surface can't be animated like it's pouring, but can only feature the default hard-coded warping effect for liquids. Too bad!
But we're lucky! The world acclaimed Ericw tools, and more specifically his qbsp, allow invisible water brushes thanks to the very special *waterskip texture.
*slimeskip and *lavaskip also exist, as a matter of fact, and all of them can be found in the indispensable skip textures kit.
Now things are easy:
- Make an invisible water brush with the *waterskip texture.
- Duplicate it at the same place (with Ctrl+D in TrenchBroom), turn the duplicate into a func_illusionary brush, and decorate it with an animated waterfall texture.
- That's it! Now the player can see pouring water AND pass through it to enter an actual water volume.
Et voilà!
Sounding water
Water textures not only turn brushes into water and trigger the hard coded visual warping effect (when it's not the invisible *waterskip of course). They also make the compiler automatically add ambient water sounds to enhance the immersion (who said "pun"?). That's really a cool feature!Well, that's sometimes a very annoying feature to be honest. For better or for worse, how sounds propagate is strongly connected to the vis calculation. Basically the rule is: if you can see it, you can hear it. Well, even worse in fact; the real rule is really convoluted: if you are standing within a virtual 3D partition of the world which is visually connected (according to vis rules) to another virtual 3D partition of the world touching water, then you can hear it.
And sometimes that just means the player can hear the water gurgling from veeeery far away, no matter they can't actually see the water and the sound totally feels out of place where they are.
An in-depth understanding on how vis partitions space and how to perform map optimizations for that is required to get rid of the nuisance, which is all the more susceptible to happen when designing outdoor areas which are where the player is more prone to seeing things in far distance. For those lacking the aforementioned skills like me, vis' -noambientwater command line option is there to save the day and remove all the automatic ambient sounds added for waters. Then you can manually add sound_ambient entities just where you want, and their sound shouldn't propagate everywhere without attenuation anymore.
Similar options exist for slime, lava or sky sounds as well (yes, sky brushes also emit a windy sound to enhance the "outdoor feeling").
Frozen water
That may sound weird from someone working on a Portal Of Praevus sequel, but it's only a few days ago that I heard of obj_ice, the only "obj_" brush entity unlikely hidden among the dozens of "obj_" point entities. Looks like Raven guys overlooked it as well because it's never user in any of the original game maps. Despite its all snowy/icy theme, Portal Of Praevus ignores it as well. The only occurrence I was able to find is somewhere in the Black Tower map of the classic Fortress of Four Doors mod.obj_ice has to be mentioned, tho, because it offers a way to make optionally translucent brushes able to take damage and break like a breakable_brush and most importantly it features an exclusive slippery effect. It inevitably reminds of the slippery ice sectors in Heretic and Hexen, and it's a nice touch that they brought it in Hexen II as well.
Air
Skyboxes and fog
Hexen II being mainly a big Quake mod, most of what applies to Quake applies to Hexen II as well. That of course includes modern era features unavailable at the times the games were made like skyboxes and fog. Dumptruck_ds made an excellent video tutorial about them. Also check all his other mapping tutorial videos. Although made for Quake, really few of them are actually Quake-specific and couldn't apply to Hexen II too. Most will just fit.Lazy lighting
As stressed in my introductory paragraph, one of the main mood differences between Quake and Hexen II is claustrophobia vs open air. Claustrophobia means scarce natural light, hence the need to use tons of torches, wall lights, light wells, ambience lights, etc. Just to give an idea, in Azure Agony (Quake's largest map) out of 404 entities (of all types, including monsters, pick ups, doors, etc.) 141 of them are lights! That's really huge and one can easily imagine that when making a Quake map a big part of the time must be dedicated just to the lighting.By chance some new compilation tricks allow to reduce the load nowadays, thanks to Ericw tools again, and they fit especially well with outdoors.
-
Indoors need all the light casting gadgets I enumerated above, but none of that is required when an open air landscape can just bath into the sun light! It's the only light source required. It automagically applies in any area topped with sky brushes. You can adjust the light intensity, angle, color, etc. thanks to the "_sunlight" properties in the worldspan entity (see the light.exe documentation). The easiest way to make a sun is simply to put a normal light entity somewhere targetting an info_null (to set up an angle) and having its "_sun" property set to 1.
Additional suns can be added as secondary ambient light sources for subtle effects thanks to the "_sunlight2" and "_sunlight3" properties in worldspan.
-
In real life, surfaces reflect light. This can be mimicked thanks to worldspan's "_bounce" properties. Please note that when the feature is activated, light will bounce from surface to surface which will result in a more realistic but also brighter map. So the rule is: choose whether light will bounce or not before starting to light you map because it will sensibly affect the overall luminosity and if you change afterwards you'll have to adjust all your lights again.
-
In real life, even when the sun is bright and shadows are sharp, areas in shadows are never pitch black. But here we're not talking about real life but about a computer algorithm calculating lighting for a 3D world in a computer game. That's all fake and doesn't follow the real life rules. So sadly shadows will be unlikely pitch black by default when the light source is intense. Bouncing can help that. The "_minlight" property can help too, but be extremely careful with it. You can put that property on any brush entity and then, no matter how much light it actually receives, no part of it will be darker that the minimum value set by this property. It may result in a very uniform and uncanny ouctome, and that's why Quake mappers usually disregard it. Still, if used with care it may help some situations and avoid too dark areas.
Corridor in Church Of The Unholy, default min light 50 which is dark but not totally black either.
Even the darkest parts of the map still have a small residual luminosity.
Also note how Hexen II maps usually don't make such a careful use of light to convey atmosphere.
In my Church Of The Unholy Quake project I used "_minlight" with a value of 50 applied to worldspan (so to the whole map, which was very risky). Surprisingly enough, it turned out working pretty well because while theoretically applying to the whole map, it actually impacted only the dark underground parts thanks to the outdoor parts being already lighten by the "_sunlight2" settings. Don't forget to mix the two tricks otherwise "_minlight" only will cause too dark outdoor shadows if adjusted on indoors or too bright indoors if adjusted on outdoor shadows (even if the latter can be somewhat tricked by putting strong lights indoors and making the bright indoor shadows darker by contrast... but that's patch-up job).
light's "-addmin" option can also help the use of "_minlight".
- Textures can emit light. Put a light entity somewhere and set its "_surface" property to any texture name. This light entity itself won't be taken into account, instead all the brush faces within the map having the texture in question will now cast light. One single light to rule them all, so to speak. It can be an easy way to save a lot of work and offer a consistent light handling all over the whole map. What happens behind the scenes is: lights are added every 128 units all over the concerned surfaces, 2 units away from them.
But let's look on the bright side of it: it means there is less pressure on Hexen II mappers' shoulders for premium lighting and you won't be bashed if you just do a decent job there. After all, Hexen II maps have many other ways of arousing enjoyment: colorful environments, lavish textures, cool puzzles, etc.
So a bit of laziness may be forgiven as far as lighting is concerned... even if a map reaching Quake standards will all the more stand out, of course!
Once again, Dumptruck_ds has excellent video tutorials about lighting to look deeper into that subject... and many others!
Life
Vegetation
That's another funny trick coming from the Quake world, which is tragically lacking any decorative entities like chests, benches, statues... and all kinds of greenery we're used to in Hexen II. So why not trying to mimic plants with brushes, after all? That may sound completely dumb, yet it's amazing how you can easily make something surprisingly good in no time. The feature image on top of this page demonstrates this with the water plants in the foreground, but the outcome can be even more striking:
Incredible but true: those nice palm trees in Quake mod Dwell are brushes!
- Each plant is made out of 2 flat brushes to feel 3D (just 1 brush would feel like it's a sprite).
- I chose to make the brushes func_illusionary entities to save the player from awkwardly bumping into them.
- Each brush is textured with the special SKIP texture (also found in the skip textures kit mentioned above) except for one side having a vegetal fence texture.
- Each brush has the "_mirrorinside" property set to 1. That means the brush faces are drawn on both sides (inner and outer), which of course only makes sense for see-through brushes (which is the case here thanks to the SKIP texture). Here the only face actually drawn is the one with the fence texture. The "plant" shows in-game as 2 intersecting zero-width 2-sided planes.
- And that's it! Believe it or not but it perfectly does the trick. Dwell's palm trees are nothing more than the same at a bigger scale.
Want to ask for clarification, report an issue with this trick or propose another one? Drop me an email
If you use the trick please credit me and put a link to this website.
