-
-
Notifications
You must be signed in to change notification settings - Fork 189
Rework deferred collider initialization #378
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
Merged
Merged
Conversation
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
Jondolf
reviewed
Jun 23, 2024
Jondolf
reviewed
Jun 23, 2024
Jondolf
reviewed
Jun 23, 2024
Jondolf
approved these changes
Jun 24, 2024
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good now, thank you for all the hard work and patience on this!
I see this also adds crate-wide allows for clippy::type_complexity and clippy::too_many_arguments. I agree we should probably do this. The existing per-method allows can be removed in a follow-up.
Jondolf
added a commit
that referenced
this pull request
Jun 29, 2024
…#386) # Objective When loading a (glTF) scene and generating colliders for it, it can be useful to be able to add all entities in that scene to some collision layer. However, `ColliderConstructorHierarchy` (previously `AsyncSceneCollider`, see #378) doesn't currently allow specifying default collision layer or density configurations despite allowing configurations for individual entities. ## Solution Add `default_layers` and `default_density` properties for `ColliderConstructorHierarchy`. The `layers` and `density` properties of `ColliderConstructorHierarchyData` are now `Option`s, and if they are `None`, the default values are used. I also moved the collider constructor types and tests to their own module, and updated some docs to remove mesh-specific wording. For reviewing purposes, the first commit (8cbe48c) should be easier to read, the other commit just moves code to the `constructor` module.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
M-Migration-Guide
A breaking change to Avian's public API that needs to be noted in a migration guide
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
As we all know,
Collideris notReflect. This is a bit of a problem for people wanting to load collider shapes from code-external sources. Notably, people using @kaosat-dev 's excellent Blender-GLTF workflow as an editor need to setup their ownReflectversion ofColliderall the time, usually something like this:and then attach XPBD colliders to entities holding the above fake collider.
I've been thinking about opening a PR on the Blender workflow to do this automatically based on a cargo feature, but then I thought that maybe this would be better in XPBD / Avian proper so that other reflect-heavy workflows may profit from it as well. I'm thinking about scene structures, embedding colliders in BSN and future Bevy editor prototypes.
Solution
My approach is to extend ComputedCollider to cover all variants of creating a collider. Some of these require a Mesh, some don't. When going through AsyncColliders, I can see if the specified creation method needs a Mesh. If so, the entity that the AsyncCollider is on must also hold a Handle
Changelog
ComputedColliderandAsyncColliderhave been combined intoColliderConstructorand support all possible collider shapes except compounds.ColliderConstructorisReflect,SerializeandDeserialize. You can use it to statically configure your colliders when loading them from code external sources such as save files or serialized level definitions.ColliderConstructorsupports creating primitive shapes, so it does not need to be placed on an entity holding a mesh.ColliderConstructorcan be used in 2D when not using computed shapesAsyncSceneCollideris now calledColliderConstructorHierarchyand no longer requires being placed on aScene. It will generally generate a collider for all available descendants.ColliderConstructoralso apply herebevy_sceneis enabled, placingColliderConstructorHierarchyon aScenewill still wait until the scene is loadedColliderConstructorHierarchy::newnow takes animpl Into<Option>instead of anOption, so you can drop theSomefrom your calls if you want:AsyncSceneCollider::new(Some(Foo))becomesColliderConstructorHierarchy::new(Foo)ColliderConstructorHierarchycan be used in 2D when not using computed shapesbevy_scenecan now be feature gated off while still using deferred collidersbevy_gltfis no longer pulled inMigration Guide
async-collider. If you need to use computed shapes, use the featurecollider-from-mesh. If you depend onColliderConstructorHierarchywaiting for a scene to load, use the featurebevy_sceneAsyncColliderand useColliderConstructordirectlyAsyncSceneCollidertoColliderConstructorHierarchyAsyncSceneCollider::default_shapetoColliderConstructorHierarchy::default_constructorAsyncSceneCollider::meshes_by_nametoColliderConstructorHierarchy::configAsyncSceneCollider::with_shape_for_nametoColliderConstructorHierarchy::with_constructor_for_nameAsyncSceneCollider::without_shape_for_nametoColliderConstructorHierarchy::without_constructor_for_nameAsyncSceneColliderDatatoColliderConstructorHierarchyConfigAsyncSceneColliderData::shapetoColliderConstructorHierarchyConfig::constructorComputedCollidertoColliderConstructor.ComputedCollider::TriMeshtoColliderConstructor::TrimeshFromMeshComputedCollider::TriMeshWithFlagstoColliderConstructor::TrimeshFromMeshWithConfigComputedCollider::ConvexHulltoColliderConstructor::ConvexHullFromMeshComputedCollider::ConvexDecompositiontoColliderConstructor::ConvexDecompositionFromMeshWithConfigVHACDParameterstoVhacdParametersCollider::halfspacetoCollider::half_spaceLinked Issues
bevy/bevy_gltfdependency fromasync-collider#306