Skip to content

Fix VRAD prop indirect lighting regression #1345

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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

ficool2
Copy link
Contributor

@ficool2 ficool2 commented Jun 10, 2025

VRAD's prop lighting has been noted to regress since Orangebox particularly in TF2. Specifically, prop lighting appears to be darker and more harsh overall. After some digging, this is caused by a faulty calculation for how indirect (bounced) lighting is sampled on props.

Orangebox VRAD did not take into account any falloff or dot from a lighting sample. However because of this, it lead to an unnaturally bright result, although some users opinionated this is an improvement over current VRAD.

Current (TF2) VRAD accounts falloff from the sample, using an inverse square law, presumably to fix the bright results of the Orangebox's method. Unfortunately, this falloff is quite harsh and therefore creates an unnaturally dark result.

This PR implements a middleground of those both in VRAD. It only takes into account the dot of a sample, which leads to a decent spot in-between where it's not too dark or not bright. In-fact, this is the same change that CS:GO VRAD implemented to have more natural prop lighting. A bonus is this also more closely matches the indirect lighting calculation for brushes.

However, for the sake of compatibility with maps that might depend on the previous algorithms' results, a new VRAD option named -StaticPropIndirectMode is added to allow users to switch to the old TF2 or Orangebox algorithm.

Comparison:
2fort

@ficool2 ficool2 force-pushed the vrad_indirectproplighting branch from 662aa9b to e86e675 Compare June 10, 2025 11:47
@EternallyEmber
Copy link

EternallyEmber commented Jun 10, 2025

oh, hi! Ficool!

This solution Looks amazing! ❤️
i suppose adding AO too as #1343 mentioned is a optional enhancement better left to be done separately someday.

now i just really hope this gets in!!!!

@SirYodaJedi
Copy link

SirYodaJedi commented Jun 11, 2025

This is a huge improvement; I had assumed static props weren't taking indirect lighting into account at all, as I was getting some parts of props as pitch black when recompiling DoDS maps.
I'm definitely going to be adding this to my personal VRAD fork, but I do hope that if this PR is approved, the other first party SDK2013 games besides TF2 get the update as well, so everyone can benefit.

For clarification, does the lighting issue also affect the singleplayer SDK? The comments mention TF2 specifically, but it sounds like the change was a 2013 thing (so it'd also affect HL2).

@Bitl
Copy link
Contributor

Bitl commented Jun 11, 2025

This is a huge improvement; I had assumed static props weren't taking indirect lighting into account at all, as I was getting some parts of props as pitch black when recompiling DoDS maps. I'm definitely going to be adding this to my personal VRAD fork, but I do hope that if this PR is approved, the other first party SDK2013 games besides TF2 get the update as well, so everyone can benefit.

For clarification, does the lighting issue also affect the singleplayer SDK? The comments mention TF2 specifically, but it sounds like the change was a 2013 thing (so it'd also affect HL2).

this also effects the SP sdk as well i think.

@ficool2
Copy link
Contributor Author

ficool2 commented Jun 11, 2025

For clarification, does the lighting issue also affect the singleplayer SDK? The comments mention TF2 specifically, but it sounds like the change was a 2013 thing (so it'd also affect HL2).

Games not derived from SDK 2013 MP have the orangebox algorithm (and so suffer from being too bright)

Bitl added a commit to FIREFIGHT-RELOADED/FIREFIGHT-RELOADED-src-sdk-2013 that referenced this pull request Jun 11, 2025
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

Successfully merging this pull request may close these issues.

4 participants