Stop rendering clear lights #4225
Merged
Conversation
This file contains 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
`ZoneView.getVisibleArea(PlayerView)` is guaranteed to return a non-`null` result. This method is now marked as `@Nonnull` to make this clear, and we can avoid several `null` checks in `ZoneRenderer` as a result.
We already cached total lit areas, and this change also adds darkness. Just as for lit areas, the necessary computation is done lazily. The terminology has also been cleaned up: the lit area used to be termed "visible area", but `Illumination` doesn't actually know anything about visibility. So `Illumination.getVisibleArea()` has been renamed to `Illumination.getLitArea()`, and other uses of the term "visible" have also been removed.
Non-GM players need to have darkness rendered as blackness rather than as lights. We used to accomplish this by rendering each darkness as a regular light (as the GM would see it), then would paint each darkness as black afterwards. Now we don't even represent the darkness as a `DrawableLight` unless the player is a GM. This way we aren't wasting time compositing darkness lights that won't even be visible in the end. We also don't render the darknesses individually, but instead render the entire darkened area as black in a single pass.
Clear lights no longer get mapped to `DrawableLight` instances, making it so that they no longer get rendered. With this change, `DrawableLight`s can no longer have `null` paints. This means we no longer need to support "default paints" in `ZoneRenderer.renderLightOverlay()`, so that parameter and related logic have been removed.
kwvanderlinde
force-pushed
the
bugfix/4213-colourless-lights-as-transparent
branch
from
00f6a8e
to
d488009
Compare
cwisniew
approved these changes
Jul 31, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Identify the Bug or Feature request
Fixes #4213
Description of the Change
The primary change is to avoid building
DrawableLightobjects for clear lights (lights with anullpaint).This required changes to how player darkness is rendered as we can no longer rely on each darkness being represented as
DrawableLights (darkness can be clear just like lights). So instead we now find the entire darkened area from theZoneViewand render that as black without needing to know about the individual darkness sources.For a performance win, we also now avoid rendering the colour aspect of darkness when the player is not a GM, since only GMs can see them anyways.
Some minor edits made along the way were:
nullchecks inZoneRendererregarding the visible area.Possible Drawbacks
Anyone with a clear light may have gotten used to the 1.13 behaviour of treating it as black. Can be worked around by explicitly defining the light as black.
Documentation Notes
Lights will be rendered a clear if no colour is given, e.g.,
Transparent 20: scale circle 20+100Release Notes
This change is