Context
#445 added a creation-time "Join Primitives (J)" toggle that combines multiple colliders into one compound mesh when they're generated together in a single pass (join_primitives, collider_shapes/add_bounding_primitive.py).
This issue is about the retroactive case: a collider was made as a box in one step and a cylinder in a separate step (or at different times), and the user now wants to select both and merge them into a single compound mesh after the fact, without redoing the creation.
Open question
This may already be considered covered in spirit by #445's creation-time join, since the common case (build several primitives for one object in one go) is handled. Flagging explicitly for a scope call: is the retroactive/after-the-fact case worth a dedicated operator, or is #445's toggle sufficient and this should be closed as not planned?
Proposal (if pursued)
New operator (e.g. object.join_colliders_to_compound) that:
- Requires 2+ selected collider objects sharing the same render-mesh parent.
- Reuses
bmesh_join (bmesh_operations/mesh_edit.py) for the geometry merge.
- Applies existing collider-renaming logic to the result, consistent with how
join_primitives names its output today.
Acceptance criteria
- Selecting 2+ existing collider objects and running the operator produces one compound mesh collider, named per the existing convention.
- Operator validates the selection (rejects non-collider objects, objects with different parents, or fewer than 2 selected) with a clear error message.
Context
#445 added a creation-time "Join Primitives (J)" toggle that combines multiple colliders into one compound mesh when they're generated together in a single pass (
join_primitives,collider_shapes/add_bounding_primitive.py).This issue is about the retroactive case: a collider was made as a box in one step and a cylinder in a separate step (or at different times), and the user now wants to select both and merge them into a single compound mesh after the fact, without redoing the creation.
Open question
This may already be considered covered in spirit by #445's creation-time join, since the common case (build several primitives for one object in one go) is handled. Flagging explicitly for a scope call: is the retroactive/after-the-fact case worth a dedicated operator, or is #445's toggle sufficient and this should be closed as not planned?
Proposal (if pursued)
New operator (e.g.
object.join_colliders_to_compound) that:bmesh_join(bmesh_operations/mesh_edit.py) for the geometry merge.join_primitivesnames its output today.Acceptance criteria