DaemonEngine
Add shader stage options for height scale and height offset
Our engine already supports scaling and offsetting an height map, but it currently only supports the shader-wide DarkPlaces' dpoffsetmapping syntax, which is not enabled by default, and unlike the DarkPlaces engine, the Dæmon engine truly supports stages and stage blending (and then multiple height maps), so we better set this option per stage, per height maps.
The reason why dpoffsetmapping has been implemented first because at the time I was debugging the height map code, we did not shipped any height map yet, and I used Xonotic assets as test bench.
Because of the engine not supporting per-stage scale/offset yet, our height maps are not straight copies of Xonotic ones, but pre-scaled, pre-offsetted copies, which loses a lot of precision (the difference is obviously visible) and also are truncated to the floor level (no bumps).
Having native Dæmon keywords and proper per-stage height scale and offset and supporting the exact same kind of height offset operations as Xonotic would allow us to ship stock copies of Xonotic heightmaps and benefit for more precision and more details.
This would also allow us to use Xonotic's fft-normalmap-to-heightmap tool on more normal maps to produce more height maps.
I'm also looking for opinions about naming things.
Right now the proposed syntax is:
textures/castle/brick
{
qer_editorImage textures/castle/brick
{
diffuseMap textures/castle/brick
normalHeightMap textures/castle/brick_nh
heightScale 6.1
heightOffsetType match8
heightOffset 161.7
}
}
It should be equivalent to Xonotic syntax:
textures/castle/brick
{
qer_editorImage textures/castle/brick
dpoffsetmapping - 6.1 match8 161.7
{
map textures/castle/brick
}
{
map $lightmap
rgbGen identity
tcGen lightmap
blendfunc filter
}
}
So I went for heightScale, heightOffsetType, heightOffset keywords. Other options could be relief* or depth*, but in fact we already have depthScale which reads an expression, depthScale is part of many expression-based options inherited from XreaL we don't make use of. We have the same problem with normalScale <X> <Y> <Z> that reads a vec3 and normalIntensity <Exp> that reads an expression. I'm not sure we can easily detect if the rest of a line is an expression or not before chosing how to parse such rest of line, so for now I chose to use different names and keep the old one for the expression thing.
