Make visibility range (HLOD) dithering work when prepasses are enabled. #16286
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
Currently, the prepass has no support for visibility ranges, so artifacts appear when using dithering visibility ranges in conjunction with a prepass. This patch fixes that problem. Note that this patch changes the prepass to use sparse bind group indices instead of sequential ones. I figured this is cleaner, because it allows for greater sharing of WGSL code between the forward pipeline and the prepass pipeline. The `visibility_range` example has been updated to allow the prepass to be toggled on and off.
pcwalton
added
A-Rendering
tbillington
approved these changes
Nov 8, 2024
Screen.Recording.2024-11-08.171652.mp4There is a very noticeable grey flicker when the model changes with the prepass enabled. |
BenjaminBrienen
added
C-Feature
IceSentry
approved these changes
Nov 22, 2024
IceSentry
added
S-Ready-For-Final-Review
pcwalton
added a commit
to pcwalton/bevy
that referenced
this pull request
Nov 22, 2024
PR bevyengine#15164 made Bevy consider the center of the mesh to be the center of the axis-aligned bounding box (AABB). Unfortunately, this breaks crossfading in many cases. LODs may have different AABBs and so the center of the AABB may differ for different LODs of the same mesh. The crossfading, however, relies on all LODs having *precisely* the same position. To address this problem, this PR adds a new field, `use_aabb`, to `VisibilityRange`, which makes the AABB center point behavior opt-in. @BenjaminBrienen first noticed this issue when reviewing PR bevyengine#16286. That PR contains a video showing the effects of this regression on the `visibility_range` example. This commit fixes that example.
|
Turns out that the bug that @BenjaminBrienen noticed is actually a regression from a much earlier PR. I submitted a fix at #16468. |
BenjaminBrienen
approved these changes
Nov 22, 2024
github-merge-queue bot
pushed a commit
that referenced
this pull request
Nov 22, 2024
…ed. (#16468) PR #15164 made Bevy consider the center of the mesh to be the center of the axis-aligned bounding box (AABB). Unfortunately, this breaks crossfading in many cases. LODs may have different AABBs and so the center of the AABB may differ for different LODs of the same mesh. The crossfading, however, relies on all LODs having *precisely* the same position. To address this problem, this PR adds a new field, `use_aabb`, to `VisibilityRange`, which makes the AABB center point behavior opt-in. @BenjaminBrienen first noticed this issue when reviewing PR #16286. That PR contains a video showing the effects of this regression on the `visibility_range` example. This commit fixes that example. ## Migration Guide * The `VisibilityRange` component now has an extra field, `use_aabb`. Generally, you can safely set it to false.
mockersf
pushed a commit
that referenced
this pull request
Nov 22, 2024
…ed. (#16468) PR #15164 made Bevy consider the center of the mesh to be the center of the axis-aligned bounding box (AABB). Unfortunately, this breaks crossfading in many cases. LODs may have different AABBs and so the center of the AABB may differ for different LODs of the same mesh. The crossfading, however, relies on all LODs having *precisely* the same position. To address this problem, this PR adds a new field, `use_aabb`, to `VisibilityRange`, which makes the AABB center point behavior opt-in. @BenjaminBrienen first noticed this issue when reviewing PR #16286. That PR contains a video showing the effects of this regression on the `visibility_range` example. This commit fixes that example. ## Migration Guide * The `VisibilityRange` component now has an extra field, `use_aabb`. Generally, you can safely set it to false.
ecoskey
pushed a commit
to ecoskey/bevy
that referenced
this pull request
Dec 2, 2024
…ed. (bevyengine#16468) PR bevyengine#15164 made Bevy consider the center of the mesh to be the center of the axis-aligned bounding box (AABB). Unfortunately, this breaks crossfading in many cases. LODs may have different AABBs and so the center of the AABB may differ for different LODs of the same mesh. The crossfading, however, relies on all LODs having *precisely* the same position. To address this problem, this PR adds a new field, `use_aabb`, to `VisibilityRange`, which makes the AABB center point behavior opt-in. @BenjaminBrienen first noticed this issue when reviewing PR bevyengine#16286. That PR contains a video showing the effects of this regression on the `visibility_range` example. This commit fixes that example. ## Migration Guide * The `VisibilityRange` component now has an extra field, `use_aabb`. Generally, you can safely set it to false.
ecoskey
pushed a commit
to ecoskey/bevy
that referenced
this pull request
Jan 6, 2025
…ed. (bevyengine#16468) PR bevyengine#15164 made Bevy consider the center of the mesh to be the center of the axis-aligned bounding box (AABB). Unfortunately, this breaks crossfading in many cases. LODs may have different AABBs and so the center of the AABB may differ for different LODs of the same mesh. The crossfading, however, relies on all LODs having *precisely* the same position. To address this problem, this PR adds a new field, `use_aabb`, to `VisibilityRange`, which makes the AABB center point behavior opt-in. @BenjaminBrienen first noticed this issue when reviewing PR bevyengine#16286. That PR contains a video showing the effects of this regression on the `visibility_range` example. This commit fixes that example. ## Migration Guide * The `VisibilityRange` component now has an extra field, `use_aabb`. Generally, you can safely set it to false.
ecoskey
pushed a commit
to ecoskey/bevy
that referenced
this pull request
Jan 6, 2025
…d. (bevyengine#16286) Currently, the prepass has no support for visibility ranges, so artifacts appear when using dithering visibility ranges in conjunction with a prepass. This patch fixes that problem. Note that this patch changes the prepass to use sparse bind group indices instead of sequential ones. I figured this is cleaner, because it allows for greater sharing of WGSL code between the forward pipeline and the prepass pipeline. The `visibility_range` example has been updated to allow the prepass to be toggled on and off.
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.
Currently, the prepass has no support for visibility ranges, so artifacts appear when using dithering visibility ranges in conjunction with a prepass. This patch fixes that problem.
Note that this patch changes the prepass to use sparse bind group indices instead of sequential ones. I figured this is cleaner, because it allows for greater sharing of WGSL code between the forward pipeline and the prepass pipeline.
The
visibility_rangeexample has been updated to allow the prepass to be toggled on and off.