Visibility range takes the model aabb into acount #15164
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
|
Welcome, new contributor! Please make sure you've read our contributing guide and we look forward to reviewing your pull request shortly ✨ |
alice-i-cecile
added
C-Bug
|
Haven't thought if it's more costly, but maybe we should pick a point on the edge of the AABB nearest the camera? And not the AABB center. |
|
In the frustum culling code the radius of the aabb is calculated as transform.radius_vec3a(model_aabb.half_extents). Maybe we could use the center point + the radius as the edge point? Please tell me if you would like to add that! |
IceSentry
approved these changes
Sep 12, 2024
kristoff3r
approved these changes
Sep 12, 2024
JMS55
approved these changes
Sep 12, 2024
rparrett
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.
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.
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.
Objective
I'm building a game where i generate a set of meshes where the transform is identity, and in each mesh the vertices are offset to where the model is. When adding visibility ranges to the models i noticed that they only switched when the distance to the origin changed over the threshold and all at the same time.
Solution
I believe that each mesh gets a Aabb generated for use with visibility testing. So we can use that aabb to calculate a more representative distance to the mesh.
The code to transform the aabb is taken from the visibility sysyem.
Testing
I tested the changes locally in my project.
Would you like me to write an example or a test somewhere?
Is there any other code that uses the visibility range, that i should also update?