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

Wrong default colormap blend #289

Closed
illwieckz opened this issue Feb 11, 2020 · 2 comments
Closed

Wrong default colormap blend #289

illwieckz opened this issue Feb 11, 2020 · 2 comments

Comments

@illwieckz
Copy link
Member

illwieckz commented Feb 11, 2020

The bug is not new, but was hidden by the bug fixed in #277 (glsl/lightmapping: fix terrain alpha blending for collapsed materials).

This bug was already there before in vertex lighting mode.

This is how it must look:

wrong colormap blend

This is now it looks now on light map lighting mode:

wrong colormap blend

This is how it already looked like on vertex lighting mode before #277:

wrong colormap blend

This is how it looks like on vertex lighting mode if I apply the same buggy workaround that was applied in lightmap lighting mode before #277

wrong colormap blend

Don't mind the bizarre artifacts for now, that's another bug I have not yet investigated, but definitely another bug (looks to have been introduced between 0.50.0 and 0.51.1).

The bug we talk about always has been there, this is how the same map looked like on Unvanquished 0.6.0 and 0.50.0 in vertex lighting mode. That was already too much darky, but we also see our engine is now more darky with newer artifacts that was not there at first, that's probably another yet unknown bug:

wrong colormap blend

wrong colormap blend

So the bug fixed in lightmap glsl in #277 looks to have been a workaround for an old bug living in others glsl shaders.

This bug only occurs on some legacy materials. It's related to the various guesses the engine does to detect the right color blend to apply, the problem probably living in that test:

// if cgen isn't explicitly specified, use either identity or identitylighting
if ( stage->rgbGen == colorGen_t::CGEN_BAD )
{
if ( blendSrcBits == 0 || blendSrcBits == GLS_SRCBLEND_ONE || blendSrcBits == GLS_SRCBLEND_SRC_ALPHA )
{
stage->rgbGen = colorGen_t::CGEN_IDENTITY_LIGHTING;
}
else
{
stage->rgbGen = colorGen_t::CGEN_IDENTITY;
}
}

If stage->rgbGen is always set to colorGen_t::CGEN_IDENTITY, both lightmap lighting and vertex lighting looks ok (but then it breaks some other textures that legitimately relied on this test to set the other type).

illwieckz added a commit to illwieckz/Daemon that referenced this issue Feb 13, 2020
illwieckz added a commit to illwieckz/Daemon that referenced this issue Feb 13, 2020
@slipher
Copy link
Member

slipher commented Feb 13, 2020

Glorious. We can create a game which can be played without /r_gamma 2 😝

@illwieckz
Copy link
Member Author

illwieckz commented Feb 13, 2020

Note that this bug made the map darker than current engine with /r_gamma 1:

Current engine with gamma 1 and bug being awaken from a 14 years sleep by patch enabling alphagen in diffuse code path:

broken engine

Current engine with gamma 1, (stock 0.51.1 or master with fixed bug):

stock engine

Current engine with gamma 1, colorspace correction and dithering to reduce color banding a bit:

next-gen engine

This map was made for Tremulous in 2007, this is the 2007 build by KOsAD, not some extensive rebuild I did (lightmap file dates are 2007-03-12, so those lightmaps will be 13 years old in one month).

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

No branches or pull requests

2 participants