Skip to content
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

[GUI.Component] ConstraintAttachBodyPerformer: Add RigidType support #4801

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

fredroy
Copy link
Contributor

@fredroy fredroy commented Jul 1, 2024

adding instantiation with RigidType + removal of "hard" usage of VecTypes.

In my case, it was to support grabbing a beam (BeamAdapter) with the mouse and constraints.

Screen.Recording.2024-07-01.at.17.08.16.mov

Reminder: BilateralConstraint needs a GenericConstraintSolver (+FreeMotionAL), LCPConstraintSolver is not usable


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 fredroy added pr: fast merge Minor change that can be merged without waiting for the 7 review days pr: status to review To notify reviewers to review this pull-request pr: new feature Implement a new feature labels Jul 1, 2024
Comment on lines 101 to 105
static const typename DataTypes::Coord point1 {};
static const typename DataTypes::Coord point2 {};
static const typename DataTypes::Deriv normal {};

bconstraint->addContact(normal, point1, point2, normal.norm(), 0, index, point2, point1);
bconstraint->addContact(normal, point1, point2, 0.0, 0, index, point2, point1);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The fact that a contact is added between two null vectors is very confusing. It appears that it was not the case initially: b664374. It worth having a discussion on this during the next meeting

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking at the code, the only parameters of this function used are the two coords (point1 and point2) and the two indices (0 and index) the rest are just unused and thus not necessary (for the templated method and the rigid spec).

@fredroy fredroy force-pushed the add_bilateralconstraitperformer_rigid branch 2 times, most recently from b4e0ef4 to 8c76365 Compare July 8, 2024 00:06
@alxbilger alxbilger added the pr: dev meeting topic PR to be discussed in sofa-dev meeting label Jul 12, 2024
@fredroy fredroy force-pushed the add_bilateralconstraitperformer_rigid branch from 8c76365 to 5db46e1 Compare July 15, 2024 00:05
Comment on lines 101 to 105
static const typename DataTypes::Coord point1 {};
static const typename DataTypes::Coord point2 {};
static const typename DataTypes::Deriv normal {};

bconstraint->addContact(normal, point1, point2, normal.norm(), 0, index, point2, point1);
bconstraint->addContact(normal, point1, point2, 0.0, 0, index, point2, point1);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking at the code, the only parameters of this function used are the two coords (point1 and point2) and the two indices (0 and index) the rest are just unused and thus not necessary (for the templated method and the rigid spec).

@fredroy fredroy added pr: status wip Development in the pull-request is still in progress and removed pr: dev meeting topic PR to be discussed in sofa-dev meeting pr: status to review To notify reviewers to review this pull-request pr: fast merge Minor change that can be merged without waiting for the 7 review days labels Jul 17, 2024
@fredroy
Copy link
Contributor Author

fredroy commented Jul 18, 2024

Dear @bakpaul,
I tried to set the option d_keepOrientDiff but, after doing some shenaningans because the Data is protected, setting this Data to true make it crashes when trying to apply the Constraint. 🫨
Note that this may be related on the fact that the Beam is modeled with BeamAdapter...

So I let it to false for the moment 😅


Here it the backtrace (on mac) if the option is to "true":

Thread 0 Crashed::  Dispatch queue: com.apple.main-thread
0   libSofa.Component.Constraint.Lagrangian.Model.24.12.99.dylib	       0x10693b764 void sofa::component::constraint::lagrangian::model::BilateralLagrangianConstraintSpecialization<sofa::component::constraint::lagrangian::model::RigidImpl>::getConstraintViolation<sofa::defaulttype::StdRigidTypes<3u, double>>(sofa::component::constraint::lagrangian::model::BilateralLagrangianConstraint<sofa::defaulttype::StdRigidTypes<3u, double>>&, sofa::core::ConstraintParams const*, sofa::linearalgebra::BaseVector*, sofa::component::constraint::lagrangian::model::BilateralLagrangianConstraint<sofa::defaulttype::StdRigidTypes<3u, double>>::DataVecCoord const&, sofa::component::constraint::lagrangian::model::BilateralLagrangianConstraint<sofa::defaulttype::StdRigidTypes<3u, double>>::DataVecCoord const&, sofa::component::constraint::lagrangian::model::BilateralLagrangianConstraint<sofa::defaulttype::StdRigidTypes<3u, double>>::DataVecDeriv const&, sofa::component::constraint::lagrangian::model::BilateralLagrangianConstraint<sofa::defaulttype::StdRigidTypes<3u, double>>::DataVecDeriv const&) + 732
1   libSofa.Core.24.12.99.dylib   	       0x10a09ee30 sofa::core::behavior::PairInteractionConstraint<sofa::defaulttype::StdRigidTypes<3u, double>>::getConstraintViolation(sofa::core::ConstraintParams const*, sofa::linearalgebra::BaseVector*) + 704
2   libSofa.Component.Constraint.Lagrangian.Solver.24.12.99.dylib	       0x10582a334 sofa::component::constraint::lagrangian::solver::MechanicalGetConstraintViolationVisitor::fwdConstraintSet(sofa::simulation::Node*, sofa::core::behavior::BaseConstraintSet*) + 136
3   libSofa.Simulation.Core.24.12.99.dylib	       0x1074e6d44 sofa::simulation::Visitor::Result sofa::simulation::Visitor::for_each<sofa::simulation::BaseMechanicalVisitor, sofa::simulation::Visitor::VisitorContext, sofa::simulation::NodeSequence<sofa::core::behavior::BaseConstraintSet, false>, sofa::core::behavior::BaseConstraintSet>(sofa::simulation::BaseMechanicalVisitor*, sofa::simulation::Visitor::VisitorContext*, sofa::simulation::NodeSequence<sofa::core::behavior::BaseConstraintSet, false> const&, sofa::simulation::Visitor::Result (sofa::simulation::BaseMechanicalVisitor::*)(sofa::simulation::Visitor::VisitorContext*, sofa::core::behavior::BaseConstraintSet*), std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>> const&) + 432
4   libSofa.Simulation.Core.24.12.99.dylib	       0x1074e6318 sofa::simulation::BaseMechanicalVisitor::processNodeTopDown(sofa::simulation::Node*, sofa::simulation::Visitor::VisitorContext*) + 1088
5   libSofa.Simulation.Core.24.12.99.dylib	       0x1074e7848 sofa::simulation::BaseMechanicalVisitor::processNodeTopDown(sofa::simulation::Node*) + 56
6   libSofa.Simulation.Graph.24.12.99.dylib	       0x104eec8b8 sofa::simulation::graph::DAGNode::executeVisitorTopDown(sofa::simulation::Visitor*, std::__1::list<sofa::simulation::graph::DAGNode*, std::__1::allocator<sofa::simulation::graph::DAGNode*>>&, std::__1::map<sofa::simulation::graph::DAGNode*, sofa::simulation::graph::DAGNode::StatusStruct, std::__1::less<sofa::simulation::graph::DAGNode*>, std::__1::allocator<std::__1::pair<sofa::simulation::graph::DAGNode* const, sofa::simulation::graph::DAGNode::StatusStruct>>>&, sofa::simulation::graph::DAGNode*) + 324
7   libSofa.Simulation.Graph.24.12.99.dylib	       0x104eecac0 sofa::simulation::graph::DAGNode::executeVisitorTopDown(sofa::simulation::Visitor*, std::__1::list<sofa::simulation::graph::DAGNode*, std::__1::allocator<sofa::simulation::graph::DAGNode*>>&, std::__1::map<sofa::simulation::graph::DAGNode*, sofa::simulation::graph::DAGNode::StatusStruct, std::__1::less<sofa::simulation::graph::DAGNode*>, std::__1::allocator<std::__1::pair<sofa::simulation::graph::DAGNode* const, sofa::simulation::graph::DAGNode::StatusStruct>>>&, sofa::simulation::graph::DAGNode*) + 844
8   libSofa.Simulation.Graph.24.12.99.dylib	       0x104eec028 sofa::simulation::graph::DAGNode::doExecuteVisitor(sofa::simulation::Visitor*, bool) + 312
9   libSofa.Component.Constraint.Lagrangian.Solver.24.12.99.dylib	       0x1057f3210 sofa::component::constraint::lagrangian::solver::ConstraintSolverImpl::getConstraintViolation(sofa::core::ConstraintParams const*, sofa::linearalgebra::BaseVector*) + 96
...
@fredroy fredroy requested a review from bakpaul July 18, 2024 06:15
@bakpaul
Copy link
Contributor

bakpaul commented Jul 18, 2024

I think this is because you need to call the bwdInit after the init and addContact calls when this parameter is used (by checking quickly the code). It is harmless when the template is Vec3D but it prepares the computation for when you want to keep the orientation -> again this is really a bad API and might require some refactoring.

If you still have the diff locally, could you try this ? I guess the usability of your feature would really gain from this if it was working. But if this doesn't make any change, I am ok with the state of the PR.

Tell me how it goes !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
pr: new feature Implement a new feature pr: status wip Development in the pull-request is still in progress
3 participants