Ferdinand List - Blog

[id tech 3] Dynamic shadows

2022-08-04T00:00:00Z

I stumbled across this old quake3world thread by user $NulL claiming to have achieved an implementation of dynamic shadows in q3. Since the post is from 2005 and links are of course dead, I went on a hunt to see if I could still find it somehow. Thankfully, as it turned out, sst13 happened to have a copy of the file that he could provide!

I went ahead and made a new video of it.

How it works §

The movement of the shadow volume is produced by having it in the same transitioned func_ as the geometry itself.

A shader is used to darken the geomtry hit by the shadow volume. A high sort value of 12 is used to make sure the shadow draws in the correct order on all kinds of shaders.

textures/null_test/a_shadow_dark
{
	qer_editorimage textures/null_test/shadow.tga
	surfaceparm nonsolid
	surfaceparm nolightmap
	surfaceparm trans
	surfaceparm nomarks
	surfaceparm nodlight
	sort 12
	q3map_cloneshader textures/null_test/a_shadow_light
	{
		map textures/null_test/shadow_d.tga
		blendfunc gl_dst_color gl_src_color
	}
}

From the original post, as stated by $NulL:

The outward facing polygons of the shadow volume darken whats already in the framebuffer.
The inward facing ones brighten it up again.
So when you can see both inward and outward facing polys they cancel each other out, but when only the outward facing poly is visiable the area is shadowed.
(You should never directly see an inward facing polygon)
There are some major limitations though. Being depth pass shadows you dont ever want a player's view to pass into a shadow volume.
There will be a maximum number of shadow polys rendered on top of each other before it fails and the shadow volumes become visable.

Apparently there has been an attempt at creating a smooth shadow version as well that got lost in time:

Right, I got a fading one kinda working. I used a gradiant texture instead of alpha blending it. But I carnt get around the values not being able to cancel each other out, so it looks ok from the side or top but from anywhere else the volumes become too visible.

Download §

test_shadow.zip [Q3, 240KB]

[id tech 3] deformVertexes normal

2022-08-01T00:00:00Z

While working on the water shading sample map I had an issue with the shader declaration deformVertexes normal causing the engine to complain about unkown numeric shader parameters.

I double checked with the shader manual which notes the following params for deformVertexes normal:

deformVertexes normal <div> <func> <base> <amplitude> <freq>

Not being able to resolve the issue I went on a hunt online to see if I could find any additional info on the matter. I ended up in the quake 3 source on github, surprised to see different params listed for the usage of deformVertex normal:

deformVertexes normal <frequency> <amplitude>

I adjusted the params in my shader and the warning was gone. However, it was still not quite behaving the way the params suggest. I went ahead and asked nigrum/garux, the project founder of netradiant-custom, if he had any idea about it and he pointed out to me that he had made fixes to q3map2 as well as corrections to the shader manual resolving the problem. The up to date params are in the shader manual that ships with netradiant-custom and will apparently only apply to the version of q3map2 that is included with it.

deformVertexes normal <amplitude> <frequency>

[id tech 3] Water shading

2022-07-24T00:00:00Z

I've known for a while that Hipshot has used q3map2's alpha blending features in order to fade out the edges of water volume in order to make the transition to lit surfaces more subtle and less contrasty (for instance on solitude). However, I never actually got to try it myself so I made this little sample map to get an overview of some water shading methods in id tech 3.

Post contents

Preface §

Origin of the investigation was Hipshot's water shader that consists of two grainy alpha channel textures blended on top of each other with a slight turb effect. Key here is the alphaGen vertex directive that makes the shader's alpha channel depend on q3map2 alpha mod shaders placed on the water volume's vertices.

// hipshot's water shader for alpha blending to zero

textures/ct_testWaterBlend/water_01
{
	qer_editorimage textures/ct_testWaterBlend/hipshot_water.tga
	q3map_globaltexture
	surfaceparm trans
	surfaceparm nonsolid
	surfaceparm nomarks
	surfaceparm nolightmap
	nopicmip
	noMipMaps
	cull none
	{
		map textures/ct_testWaterBlend/hipshot_water.tga
		blendFunc GL_SRC_ALPHA GL_ONE_MINUS_SRC_ALPHA
		rgbGen identity
		alphaGen vertex	
		tcmod scale 1 1			
		tcMod turb 0 .15 0 .015	
	}	
	{
		map textures/ct_testWaterBlend/hipshot_water2.tga
		blendFunc GL_SRC_ALPHA GL_ONE_MINUS_SRC_ALPHA
		rgbGen identity
		alphaGen vertex	
		tcmod scale 1 1			
		tcMod turb 0 -.15 0 -.015				
	}	
}

Read more about alphaMod shaders here.
In case you are missing the alphaMod shaders, you can download them here. For reference, I included a sample shader below.

// alpha fade shader
// (c) 2004 randy reddig
// http://www.shaderlab.com
// distribution, in part or in whole, in any medium, permitted

textures/common/alpha_100
{
	qer_trans 0.5
	q3map_alphaMod volume
	q3map_alphaMod scale 1.0
	surfaceparm nodraw
	surfaceparm nonsolid
	surfaceparm trans
}

The alphaMod shaders are placed on small brush poles that get aligned with the vertices of the water volume to be alpha blended. Gathering the water volume brushes as well as the alphaMod shader brushes in a func_group will limit the blending effect to that particular group. See the sample map at the bottom of the page as an example.

Alpha blending the edges of water volumes §

As a result of alpha blending the water volume edges, you receive a smooth transition to the neighboring materials. In this example, the water shader fades to zero. However any alpha channel intensity is possible to use.

Additional tests §

Below you can see additional tests that I executed.

Tests include:

using fog inside water volumes
using faint level wide fog along with water fog
using alpha blending to fade water volumes to zero at the edges
using solid color alpha blended layers on top of water volumes
using envmaps on water volumes
various combinations of the above

The shader including a solid color stage can be an option for cases where you are already using a thicker level wide fog and want to have your water a little more diffuse without producing fog conflicts.

Here is the complete modification of hipshot's water shader including solid color stage and envmap stage.

// hipshot's water shader for alpha blending to zero
// with a solid color layer and an envmap

textures/ct_testWaterBlend/water_03
{
	qer_editorimage textures/ct_testWaterBlend/hipshot_water.tga
	q3map_globaltexture
	surfaceparm trans
	surfaceparm nonsolid
	surfaceparm nomarks
	surfaceparm nolightmap
	nopicmip
	noMipMaps
	cull none
	{
		map textures/ct_testWaterBlend/hipshot_water.tga
		blendFunc GL_SRC_ALPHA GL_ONE_MINUS_SRC_ALPHA
		rgbGen identity
		alphaGen vertex	
		tcmod scale 1 1			
		tcMod turb 0 .15 0 .015	
	}	
	{
		map textures/ct_testWaterBlend/hipshot_water2.tga
		blendFunc GL_SRC_ALPHA GL_ONE_MINUS_SRC_ALPHA
		rgbGen identity
		alphaGen vertex	
		tcmod scale 1 1			
		tcMod turb 0 -.15 0 -.015				
	}	
	{
		map textures/ct_testWaterBlend/waterColor_02_50.tga
		blendFunc GL_SRC_ALPHA GL_ONE_MINUS_SRC_ALPHA
		rgbGen identity
		alphaGen vertex
	}		
	{
		map textures/ct_testWaterBlend/waterFX_01.tga
		rgbGen identity
		tcGen environment 
		blendFunc GL_SRC_ALPHA GL_ONE_MINUS_SRC_ALPHA
		alphaGen vertex	
		tcmod scale 0.5 0.5
	}	
}

A notable experiment to me is using an alpha channel controled solid color envmap. While the envmap image itself is just a solid light grey, the alpha channel is a ripple kind b/w texture as seen below. This method allows for controling the envmap color separately from the opacity.

Combining level wide fog and water fog §

As a part of this sample map I wanted to reinvestigate on the issue of using multiple fog volumes in a map. While combining two thick fog volumes produces rendering errors as seen in image 1, using a faint level wide fog along with a thick water fog is not actually problematic as seen in image 3. I am a fan of using thin level wide fog as it eases the contrast of the lightmap just a little and can be used to give the overall lighting a subtle tint. Comparing images 2 and 3 you can see that while in image 2 there are pitch black areas with actual information loss, in image 3 these areas get pulled up just a tiny bit revealing the underlaying geometry. Additionally, shadows in image 3 appear with a slight blue tint instead of just greyscale.

Working with envmaps (update 2022-07-29) §

On a real water surface you would normally be able to observe a reflection of the environment, continuously distorted by the water's movement. The tool we have in id tech 3 to simulate this effect is using an tcgen environment shader stage, commonly referred to as envmap. The challenge here however is to bring in the element of distortion and not make the water surface look like a mirror.
I have extended the sample .map with a row of examples on how envmaps could be used, ranging from tesselation of flat surfaces with q3map2's tessSize over different deformVertex approaches and using actual tesselated deformed meshes created in blender in combination with deformVertex move and tcmod modifications of the envmap.

As a conclusion I would say that the most satisfying results are definitely produced by applying your water shader to a tesselated deformed mesh in combination with deformVertex move or tcmod turb on the envmap stage. While both approaches work, deformVertex move may actually not be feasible geometrically in some scenarios as the entire mesh will actually appear moving. In these cases using a turb, maybe in combination with a slight scroll or stretch, on the envmap is a fine compromise.

Worth mentioning as well is the approach of using deformVertex normal in order to produce an interesting simulated reflection. While the examples included in the sample map use a low tessSize of 16, good compromise in terms of performance may be found with a little higher tessSize. Overall these methods of shading water will take a hit on your tris count if used extensively. While I do not have any extensive details on the matter, using the mesh without the forceMeta flag, should keep it cheap in terms of performance.

The tesselated and deformed mesh with r_showtris 1

Water shader with deformVertex move used on mesh

Water shader with tcmod turb on the envmap used on mesh

Here is the complete turb shader used on the mesh, inclding alpha blended dirt stages.


// hipshot's water shader for alpha blending to zero
// with an envmap with tcmod turb
// for use on a tesselated mesh
textures/ct_testWaterBlend/water_tess_01-turb
{
	qer_editorimage textures/ct_testWaterBlend/hipshot_water.tga
	q3map_globaltexture
	surfaceparm trans
	surfaceparm nonsolid
	surfaceparm nomarks
	surfaceparm nolightmap
	nopicmip
	noMipMaps
	cull none
	deformVertexes wave 1000 sin -2 2 0 0.2 
	{
		map textures/ct_testWaterBlend/hipshot_water.tga
		blendFunc GL_SRC_ALPHA GL_ONE_MINUS_SRC_ALPHA
		rgbGen identity
		alphaGen vertex	
		tcmod scale 1 1			
		tcMod turb 0 .15 0 .015	
	}	
	{
		map textures/ct_testWaterBlend/hipshot_water2.tga
		blendFunc GL_SRC_ALPHA GL_ONE_MINUS_SRC_ALPHA
		rgbGen identity
		alphaGen vertex	
		tcmod scale 1 1			
		tcMod turb 0 -.15 0 -.015				
	}	
	{
		map textures/ct_testWaterBlend/waterFX_02-green.tga
		rgbGen identity
		tcGen environment 
		blendFunc GL_SRC_ALPHA GL_ONE_MINUS_SRC_ALPHA
		alphaGen vertex	
		tcmod scale 2 2
		tcMod turb 0 .025 0 .15	
	}	
}

If you want to reside to a conventional envmap on brushes, you might want to check out tessSize whatsoever as the way q3map2 triangulates the geometry may affect the appearance of the envmap.

Lastly, one thing I did in fact not know was that alphaMod brushes can be used in a linear way instead of just placing them on single vertices. Additionally, if you want to alpha blend an imported mesh, you cannot have your alphaMod brushes in a func_group as models cannot be part of that group and thus the blending declarative will have no effect on any geometry. Leave everything as part of the worldspawn entity.

Download §

This map's water shader and sky shader, as well as the corresponding materials were originally created by Hipshot. The .map source file is included with the pk3.
I included the mesh .obj used for the envmap tests with the pk3. Also included is the psd file for the envmap. Special thanks to quBit for giving me a lot of input on shading possiblities. Thanks to nigrum/garux for netradiant custom and answering a lot of my questions.

New portfolio site launched

2022-07-22T00:00:00Z

For a a fear years now I have been trying different approaches to operating a low maintenance effort portfolio site in a sustainable and archivable way.

This is my latest approach relying on the static site generator 11ty and gitlab ci/cd for deployment. 11ty allows for easy content management with re-usable templates relying on templating languages like Markdown or Nunjucks while incorporating the powers of CSS and Javascript. Site and content are managed in a git repository on gitlab and re-deploy automatically to my webserver when a commit is pushed to the main branch.
Since the output of 11ty is just plain static html and css, the site can be easily archived while still offering me a reasonably dynamic interface for content management.

The main purpose of this project is documenting my architecture projects. However, since I get asked about my level design projects every once in a while, I decided to give them an own subsite. Then there is the blog you are reading which shall function more as a personal archive rather than something people may actively follow.

Masking gitlab ci/cd env variables using base64

2022-07-22T00:00:00Z

Gitlab has requirements with regards to special chars and length for environment variables to be maskable. These can be circumvented using base64 encoding which containss no special chars. Store the env variable encoded and masked and decode it during the execution of your gitlab pipeline.

Example: private ssh key §

Converting to base64:

    cat id_rsa_gitlab_cicd | base64 -w0 > id_rsa_gitlab_cicd_base64

Converting back to clear text inside your gitlab pipeline:

  script:
  - echo "Deploying!"
  - echo "${SSH_PRIVATE_KEY}" | base64 -d > id_rsa_gitlab_cicd_decoded

Links §

Deploy an 11ty site using gitlab ci/cd pipelines

2022-07-22T00:00:00Z

Just a link drop about deploying a site built with 11ty using gitlab CI/CD pipelines

The language of arena FPS level design

2017-03-05T00:00:00Z

This is an archived post originally published on plusforward in 2017.

Post contents

What Is The Problem? §

Studying architecture, I've spent a great portion of the recent years thinking about what makes environments sufficient to their requirements or what makes them whole. At the same time, arena fps mapping is something that has always been in the back of my mind. The conditions are kind of similar for creating real spaces and virtual levels. There is a context for these environments, and certain geometries create forces that influence "users" in their actions. Sometimes the designers introduce forces they could not predict. Just like architecture, arena fps map making has never been fully figured out and certainly never will as long as we rely on individual intellects for telling us how maps should be made. Part of that is surely because of the fact that the Quake games which kicked off competitive arena fps, are older than the profession of the level designer as we know it today. Quake mapping has never been systematized although there have been attempts (which again nobody had the competencies to verify). I'm not claiming I have these competencies, my judgement is just as limited as anyone eles'.

Approaching The Problem §

Now where am I going with this? Obviously, map design in arena fps is governed by the respective game's mechanics, and apart from that by the player skill. If we consider the case of a professional gamer who can perfectly use all of the game's mechanics, map design just is a direct response to the game's mechanics. A game's mechanics however, aren't only developer made. Developers suffer the same problem as other designers: They sometimes fail to comprehend the consequences of their actions (which I guess is human). By making a game accessible to a playerbase, it is going to be tested and exploited. New dependencies arise by how the players interact with the framework that the game is and also by how they interact with each other. This effect is not immediate, it's a process driven by the contribution(s) of many. To get back to the core, map design, depends on a game's mechanics, which are not only driven by the developers but also by the players and the interaction between them. It is a node in the network of dependencies that make a good arena fps. I think it is pretty safe to say that in order to make a good level, one is obligated to understand the game's mechanics as described above.

My Proposal §

How to go about that though!? In our competetive map pools, we usually have five to seven maps, all of which are essentially unique. However, all of them seem to work which shows that the issue I'm discussing here is a complex one. My research in the context of architecture has made me stumble across Christopher Alexander's concept of pattern languages. To not get too theoretical here, let's call this a language or network in which the words or nodes are essentially descriptions of situations and actions present in living environments. All of the nodes are linked to each other in a specific way so that each node needs certain sub nodes to be complemented but at the same time complements other nodes "above it".

The very idea is to help people understand problem structures and to give them an instruction on how to resolve them. This is all rooted in the idea of solving a problem by understanding a problem; which in my eyes is exactly what has to happen in respect to level design in arena fps.

How many more decent duel maps could we get if every designer knew about the design relevant nodes, "initial spawns", "inital control distribution", "playing out of control", "control shifts", "respawns", "making noise", "early game", "late game", "high ground advantage", "fake rocket jump", "armor distribution" to just name a few potential nodes of this virtual network that describes arena fps design. Enabling every map maker to understand the connection between those terms, visually comprehending what connections each one of them has, would be a first step towards creating an objective understanding of making suitable levels for arena fps.

If a single person however, was able to set up a complete "whole" network like this then surely we'd have it already. Fact is though, that pretty much no one, neither the best designers, nor the best pro players are able to put their thoughts down in a way that gives us a whole perspective like this. In my opinion, this can only be a collaborative community task.

I'd like to kick off a web interface to establish this and combine it with my architecture research next term. Please feel invited to join the discussion on this topic.

Current pool of patterns (to be updated) §

Unsorted

initial spawns
inital control distribution
playing out of control
control shifts
respawns
making noise
early game
late game
high ground advantage
fake rocket jump
armor distribution

On the dependencies of major items

Shortest Item Connection
Safest Item Connection
Narrow Threshold (choke points that don't give a lot of room to dodge)
Change in Elevation (including the different forces introduced by jumppads, teles, rocket jumping)
Control Shifts
Player Delays
Item Delays

On the geometry around major items

Defendable Positions
Vulnerable Positions
Items on a Platform
Items on a Pillar
Items on Even Ground
Items in Dead Ends
Items in Alcoves
Items under Drop Downs
Items at the top of a staircase
Floating Items
Items in Water
Moving to an Item spawn
Visibility of the Item Spawn(long range vulnerability e.g. rail)
Narrowness of an Item Spawn (splash vulnerability e.g. rockets)
Close Player Respawns