WIP: Add support for multiple shadows#2
Draft
Rainyan wants to merge 12 commits intoDESTROYGIRL:dynamic_rtt_shadowsfrom
Draft
WIP: Add support for multiple shadows#2Rainyan wants to merge 12 commits intoDESTROYGIRL:dynamic_rtt_shadowsfrom
Rainyan wants to merge 12 commits intoDESTROYGIRL:dynamic_rtt_shadowsfrom
Conversation
This reverts commit 0326a07.
This reverts commit a143a91.
This reverts commit 574dcb8.
This reverts commit 44e757b.
This reverts commit a68bffc.
This refactor has no functional changes, but is a midway commit for preparing to support renderables with more than 1 shadow cast at different angles. Refactor C_BaseEntity shadow handle member variable m_ShadowHandle from type ClientShadowHandle_t to CUtlVector<ClientShadowHandle_t> of size 1. This commit merely changes the data type, but will still hold the assumption that there may only be 1 shadow handle per entity. Change GetBrightestLightSource to GetNthBrightestLightSource for supporting getting the nth brightest light source, instead of just the brightest. Currently, we just query it for the 0th brightest (i.e. the brightest) source like before, but this is in preparation for additional shadows for the other angles for the same entity. The enum CLIENTSHADOW_INVALID_HANDLE is modified from largest value (65535) to one less, so that we can reserve the largest value for the new magic value CLIENTSHADOW_OUT_OF_RANGE, to be used for iterating shadow handles, for the future >1 shadows-per-ent support. This technically reduces the max castable shadows from 65534 to 65533, but in practice it doesn't matter because we'll never reach this limit. Finally, we're changing the IClientRenderable::GetShadowHandle interface prototype to require a shadow index parameter, and refactoring any code related to the above changes to be compatible with the new syntax.
2 tasks
Minimum naive implementation for casting 2 shadows per player. Still need to fix the shadow handle dirty flags to support more than 1 shadows, adjust the shadow brightnesses, and support alpha fading for transitioning between shadows, since this would be the main feature needed for avoiding the occasionally strange-looking shadow lerp.
Divide shadow FX alpha blend amount by the shadow count
Scale shadow FX alpha blend alpha value by the fraction of the shadow brightness squared magnitude over n-1th shadow brightness squared magnitude. I.e. adjust the shadow brightness in comparison to its relative next-darkest shadow brightness.
Fix shadow FX alpha blend alpha value calculations for 1 and 2 shadow cases. We assume no more than 2 shadows for now.
Support alpha blend division for arbitrary shadow counts
Swap shadows instantly when we're lerping between A->B and B->A, i.e. the two shadows wish to take each others' places
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
WIP, not ready for merge yet!
This is a draft for supporting multiple shadows with alpha blend, for addressing some of the trouble with NeotokyoRebuild#1249
For now, I have reverted the range a68bffc..0326a07 manually to avoid rewriting the aforementioned main neo PR history, so this is effectively based atop a021b83. If we need changes from the reverted range, we could cherry-pick them on top of this PR to re-apply them once this PR ready for merge to the main PR NeotokyoRebuild#1249.