partial void effect on station15 tree model

[illwieckz]

See that weird void effect at the tip of the conifer branch:

It must look like this:

Note that the bug seems to occur on the collision with the plant leaf model. For information, there is also an alphagen brush in source map at this place:

This bug looks somewhat related to that bug noticed in wolf:et map (at least for the tree):
Unvanquished/Unvanquished#799 (comment)

[illwieckz]

@gimhael the somwhat fix for #118 also somewhat fixes this (the texture is right but lighting is wrong):

It also somewhat fixes Unvanquished/Unvanquished#799 bug at least for the tree part:

But that variant of the bug is still remaining:

It was noticed in Unvanquished/Unvanquished#799 (see comment) that the wolf:et bug was introduced in 6cb4dcc but the source tree was buildable starting with commit 97cbb46 (those are translated commit ids in Daemon repository after engine split, see the other thread for commits ids on Unvanquished repository).

[illwieckz]

For testing purpose a snapshot of for-0.51.0 assets (including station15 map) can be fetched this way:

wget -O- http://gg.illwieckz.net/dl/unvanquished/dev/UnvanquishedAssets.get | xargs wget

[illwieckz]

For testing purpose one can load wolf:et's railgun map this way:

• Download official etlegacy assets from an official mirror (you can use pimi):

pimi.sh etmain

• Add some compatibility layer (no legal issue, it's just doing symlinks, downloading empty dpks containing DEPS file only and downloading a spawn layout so the game does not end at startup):

mkdir -p ~/.local/share/unvanquished/pkg/etmain
mkdir -p ~/.local/share/unvanquished/game/layouts/railgun
ln -s ~/.etlegacy/etmain/pak0.pk3 ~/.local/share/unvanquished/pkg/etmain/pak0_0.dpk
ln -s ~/.etlegacy/etmain/pak1.pk3 ~/.local/share/unvanquished/pkg/etmain/pak1_0.dpk
ln -s ~/.etlegacy/etmain/pak2.pk3 ~/.local/share/unvanquished/pkg/etmain/pak2_0.dpk
wget -O ~/.local/share/unvanquished/pkg/etmain/res-etmain_0.dpk http://dl.illwieckz.net/b/unvanquished/extra/foreign-maps/etmain/pkg/etmain/res-etmain_0.pk3
wget -O ~/.local/share/unvanquished/pkg/etmain/map-railgun_0.dpk http://dl.illwieckz.net/b/unvanquished/extra/foreign-maps/etmain/pkg/etmain/map-railgun_0.pk3
wget -O ~/.local/share/unvanquished/game/layouts/railgun/spawn.dat http://dl.illwieckz.net/b/unvanquished/extra/foreign-maps/etmain/game/layouts/railgun/spawn.dat

• Load the railgun map with the cheat to never end on missing spawn:

daemon -pakpath ~/.local/share/unvanquished/pkg/etmain/ +set g_neverend 1 +devmap railgun

• Load the railgun map with the spawn layout:

daemon -pakpath ~/.local/share/unvanquished/pkg/etmain/ +devmap railgun spawn

[illwieckz]

note that the unattended side-effect "somewhat fix" previously talked about is not there anymore, bug was brought back when lighting was fixed, i.e the complete fix for the other bug left this one unmodified despite some work in progress had some effect on this.

[ghost]

The tree thing seems still true as of 0.52.1:

image deleted to avoid wasting people's bandwidth

[illwieckz]

Your screenshot doesn't depict the bug, it is worked around by r_clear being enabled, well, it is less obvious with r_clear being enabled, and the screenshot is too low resolution to notice the bug precisely, the bug only affects the tip of one branch, you'll need to zoom-in more.

Anyway the bug is still there

[ghost]

Then I'm failing to understand the problem.

[illwieckz]

This may help: https://imgsli.com/ODgwMjI

[ghost]

please upload images instead of linking them, for future reviewers. Also, which side should be the good one?

[illwieckz]

Those are the images in first post, just reuploaded with a slider.

[illwieckz]

/devmap station15
/setviewpos 349 -1031 -143 159 32

This part must not be pitch black, the fact it's renderer pitch black is because it's worked around with r_clear 1, otherwise nothing would be painted at all.

If you /set r_clear 0 and move a bit, you'll see the void.

[illwieckz]

This is probably related to the fact those two models are colliding.

[slipher]

I believe this is caused by a mismatch between the depth shader and the main shader stage. The depth shader assumes that the alpha for alphaFunc GE128 should come from the image. But the main shader takes the alpha from the vertex data because the tree is using vertex lighting.

[VReaperV]

I believe this is caused by a mismatch between the depth shader and the main shader stage. The depth shader assumes that the alpha for alphaFunc GE128 should come from the image. But the main shader takes the alpha from the vertex data because the tree is using vertex lighting.

This does not seem to be the case. Both use u_ColorModulate = [1.00, 1.00, 1.00, 1.00], so it takes the vertex colour and multiplies it by the diffuse. Both have some alpha values set.

[VReaperV]

Depth buffer after depth pass on the tree:

A lot of the vertexes have very low colour values, <= 10. Some others have colour values up to about 60, which is probably where the discrepancy comes from, since they're just multiplied by the diffuse.

Here's the colour buffer after rendering this tree, with colour values normalized in range of [0.0, 0.00390625]:

[VReaperV]

So it's probably a map/shader bug.

[illwieckz]

Was it an answer for the bad vertex lighting:

• Bad vertex lighting with station15 tree Unvanquished/Unvanquished#3179

Or for the part of the tree not being rendered?

[slipher]

I could be wrong about the specifics of how the depth shader is mismatched. But disabling depth pass with #1412 fixes the issue

[VReaperV]

Or for the part of the tree not being rendered?

Point is, nothing's not being rendered. It looks black because the resulting colour is very close to 0.

[VReaperV]

So either the original issue was fixed at some point, or there was no void there in the first place.

[slipher]

It looks black because the resulting colour is very close to 0.

That's not it. The bug is nothing being rendered at all in some pixels. It can be clearly seen if you turn off r_clear; if you don't see it maybe it doesn't happen on your machine.

[VReaperV]

Ohh, I found where that is happening now. Apparently it's like one small part of a branch that's affected.

[illwieckz]

Yes, only a small part of the branch, the part colliding with the other plant.

[illwieckz]

Sometime I do believe we may have some r_clearColor cvar to debug such thing.

[VReaperV]

Ah, found the issue now.

[VReaperV]

LightMapping shader multiplies with the vertex colour first, and then does the u_AlphaThreshold check:

Daemon/src/engine/renderer/glsl_source/lightMapping_fp.glsl

Lines 102 to 108 in 559e2df

	diffuse *= var_Color;
	if(abs(diffuse.a + u_AlphaThreshold) <= 1.0)
	{
	discard;
	return;
	}

While the generic shader, which is used by the depth pre-pass, does the u_AlphaThreshold check first, and then does the multiply:

Daemon/src/engine/renderer/glsl_source/generic_fp.glsl

Lines 64 to 76 in 559e2df

	if( abs(color.a + u_AlphaThreshold) <= 1.0 )
	{
	discard;
	return;
	}
	#if defined(USE_DEPTH_FADE)
	float depth = texture2D(u_DepthMap, gl_FragCoord.xy / r_FBufSize).x;
	float fadeDepth = 0.5 * var_FadeDepth.x / var_FadeDepth.y + 0.5;
	color.a *= smoothstep(gl_FragCoord.z, fadeDepth, depth);
	#endif
	color *= var_Color;

[illwieckz]

LightMapping shader multiplies with the vertex colour first, and then does the u_AlphaThreshold check

Maybe that's wanted for terrain blending?

[VReaperV]

Maybe that's wanted for terrain blending?

I suppose so. I think just doing the multiplication first in generic shader should fix this issue.