- This topic has 2 replies, 2 voices, and was last updated 5 years, 8 months ago by .
Viewing 3 posts - 1 through 3 (of 3 total)
Viewing 3 posts - 1 through 3 (of 3 total)
- You must be logged in to reply to this topic.
Home › Forum › SOFA › Programming with SOFA › [SOLVED] Programmatically create RigidMapping between MechanicalObject and VisualModel
Tagged: 64_bits, Linux_ubuntu, SOFA_1806
Dear SOFA community,
I am using an adapted version of the ColladaLoader plugin in one of my own plugins. During the import of models from a COLLADA file, this adapted version programmatically creates RigidMapping instances between MechanicalObject and VisualModel instances using the following pattern:
MechanicalObject<Rigid3dTypes>::SPtr currentBaseMechanicalObject = sofa::core::objectmodel::New<MechanicalObject<Rigid3dTypes>>();
sofa::component::visualmodel::VisualModelImpl::SPtr currentOglModel = sofa::core::objectmodel::New<OglModel>();
// ...
// Setup MechanicalObject and VisualModelImpl
// ...
RigidMapping<Rigid3dTypes, ExtVec3fTypes>::SPtr currentRigidMapping = sofa::core::objectModel::New<RigidMapping<Rigid3dTypes, ExtVec3fTypes>>();
currentRigidMapping->setModels(currentBaseMechanicalObject.get(), currentOglModel.get());
The call to setModels causes a compilation error with v18.06, but still worked fine
with the 17.xx SOFA releases. The problem is the second parameter of setModels, which seems to indicate something changed in the class inheritance hierarchy for VisualModel(Impl) between versions 17.xx and 18.06. It just isn’t clear to me what has changed exactly. Any hints or tips how to fix this compilation error are welcome!
Thank you very much!
With best regards,
Fabian
Hi @faichele
Long time no see on the forum 😉
I think this comes from the template. We recently worked on homogeneizing the use of double vs float. Therefore I think that the problem comes from the RigidMapping which should be templated on
Let me know if this first hint is a good one.
Best
Hugo
Hello, Hugo!
Indeed, the removal of the SOFA_FLOAT/SOFA_DOUBLE CMake options and the associated impact on the Rigid<n>, Vec<n>, ExtVec<n> types was indeed the issue. Removing the specializations for 3f/3d in the template parameters for the mapping did the trick, I got the plugin code to build successfully again.
Thank you very much!
With best regards,
Fabian
WARNING
The forum has been moved to GitHub Discussions.
Old topics and replies are kept here as an archive.