Hi Hugo, hi Andrés,
I’m also sorry for delaying this issue (which is indeed of interest to me, you poked right Hugo ;)). I have quiet a lot on my plate at the moment, but it should be better by the end of next week. I’ll gladly have a look on the issue then !
I’ll eventually update this tread if I find anything interesting.
It’s perfect then, if you spoke with Hugo about the plugin 🙂
For some reason my answer seems to have been deleted when I tried to edit the linked to the plugin, so I’ll just rewrite it here, for potential future readers.
Previous answer…[Read more]
I can only speak from my user experience, but I think you can find in SOFA the tools to perform real time simulation of a guide-wire. More precisely, what has already been done is the simulation (in real time) of catheters or embolisation coils, using serially linked beam elements.
This is actually the purpose of a dedicated plugin…[Read more]
Indeed I used the pre-built Windows binaries! (which I got here, just in case)
I’ve never tried to build Boost from the source code to then use the libraries in SOFA, but if the installation directory is not the same, I guess it can cause some issues with SOFA CMakefiles.
I hope it works fine with the binaries!
Thanks for the additional details. I’m no specialist, but I’m puzzled by the values that CMake gives to the Boost library directories in the screenshot you sent:
Boost_LIBRARY_DIR_DEBUG = “C:/Program Files/boost/boost_1_66_0/stage/lib”
Boost_LIBRARY_DIR_RELEASE = “C:/Program Files/boost/boost_1_66_0/stage/lib”
In my Boost…[Read more]
I’m working under Windows as well (using VS2015 and Boost 1.62).
If everything is going well during the CMake configuration, Boost should be detected automatically, and the name of the corresponding libraries (such as boost_program_options-vc141-mt-x64-1_66.lib) should be filled automatically as well by CMake. To check what the real…[Read more]
Thank you very much for your quick answer! Indeed changing the response type to “FrictionContact” solved the problem very efficiently.
I’ll mark the topic as closed.
Thanks for your answer!
Indeed this is not a bottleneck any more: thanks to the change of lines I mentioned in my second post, the IdentityMapping works well.
Yes, I imagined that there was something in the IdentityMapping which allowed to map Vec3d DoFs to the 3 positions DoFs of the Rigid3d nodes. I thought that this mechanism had…[Read more]
I have a scene in which I’d like to simulate collisions between an animated object (with a BeamFEMForceField model and a collision model) and an unanimated object (with only a collision model).
A specificity of the scene is that my animated object includes a BilateralInteractionConstraint between two sets of connected beam…[Read more]
I have some update regarding the IdentityMapping. By changing the line
<IdentityMapping template="Rigid3d,Vec3d" input="@../DoFs" output="@collisionDOFs"/>
the mapping is created normally and seems to work as expected.
I still have no clue regarding the BeamLinearMapping and the BarycentricMapping.…[Read more]
I’m trying to associate a collision model to connected beam elements (on which I used the BeamFEMForceField component). Ideally I would have associated the collision model directly to the topology and MechanicalObject of my beams, using the TLineModel component. However I believe that this component is not ‘instantiable’ on Rigid3d DOFs,…[Read more]
In your case, if you are using a BeamFEMForceField component, the behaviour you can simulate is – to the best of my knowledge – purely elastic (although it accounts for geometric nonlinearities).
Therefore the parameters mentioned by Zsolt (plasticMaxThreshold, plasticYieldThreshold and plasticCreep), which implement plasticity, do…[Read more]
Finally I found the problem (which was a bad mistake on my side).
During the tests I did, I compiled the OpenCascade library in different modes (Release, Debug, RelWithDebInfo) and for different versions. The problem came from the fact that the Release and Debug mode generate libraries in separate folders, and at some point the Release…[Read more]
Thanks, I hadn’t notice the PR at the end of the GitHub discussion. I tried again with the fix, adding the modifications I had done to adapt the MeshSTEPLoader (which rose no conflict). The build went with no error, but the execution of runSofa failed to load several plugins, for instance :
[ERROR] [PluginManager] Plugin loading…[Read more]
Sorry for the delay. I had a look at the GitHub discussion, but I’m not sure the problem I have is the same.
I tried to update my Sofa sources with a more recent commit (573fc41 from 2018-01-14), and it resulted exactly in the error message Erwan Douaille first mentioned in the GitHub discussion (#561).
I then switched back to the…[Read more]
I should have mentioned it actually, but yes the .dll file is indeed generated, and it is in the folder where the PluginManager is looking at by default (build/bin/RelWithDebInfo/MeshSTEPLoader.dll). I don’t know if it is worth mentioning, but the static library is generated as well in a different folder (build/lib/).
In fact, just…[Read more]
Thanks for your answer.
I tried to manually add the MeshSTEPLoader.dll via Edit->Plugin Manager->Add, but it resulted in the same error: a new window was displayed (“library loading error”) on which there was the same text (“Plugin loading failed (C:/dev/sofa/master/bd/bin/RelWithDebInfo/MeshSTEPLoader.dll): Le module spÚcifiÚ est i…[Read more]
I’m trying to use the MeshSTEPLoader plugin, in order to import a geometry from a STEP file into SOFA.
I successfully built SOFA with the plugin activated, but an error occurs when launching runSofa announcing that the plugin could not be loaded.
The output when launching runSofa is :
[ERROR] [PluginManager] Plugin loading…
- Load More