Forum Replies Created
-
Posts
-
Hi @sergiopm23,
I would suggest implementing your rigid object in this way:
1) you create a node (let’s call it “RigidObj”), which contains a MechanicalObject with template Rigid3d. This MechanicalObject is composed of a single DOF, placed in correspondence of the barycenter of your object.
2) you create a child node of RigidObj (let’s call it “RigidObjVec”). Within this node, you define a new MechanicalObject which is templated with Vec3d and contains all the points of your object (loaded from a surface mesh for example), and you add a RigidMapping component. The RigidMapping allows you to make all the points in your RigidObjVec move following the barycenter.In this way, you can define the BoxROI within the RigidObjVec node, and you should have no more issues with the templates.
Hope it solves the problem!
EleonoraHello everyone,
I am also looking for a way to add a virtual RGB-D sensor in my simulation (thus, both 2D image and depth, giving the whole visible 3D point cloud) and I have come into this thread. Since last post is of some months ago, I am wondering if any of you has made any progress meanwhile and/or has any suggestion? @jieying @balazs @jangirrishabh @pierreshg
Thanks!
EleonoraHi everyone,
I know this issue has been already closed but I have a related question. I am wondering if it would be possible to replicate the pygame example using the old SofaPython (thus, python2). As far as I understand, I could use pygame and pyopengl to create a separate OpenGL context, but I am not sure that I will be able to redirect a view of my simulation there (I am missing something that does the same as
Sofa.SofaGL.draw, line 47). Do you have any suggestion or ideas?Unfortunately, I need to stick to python2 version to interface my simulation with another program.
Thanks!
Hello @ma1991,
Not long ago, I attended an event where there was one of the developers of the SoftRobots plugin and we tried out a similar scene. We experienced the same issue: the scene works perfectly on Linux, but it’s not the same on OSX. We have been told that the issue might be the way graphics is handled on OSX, which may mess things up a bit when you try to interact directly with the scene through the mouse. I am sorry I cannot really help you with the problem, but at least I can say that it might be not that straightforward to solve!
Eleonora
Hello @hkomninos,
I did some work on the comparison between FEBio and SOFA, in particular related to nonlinear constitutive laws (StVenant-Kirchhoff and Neo-Hookean). Based on my experience, it’s worth checking that you are using the same integration rule in SOFA and FEBio. Indeed, while SOFA always uses 1-point Gauss integration rule (to my knowledge), in FEBio you can specify also other rules, that can lead to quite different results (check this link, Section 3.5.1). In particular, with 1-point Gauss you might underestimate the displacements.
Apart from that, I did not investigate too much the corotational implementation in SOFA. However, it happened both to me and to other users to notice a weird response of that material, especially in static simulations. I do not know if @igorp and @jnbrunet have figured out something new about that.
Ciao!
EleonoraHi @krewcunc,
Thank you for your reply.
Actually I have been a bit vague by calling it “beam”, indeed what I am trying to simulate is a parallelepiped (thus, beam-shaped) modelled with a TetrahedralCorotationalFEM (which does not implement plasticity, likewise the BeamFEM). I guess I’m just having some discretization/numerical issues, but in order to be sure of that, it would be interesting to have some reference validations of SOFA implementations with those of other softwares. We could definitely open another topic on this.Eleonora
Hi @jangirrishabh,
I’ve come across your post and I think you should have a look at this post. I think that either the AttachConstraint or the BilateralInteractionConstraint components could work for you.
I hope you’ll find it useful.
EleonoraI have found this quite old topic and I wanted to ask if you’ve ever succeeded in comparing SOFA solutions with those of other softwares in the meanwhile.
I was indeed trying to simulate the same scenario mentioned above (3D linear elastic beam with gravity, fixed at one end) but results are not exactly as I expected. As Zsolt was mentioning, maybe there are some parameters (apart from the elastic modulus and Poisson ratio) that should be considered and tuned.Thank you!
EleonoraHi all,
I know this thread is quite old, but I am facing the same problem you described here. Did you eventually find any way to solve it?
Thanks!
EleonoraHi guys,
I’ve just tried to install v17.12 again, and I do not have the freezing issue anymore (whereas the double clicking is still not fixed, but it’s a minor thing).
Thank you!
EleonoraHi Hugo,
Thanks for your suggestion. I’m still working on it, I’ll let you know if I solve the issue.
I have another question: can you confirm that the TetrahedralCorotationalFEMForceField assumes that my model has a linear elastic behaviour? Is there a way to use other constitutive models in SOFA?Many thanks!
EleonoraHi there,
Both the breast and the probe are in mm.
However, if I use a Young modulus in MPa (~ 0.01), the breast does not behave as I expect (when deformed only by gravity). I will try to think about this measurement units issue and let you know if I make any progress.Thank you again.
EleonoraHi Hugo,
Thank you for your answer. I tried the solution you posted and it works correctly. Anyway, if I replace the hemisphere with the breast mesh, SOFA crashes as soon as collision with the probe is detected. I tried to consider as collision model just the subset of the mesh lying close to the probe, and I tried some different models (at different resolutions) but the behaviour is always the same. Do you think this has to deal with the breast mesh model itself? It doesn’t seem that irregular to me.
Thank you!
Eleonora
