Fix wires with 3+ sections: initTopology accumulation + chained-section rest frame#228
Open
lkarstensen wants to merge 3 commits into
Open
Conversation
added 3 commits
April 29, 2026 16:34
…ons (sofa-framework#223) x_used is the global curvilinear abscissa; adding x_start again placed the rest node at 2*x_start + local_offset instead of x_used. For wires with two or more RodStraightSections this produced enormous elastic restoring forces at every timestep, causing simulation explosion. Fix: use x_used directly, consistent with RodSpireSection and RodMeshSection.
…logy Fixes sofa-framework#225. Both accumulators were reset via assignment instead of accumulation, corrupting point coordinates and edge indices for any wire with three or more sections.
BaseRodSectionMaterial::getRestTransformOnX previously received only (x_used, x_start) and reconstructed world rest positions by adding Vec3(x_start, 0, 0). That assumes every preceding section ran straight along world +X -- true for one Straight base + one curved tip, but wrong as soon as a non-straight section is chained after another non-straight section: the rest shape was placed along world +X at keyPts[i] instead of continuing tangent-continuous from the curved predecessor tip, producing persistent unbalanced elastic forces and a "floppy" terminal section. - BaseRodSectionMaterial::getRestTransformOnX gains a const Transform& predecessor_H_sectionStart parameter. - RodStraightSection / RodSpireSection / RodMeshSection compute their local rest geometry in the section's own frame (origin at section start, +X = predecessor tip tangent) and compose with the predecessor transform instead of adding Vec3(x_start, 0, 0). - WireRestShape::getRestTransformOnX walks preceding sections, querying each tip at keyPts[i] with its accumulated predecessor, then dispatches to the owning section with the composed frame. Backward-compatible for one-section wires (predecessor = identity, x_start = 0) and for Straight + curved-tip pairs (straight tip produces (keyPts[1], 0, 0) with identity, matching the old hardcoded form). Fixes chained non-straight sections.
fredroy
added
the
pr: status to review
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Fixes #227 (combined issue covering both bugs).
Two related bugs make any wire with three or more sections (or two chained non-straight sections) unusable. Both are fixed here.
Bug 1 —
WireRestShape::initTopologyaccumulationprev_length = lengthandprev_edges = nbrVisuEdgesdiscard the cumulative offset/edge count after section 0. Only N=2 wires happen to produce identical output. From iteration 2 onward, points are placed at non-monotonic abscissas, edges become degenerate, andWireBeamInterpolation/MultiAdaptiveBeamMappingbreak.Fix:
(Originally tackled in #226, closed when further testing exposed Bug 2.)
Bug 2 — Rod section rest shape ignores predecessor section frame
BaseRodSectionMaterial::getRestTransformOnX(global_H_local, x_used, x_start)carries no predecessor-tip transform.RodSpireSection/RodMeshSectionreconstruct world position with+ Vec3(x_start, 0, 0), which is correct only when the wire so far ran straight along world +X. As soon as a non-straight section follows another non-straight section, the rest pose sits in empty space,AdaptiveBeamForceFieldAndMassinjects unbalanced elastic forces, and the terminal section becomes "floppy".Fix:
const Transform& predecessor_H_sectionStart.RodStraightSection/RodSpireSection/RodMeshSectioncompute their local rest geometry in the section's own frame (origin at section start, +X = predecessor tip tangent) and compose with the predecessor transform instead of addingVec3(x_start, 0, 0).WireRestShape::getRestTransformOnXwalks preceding sections, queries each tip atkeyPts[i]with its accumulated predecessor, then dispatches to the owning section with the composed frame.Backward-compatible:
x_start = 0→ unchanged.(keyPts[1], 0, 0)with identity → matches old hardcoded form.Files changed
src/BeamAdapter/component/engine/WireRestShape.inlsrc/BeamAdapter/component/model/BaseRodSectionMaterial.hsrc/BeamAdapter/component/model/RodStraightSection.{h,inl}src/BeamAdapter/component/model/RodSpireSection.{h,inl}src/BeamAdapter/component/model/RodMeshSection.{h,inl}Test plan
Verified manually:
WireRestShape_test(Straight + Spire) still passes — backward-compat case: predecessor stays identity for the straight, then(95, 0, 0)identity for the spire dispatch, matching the oldVec3(x_start, 0, 0)form.EdgeSetTopologyContainerhas monotonic point coordinates and the expected total edge count, no overlap.Straight + Spire(+90°) + Spire(+90°): rest pose of the second spire continues tangent to the first spire's tip instead of being placed along world +X atkeyPts[2]; tip no longer drifts under no input.cmake --build . --target BeamAdapter.