Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add shader stage options for height scale and height offset #1282

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

illwieckz
Copy link
Member

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.

@illwieckz illwieckz added A-Renderer T-Feature-Request Proposed new feature labels Sep 7, 2024
@illwieckz
Copy link
Member Author

illwieckz commented Sep 7, 2024

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.

@illwieckz illwieckz force-pushed the illwieckz/stage-height-options branch from 1ee1342 to 7f00631 Compare September 7, 2024 16:02
@slipher
Copy link
Member

slipher commented Sep 14, 2024

What's the meaning of heightOffsetType?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants