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

Fix dynamic lights intensity, cleanup #1425

Open
wants to merge 7 commits into
base: for-0.56.0/sync
Choose a base branch
from

Conversation

VReaperV
Copy link
Contributor

@VReaperV VReaperV commented Nov 9, 2024

Cgame-side pr: Unvanquished/Unvanquished#3184

  • NUKED the weird 4x dynamic light scaling
  • NUKED the weird r_lightScale cvar, which is used for dynamic lights, but it's a cheat cvar and always set to 2.0, and essentially only used for dynamic lights spawned from movers
  • NUKED RE_AddDynamicLightToSceneQ3A() and renamed RE_AddDynamicLightToSceneET() to RE_AddDynamicLightToScene() because they're essentially the same
  • NUKED now unused trap_R_AddAdditiveLightToScene()
  • NUKED light intensity/scale, which was only used to scale the light's colour, just multiply the colour earlier on instead
  • Fixed some incorrect memory read before bounds check

Fixes #61:
hq-beta28:
Before:
unvanquished_2024-11-09_184524_000
After:
unvanquished_2024-11-09_184725_000

tremtest:
Before:
unvanquished_2024-11-09_184614_000
After:
unvanquished_2024-11-09_184754_000

This was a cheat cvar used for dynamic lights that have no intensity set, and set to 2.0 for absolutely no reason whatsoever.
…ET() to RE_AddDynamicLightToScene()

These were largely doing the same thing, use just one function instead.
@slipher
Copy link
Member

slipher commented Nov 10, 2024

Why don't we nuke the intensity argument? It seems to be redundant with just changing the r/g/b values.

This has largely the same functionality as trap_R_AddLightToScene().
@VReaperV VReaperV force-pushed the reaper/fix-dynamic-lights-intensity/sync branch from b628f0a to 0670349 Compare November 10, 2024 08:26
@VReaperV
Copy link
Contributor Author

Why don't we nuke the intensity argument? It seems to be redundant with just changing the r/g/b values.

Right, done now.

This was only used to scale the light's colour, just multiply the colour with it earlier on instead.
@VReaperV VReaperV force-pushed the reaper/fix-dynamic-lights-intensity/sync branch from 50875cb to ffb8083 Compare November 10, 2024 08:57
light->l.scale = -intensity;
else
light->l.scale = intensity;
if ( light->l.inverseShadows ) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The forward lighting shader checks the sign of u_LightScale to check for inverse lights. These are said to be already broken, but it would be nice to set the scale to 1 or -1 to at least gesture at how it was supposed to work

@slipher
Copy link
Member

slipher commented Nov 15, 2024

I tested this branch vs. master and found the dynamic lights are not as bright. I guess if you deleted a factor of 8 of random scaling, you need to add that back in somewhere to get the same result?

Master:
unvanquished-plat23-dlight-psaw

This branch:
unvanquished-plat23-dlight-psaw

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

Successfully merging this pull request may close these issues.

Very bright dynamic lights on some maps
2 participants