You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, only one constraint solver is available and implemented in the MoreauJeanSolver struct. For research purposes I'm working on other constraint solver implementations (though they are far too specialized at the moment to contribute them anytime soon). At the moment there is no simple way of implementing and switching between different solvers in nphysics without forking it and implementing everything inside of the fork.
First of all, I would propose to add a ConstraintSolver trait that requires all functions that are currently called on the MoreauJeanSolver by the MechanicalWorld or should be part of the solver interface in general. This includes at least the functions step and step_ccd. It might also include the set_contact_model function but I'm not 100% sure if this has to be required for the trait.
The second point would be how different solver types get handled by the world. This could be done either through generics or using a trait object.
The first approach would be easier to combine with the current design of the MechanicalWorld and its methods. I think this would just require to add a generic Solver: ConstraintSolver parameter to the world and accordingly change the type of the solver field. This should be enough to make it work.
Alternatively, one could also use a trait object to access the solver. This would technically allow changing the solver between steps without constructing a new MechanicalWorld.
However this requires more changes from the current design.
The method step of the MechanicalWorld and the methods step and step_ccd along with some internal methods of MoreauJeanSolver are generic wrt. Colliders: ColliderSet<N, Bodies::Handle, Handle = CollHandle> and Constraints: JointConstraintSet<N, Bodies>. They have to be removed from the methods to support creating a ContstraintSolver trait object. The only possible solution I can think of is moving the generic parameters to the ConstraintSolver and MechanicalWorld traits themselves. Inside of the constraint solver implementations this would require adding phantom data fields because the types are only used be the respective methods.
Changing the solver to a trait object requires adding an additional lifetime bound of `static to some of its generic parameters which includes Bodies, Colliders and Constraint. I'm not sure if this is ok because I think a goal of making these set types generic parameters was to move lifetime handling out of the world.
Any thoughts on this?
The text was updated successfully, but these errors were encountered:
Currently, only one constraint solver is available and implemented in the
MoreauJeanSolver
struct. For research purposes I'm working on other constraint solver implementations (though they are far too specialized at the moment to contribute them anytime soon). At the moment there is no simple way of implementing and switching between different solvers innphysics
without forking it and implementing everything inside of the fork.First of all, I would propose to add a
ConstraintSolver
trait that requires all functions that are currently called on theMoreauJeanSolver
by theMechanicalWorld
or should be part of the solver interface in general. This includes at least the functionsstep
andstep_ccd
. It might also include theset_contact_model
function but I'm not 100% sure if this has to be required for the trait.The second point would be how different solver types get handled by the world. This could be done either through generics or using a trait object.
The first approach would be easier to combine with the current design of the
MechanicalWorld
and its methods. I think this would just require to add a genericSolver: ConstraintSolver
parameter to the world and accordingly change the type of thesolver
field. This should be enough to make it work.Alternatively, one could also use a trait object to access the solver. This would technically allow changing the solver between steps without constructing a new
MechanicalWorld
.However this requires more changes from the current design.
step
of theMechanicalWorld
and the methodsstep
andstep_ccd
along with some internal methods ofMoreauJeanSolver
are generic wrt.Colliders: ColliderSet<N, Bodies::Handle, Handle = CollHandle>
andConstraints: JointConstraintSet<N, Bodies>
. They have to be removed from the methods to support creating aContstraintSolver
trait object. The only possible solution I can think of is moving the generic parameters to theConstraintSolver
andMechanicalWorld
traits themselves. Inside of the constraint solver implementations this would require adding phantom data fields because the types are only used be the respective methods.`static
to some of its generic parameters which includesBodies
,Colliders
andConstraint
. I'm not sure if this is ok because I think a goal of making these set types generic parameters was to move lifetime handling out of the world.Any thoughts on this?
The text was updated successfully, but these errors were encountered: