[Collision] Introduce multi-staged collision pipeline #5841

fredroy · 2025-12-23T05:25:29Z

Based on

[SceneChecking] Collision: new checker on the presence of a pipeline and models #5839

Add the ability to have multiple collision pipeline in a scene, instead of one monolithic pipeline (presented at the STC20)
This allows a lot of things:

group collision model with {alarm,contact} distances (can mitigate some tunneling-effect artifacts during collisions)
different response for a group of models (not tested)
mix different type of intersections
easily add custom pipelines
maybe more

It adds a warning if no collision model are handled by any pipeline.

This PR also adds a not-an-alias for CollisionPipeline similar to BruteForceDetection, but in this case I would not deprecate it and would be more seen as a convenience for most users, as the whole Multi + Sub collision pipeline is quite verbose in the end. And the former CollisionPipeline was doing a lot of things implicitly.

EDIT: with this, PipelineImpl is not used anymore (and has ... a dubious implementation by the way)

[with-all-tests]

By submitting this pull request, I acknowledge that
I have read, understand, and agree SOFA Developer Certificate of Origin (DCO).

Reviewers will merge this pull-request only if

it builds with SUCCESS for all platforms on the CI.
it does not generate new warnings.
it does not generate new unit test failures.
it does not generate new scene test failures.
it does not break API compatibility.
it is more than 1 week old (or has fast-merge label).

fredroy · 2025-12-24T01:46:33Z

[ci-build][with-all-tests]

bakpaul · 2026-01-06T14:38:36Z

...n/Detection/Algorithm/src/sofa/component/collision/detection/algorithm/CollisionPipeline.cpp

+    m_subCollisionPipeline = sofa::core::objectmodel::New<SubCollisionPipeline>();
+    m_subCollisionPipeline->d_depth.setParent(&this->d_depth);
+    m_subCollisionPipeline->l_broadPhaseDetection.set(this->broadPhaseDetection);
+    m_subCollisionPipeline->l_narrowPhaseDetection.set(this->narrowPhaseDetection);
+    m_multiCollisionPipeline = sofa::core::objectmodel::New<MultiCollisionPipeline>();
+    m_multiCollisionPipeline->l_subCollisionPipelines.add(m_subCollisionPipeline.get());


I am not sure to exactly get what you intend to do here. It seems like you are expecting that if a CollisionPipeline is in the scene, then you expect to find the rest of the components and then you internally create a MultisubCollision + SubCollision. But what if we create another SubcollisionPipeline in the scene ? How t link it to the one created automatically ?

If it is for compat purpose, why don't you just keep the old behavior ? Why forcing to instantiate a multiCollisionPipeline inside ? I suppose that it is to avoid duplicating code. Wouldn't it be cleaner to make CollisionPipeline inherits from SubCollisionPipeline ? Or at least add some static methods that does the job ?

...ection/Algorithm/src/sofa/component/collision/detection/algorithm/MultiCollisionPipeline.cpp

bakpaul · 2026-01-06T14:40:57Z

...on/Algorithm/src/sofa/component/collision/detection/algorithm/CompositeCollisionPipeline.cpp

+    {
+        if (pipelineCollisionModels.find(cm) == pipelineCollisionModels.end())
+        {
+            msg_warning() << "CollisionModel " << cm->getName() << " is not handled by any SubCollisionPipeline.";


I would add, regarding my first comment, that this message will become very confusing for used it the old CollisionPipeline uses a multi one inside.

Nope, as the CollisionPipeline will fetch all collision models, and set in the link.
https://github.com/fredroy/sofa/blob/fed32d2df4806edaf37f36fd34e47ad24f6c6472/Sofa/Component/Collision/Detection/Algorithm/src/sofa/component/collision/detection/algorithm/CollisionPipeline.cpp#L89

YEah, but the message will be prefixed with "[WARNING] [MultiCollisionPipeline(unnamed)]" which will be confusing for someone using an oold scene that doesn't contain any MultiCollisionPipeline.

Anyway, I really think that the original CollisionPipeline is just a special case of SubCollisionPipeline that is alone and doesn't belong to any multi one. The inheritance seems more appropriate for me.

bakpaul · 2026-01-06T14:42:37Z

...ection/Algorithm/src/sofa/component/collision/detection/algorithm/MultiCollisionPipeline.cpp

+        subPipeline->computeCollisionReset();
+    }
+
+    // re-order pipelines by order of distance


Initially it was in the case of if two sub collision pipelines were testing on the same collision models, to avoid doing twice/thrice whatever the same collision tests. But not sure if useful actually

...etection/Algorithm/src/sofa/component/collision/detection/algorithm/MultiCollisionPipeline.h

alxbilger · 2026-01-14T12:20:40Z

...on/Algorithm/src/sofa/component/collision/detection/algorithm/AbstractSubCollisionPipeline.h

+namespace sofa::component::collision::detection::algorithm
+{
+
+class SOFA_COMPONENT_COLLISION_DETECTION_ALGORITHM_API AbstractSubCollisionPipeline : public sofa::core::objectmodel::BaseObject


Would it be possible to document this class? Also the main virtual functions. Thanks

alxbilger · 2026-01-14T12:22:34Z

...on/Algorithm/src/sofa/component/collision/detection/algorithm/AbstractSubCollisionPipeline.h

+            this->d_componentState.setValue(sofa::core::objectmodel::ComponentState::Valid);
+        }
+
+        doInit();


Should we call doInit when validity==false?

A bit of a stretch but maybe the (in)-validity could be solved in the inheriting class 🤔

...on/Algorithm/src/sofa/component/collision/detection/algorithm/AbstractSubCollisionPipeline.h

alxbilger · 2026-01-14T12:27:18Z

...n/Detection/Algorithm/src/sofa/component/collision/detection/algorithm/CollisionPipeline.cpp

+    this->addSlave(m_subCollisionPipeline);
+    this->addSlave(m_multiCollisionPipeline);


Can you confirm that they should be slaves?

They are supposed to be totally controlled by the "master" (aka MultiCollisionPipeline) and thus should be not be used by the common visitor and such

...n/Detection/Algorithm/src/sofa/component/collision/detection/algorithm/CollisionPipeline.cpp

...ection/Algorithm/src/sofa/component/collision/detection/algorithm/MultiCollisionPipeline.cpp

...on/Algorithm/src/sofa/component/collision/detection/algorithm/AbstractSubCollisionPipeline.h

…t/collision/detection/algorithm/MultiCollisionPipeline.h Co-authored-by: Paul Baksic <[email protected]>

…t/collision/detection/algorithm/CollisionPipeline.cpp - add assertion Co-authored-by: Alex Bilger <[email protected]>

…eline

fredroy · 2026-01-22T05:10:02Z

[ci-build][with-all-tests]

fredroy force-pushed the add_multi_pipeline branch from 9d2bf0b to bbabba1 Compare December 23, 2025 07:09

fredroy force-pushed the add_multi_pipeline branch from bbabba1 to fed32d2 Compare December 24, 2025 07:23

hugtalbot added this to the v26.06 milestone Jan 5, 2026

bakpaul requested changes Jan 6, 2026

View reviewed changes

hugtalbot removed the topic for next dev-meeting PR to be discussed in sofa-dev meeting label Jan 13, 2026

alxbilger reviewed Jan 14, 2026

View reviewed changes

fredroy and others added 18 commits January 22, 2026 09:45

initial commit to bring back multi-staged collision pipeline

84bbd8a

clean

047ece4

wip

755927a

set links

0b5ab60

set getresponselist to a static function

78c3cf5

add one unit test on warning with no model and update other tests

d20e6b5

add into registry

987df29

Update Sofa/Component/Collision/Detection/Algorithm/src/sofa/componen…

6f25d7b

…t/collision/detection/algorithm/MultiCollisionPipeline.h Co-authored-by: Paul Baksic <[email protected]>

use rangeloop with structured bindings in getResponseList

34deb64

set do*() and ctor protected in AbstractSubCollisionPipeline

53629cb

put implementations into a cpp for AbstractSubCollisionPipeline

8301776

Update Sofa/Component/Collision/Detection/Algorithm/src/sofa/componen…

ddeb53f

…t/collision/detection/algorithm/CollisionPipeline.cpp - add assertion Co-authored-by: Alex Bilger <[email protected]>

multipipeline inherits TaskSchedulerUser

ad108fa

rename AbstractSubCollisionPipeline to BaseSubCollisionPipeline

3a2e9e2

remove sorting the sub pipelines

bf62901

remove useless code (about parallel computeResponse)

7139201

remove possible dereference to null

8453e79

rename MultiCollisionPipeline to CompositeCollisionPipeline

add0b08

fredroy removed the pr: status to review To notify reviewers to review this pull-request label Jan 22, 2026

fredroy added the pr: status wip Development in the pull-request is still in progress label Jan 22, 2026

fredroy force-pushed the add_multi_pipeline branch from 9518785 to add0b08 Compare January 22, 2026 04:08

the compat class CollisionPipeline now inherits CompositeCollisionPip…

fe73c65

…eline

fredroy added pr: status to review To notify reviewers to review this pull-request and removed pr: status wip Development in the pull-request is still in progress labels Jan 22, 2026

		this->addSlave(m_subCollisionPipeline);
		this->addSlave(m_multiCollisionPipeline);

[Collision] Introduce multi-staged collision pipeline #5841

Are you sure you want to change the base?

[Collision] Introduce multi-staged collision pipeline #5841

Conversation

fredroy commented Dec 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

fredroy commented Dec 24, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fredroy Jan 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

fredroy commented Jan 22, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

fredroy commented Dec 23, 2025 •

edited

Loading

fredroy Jan 22, 2026 •

edited

Loading