Status: deferred. This issue tracks the dynamics work the design doc deliberately puts out of scope, with rationale per item and the conditions under which we'd revisit. Single tracker so the deferrals are visible and can be triaged together when a real driving scenario surfaces.
Per design doc (Section 15.5, Appendix A.4).
Deferred items
1. Constraint / joint forces (springs, dampers, revolute joints with reaction forces)
Why deferred: JEOD's stable model has zero joint primitives; the experimental models/experimental/constraints/ is an unfinished fuel-slosh stub (constrained pendulums for fluid in tanks), not general articulation. Mission code that needs joint-equivalent forces today applies them via ExternalForceC / ExternalTorqueC on individual children — workable for simple cases.
Revisit when: a mission scenario needs force-controlled joints with reaction-force resolution (a robotic arm under torque control where the joint torque must produce the right reaction on both link bodies), or when slosh-effect modeling becomes load-bearing (large fuel tanks during burns). Either way, the entry point is a JointForceC component or a slosh-specific module on top of composite-rigid-body — not a rewrite of the dynamics core.
2. Featherstone or general articulated-body algorithm
Why deferred: JEOD precedent is composite-rigid-body integration (only the root integrates; children are kinematic). Featherstone enables relative joint motion under integrated dynamics; we don't have the use case.
Revisit when: deferred-item 1 (joint forces) lands and the requirement turns out to need true relative joint motion (not kinematic driving + reaction forces). The composite-rigid-body work in this meta's "Composite-rigid-body propagation + wrench aggregation" sub-issue does NOT preclude a future Featherstone layer; both can coexist.
3. Slosh-style constrained-pendulum module
Why deferred: Same as item 1 — JEOD's experimental stub is the precedent, but it's not finished and we don't have a scenario that needs it.
Revisit when: a mission needs realistic propellant-slosh effects during burns. Land as a separate experimental module, mirroring JEOD's models/experimental/constraints/ location.
4. Inverse kinematics / trajectory generation for arms
Why deferred: This is a mission-code concern, not physics scope. Joint trajectories come from the mission planner; the physics layer just integrates them.
Revisit when: never, unless a clear "physics layer should expose IK helpers" use case materializes. Library candidates exist outside bevy_jeod if a mission needs them.
5. Multi-body contact beyond ground-contact (#88)
Why deferred: #88 closed Tier 3 ground-contact via GroundFacet. General multi-body contact (vehicle-vehicle, vehicle-debris, vehicle-station-attachment-port) is a substantially larger workstream involving collision detection, contact resolution, and constraint forces.
Revisit when: a mission requires inter-vehicle contact that #88's ground-contact infrastructure can't cover — e.g., docking dynamics where the two vehicles need contact forces during berthing. Either land as an extension of #88's contact infrastructure or as a new contact subsystem.
6. Sensor frames as named ports on bodies (JEOD MassPoint with names)
Why deferred: Maps naturally to frame entities under the body (the kinematic chain in Section 15.1 already covers the mechanism), but the ergonomic surface for declaring named ports — "body X has a sensor port named nav_camera 1.2 m forward of CoG" — is its own design. Not load-bearing for any current consumer.
Revisit when: mission code starts hand-rolling named-port handles and the boilerplate becomes painful, or when sensor-frame queries become a recurring pattern across multiple mission crates.
7. Runner-side BodyRefFrame::mass_point back-pointer absence
Why deferred: Discovered while reading JEOD during the #268 design audit. JEOD's BodyRefFrame extends RefFrame with a MassPoint * back-pointer keeping the frame and mass trees coherent; our runner port (crates/jeod_dynamics::MassBody) uses Vec<MassPoint> per body rather than a tree, and frames have no mass-side handle. Runner-side limitation, not on the Bevy adapter critical path.
Revisit when: the runner needs to support multi-body arrangements where frames must navigate to their corresponding mass point (e.g., a debugger that displays mass + frame consistently, or a serializer that round-trips both trees as one logical structure). The Bevy-side mass-tree sub-issue in this meta does NOT need this — it's a runner-specific gap.
Triage rule
Each item stays here until a concrete scenario / mission requirement surfaces that needs it. At that point, file a focused implementation issue, link it from this one, and update the corresponding "Revisit when" with the trigger.
Status: deferred. This issue tracks the dynamics work the design doc deliberately puts out of scope, with rationale per item and the conditions under which we'd revisit. Single tracker so the deferrals are visible and can be triaged together when a real driving scenario surfaces.
Per design doc (Section 15.5, Appendix A.4).
Deferred items
1. Constraint / joint forces (springs, dampers, revolute joints with reaction forces)
Why deferred: JEOD's stable model has zero joint primitives; the experimental
models/experimental/constraints/is an unfinished fuel-slosh stub (constrained pendulums for fluid in tanks), not general articulation. Mission code that needs joint-equivalent forces today applies them viaExternalForceC/ExternalTorqueCon individual children — workable for simple cases.Revisit when: a mission scenario needs force-controlled joints with reaction-force resolution (a robotic arm under torque control where the joint torque must produce the right reaction on both link bodies), or when slosh-effect modeling becomes load-bearing (large fuel tanks during burns). Either way, the entry point is a
JointForceCcomponent or a slosh-specific module on top of composite-rigid-body — not a rewrite of the dynamics core.2. Featherstone or general articulated-body algorithm
Why deferred: JEOD precedent is composite-rigid-body integration (only the root integrates; children are kinematic). Featherstone enables relative joint motion under integrated dynamics; we don't have the use case.
Revisit when: deferred-item 1 (joint forces) lands and the requirement turns out to need true relative joint motion (not kinematic driving + reaction forces). The composite-rigid-body work in this meta's "Composite-rigid-body propagation + wrench aggregation" sub-issue does NOT preclude a future Featherstone layer; both can coexist.
3. Slosh-style constrained-pendulum module
Why deferred: Same as item 1 — JEOD's experimental stub is the precedent, but it's not finished and we don't have a scenario that needs it.
Revisit when: a mission needs realistic propellant-slosh effects during burns. Land as a separate experimental module, mirroring JEOD's
models/experimental/constraints/location.4. Inverse kinematics / trajectory generation for arms
Why deferred: This is a mission-code concern, not physics scope. Joint trajectories come from the mission planner; the physics layer just integrates them.
Revisit when: never, unless a clear "physics layer should expose IK helpers" use case materializes. Library candidates exist outside
bevy_jeodif a mission needs them.5. Multi-body contact beyond ground-contact (#88)
Why deferred: #88 closed Tier 3 ground-contact via
GroundFacet. General multi-body contact (vehicle-vehicle, vehicle-debris, vehicle-station-attachment-port) is a substantially larger workstream involving collision detection, contact resolution, and constraint forces.Revisit when: a mission requires inter-vehicle contact that #88's ground-contact infrastructure can't cover — e.g., docking dynamics where the two vehicles need contact forces during berthing. Either land as an extension of #88's contact infrastructure or as a new contact subsystem.
6. Sensor frames as named ports on bodies (JEOD
MassPointwith names)Why deferred: Maps naturally to frame entities under the body (the kinematic chain in Section 15.1 already covers the mechanism), but the ergonomic surface for declaring named ports — "body X has a sensor port named
nav_camera1.2 m forward of CoG" — is its own design. Not load-bearing for any current consumer.Revisit when: mission code starts hand-rolling named-port handles and the boilerplate becomes painful, or when sensor-frame queries become a recurring pattern across multiple mission crates.
7. Runner-side
BodyRefFrame::mass_pointback-pointer absenceWhy deferred: Discovered while reading JEOD during the #268 design audit. JEOD's
BodyRefFrameextendsRefFramewith aMassPoint *back-pointer keeping the frame and mass trees coherent; our runner port (crates/jeod_dynamics::MassBody) usesVec<MassPoint>per body rather than a tree, and frames have no mass-side handle. Runner-side limitation, not on the Bevy adapter critical path.Revisit when: the runner needs to support multi-body arrangements where frames must navigate to their corresponding mass point (e.g., a debugger that displays mass + frame consistently, or a serializer that round-trips both trees as one logical structure). The Bevy-side mass-tree sub-issue in this meta does NOT need this — it's a runner-specific gap.
Triage rule
Each item stays here until a concrete scenario / mission requirement surfaces that needs it. At that point, file a focused implementation issue, link it from this one, and update the corresponding "Revisit when" with the trigger.