Forum Replies Created
-
AuthorPosts
-
epernodBlocked
Hi,
sorry I didn’t read the whole conversation but did you give a try with SubsetTopologyEngine ?
You can split the mesh using a boxROI and then use tetra FEM on the ROI you want to simulate with accuracy and use a Grid + HexaFEM for the rest of the mesh.
It is more a trick than an accurate solution. Otherwise I would recommand to generate a better mesh with CGal for example and putting more seeds where you need finer meshSee example : examples/Components/engine/SubsetTopoloy_refiningMesh.scn
regards,
epernodBlockedHi,
stl in ascii and binary is supported using the MeshSTLLoader but I don’t know URDF/stl, could you share a small mesh to see the format?
From which software do you export this format?regards,
epernodBlockedHi,
could you do a simple test and try to launch runSofa with another scene. To check if it is the scene or the app.
You Can do this by launching from shell:
./runSofa.exe /path/examples/Demos/liver.scnRegards
11 October 2019 at 18:36 in reply to: scene slowing down on interaction with two forcefeedback devices #14392epernodBlockedHi,
could you just specify which version of SOFA you are using.
thanks,
Erik
epernodBlockedHi,
Looking only at the numbers. I think you are trying to incisé outside of the mesh.
Do you confirm that you Can see the mesh when you start thé simulation before cutting?
The numbers in the .txt are 3d coords. So your first incision point is on (5,6,0) while your points are between (0,0,0) and (2,2,0).
Let me know if changing thé coords in the txt works.
Regards,
epernodBlockedhi,
ok, but were you able to run the OpenHaptics example? Sofa is using this lib to control the geomagic. So if there example do not work, maybe you need to update your version of OH.best,
epernodBlockedHi,
any update on your problem?regards,
epernodBlockedok I don’t think it is a problem from SOFA.
As it is using OpenHaptics to communicate with the touch, be sure to have an up to date version and if you can try to run the example from the lib as well.epernodBlockedHi,
sorry my hexadecimal is a bit rusty.
771 correspond to:
#define HD_COMM_CONFIG_ERROR 0x0303
in openHaptics: hdDefines.h
Just to be sure, when you are using the touch setup, is the device well detected?
Are you able to run touch demo ? (I’m on windows, so not sure it exists on linux)best,
epernodBlockedHi,
the driver error 771 if I well remember means that your device is busy.
Be sure before starting the scene that you have closed all touch app. like the demo or Touch Setup.If none, also check in your task manager that there is no zombie task like an old exec of runSofa or touch app.
best regards,
epernodBlockedHi,
the normal you see in the window are coming from the OglModel of your scene.
Each OglModel has a Datanormal
. I’m not used to create scene in python but I’m quite sure you can access directly Data values of component.Be sure to have
updateNormals
set to true in the OglModelErik
epernodBlockedAnd be sure to work on a nearly up to date version of SOFA from github because several bugs on the topology operation have been fixed in the past months.
epernodBlockedDid someone say topology? Did I saw the bat-topology-signal?
Hello Wendy,
yes sorry, all those components are still a bit messy. It is on the todo list to have a clearer api.
Until then, for basic suppression/add of topological elements, I would suggest to have a look at those scenes:
https://github.com/sofa-framework/sofa/tree/master/examples/Components/topology/TopologicalModifiersthey use a component called
<TopologicalChangeProcessor listening="1" filename="RemovingTetra2TriangleProcess.txt" />
which is used to script the topological operation (mainly for tests).
This will give you a good starting point in the code on how to use the modifiers.Do not hesitate if you need more help.
best regards,
epernodBlockedHi,
no sorry, I didn’t had time to check that and I have other deadlines for the moment.
I let you know if I make progress on that topic.Erik
epernodBlockedHi,
@outtt I see the delay in your video but I tested the liver18.12.scn on my computer and I don’t have the delay.
Could you tell me exactly which version of SOFA you are using. Is it the 18.12 from github that you compiled or a package?Are you able to test on an up to date version of SOFA? There might have been additional fixes not included in the 18.12.
@Hugo, this is not link to change in the plugin. The scene have been update and the position data link has been removed to follow change in the constraint resolution API.
If indeed we lost some performances we will need to come back and understand what has been broken by the lambda function changes.Erik
epernodBlockedHello @Wong
ok I understand, the data binding has not been canceled. The code from the Geomagic didn’t changed.
But the API on how to solve the constraint changed to be more accurate. The delay is due to tool position computation regarding the constraint.When you speak about the 50 FPS, is it using the demo scene of the plugin or your scene?
Erik
epernodBlockedOk, yes it is because the omni position is now gathered inside the Omni node where there is mechanicalStateController.
To link to the Instrument model, it uses VectorSpringForceField.Letting the first Data link was creating inconsistencies between the collision and controllerState nodes communicating using the VectorSpringForceField and the direct link inside the
<MechanicalObject name="instrumentState" template="Rigid" />
Anyway, normally the old method is still working, did you try running it, what is the result?Also did you try using the other rigid skull scene using RestShapeSpringsForceField?
regards,
epernodBlockedHi,
could you just post the old scene with the data binding you are highlighting.
I will check if this is still possible or with another mechanism.The change in the scene were a consequence of changes in the constraint resolution API inside SOFA.
regards,
epernodBlockedHi guys,
just going quickly through the scene example, I think the tag “CarvingSurface” is missing on the target collision Model.
Then the class
TopologicalChangeManager
can give you which combination of collision model can be used for carving.And yes only one collision model at a time can be used for your tool.
regards,
epernodBlockedOk great!
You are welcome. Could you set the field as resolved. Thanks.epernodBlockedHi @Zhichao,
I had the same problem, it was because the cgal dll files were not found by CGALPlugin.dll
So you should add the cgal bin directory to your env path or look at this PR I try to fix that problem:
https://github.com/sofa-framework/sofa/pull/958best regards,
21 February 2019 at 18:31 in reply to: [SOLVED] AttachConstraint not compatible with freemotionanimationloop #13097epernodBlockedHello @tgaury,
could you describe what is the result you obtain. Is it crashing, nothing happen?
Do you have any output log?like this I could see 2 options. Either attachConstraint work only with defaultAnimationLoop or you have to specify indices1=”@../M1/np1.indices1″
Regards,
epernodBlockedHi,
yes you need a tetrahedron topology. I checked and only triangle model collision is working well at the moment. So you will need something like (code not tested):
<CarvingManager active="true" /> <Node name="Grid" > <RegularGrid name="HexaTop" n="12 12 12" min="-10 -6 -10" max="10 14 10" /> <MechanicalObject name="ms" position="@HexaTop.position" /> <TetrahedronSetTopologyContainer name="Container" position="@HexaTop.position" /> <TetrahedronSetTopologyModifier name="Modifier"/> <Hexa2TetraTopologicalMapping input="@HexaTop" output="@Container" swapping="false" /> </Node> <Node name="Surface" > <TriangleSetTopologyContainer name="Container"/> <TriangleSetTopologyModifier name="Modifier"/> <Tetra2TriangleTopologicalMapping input="@../Grid/Container" output="@Container" flipNormals="true"/> <TriangleSet name="triangleCol" tags="CarvingSurface"/> </Node> <Node name="carvingElement"> <MechanicalObject name="Particles" template="Vec3d" position="0 0 1.4" velocity="0 0 0"/> <UniformMass name="Mass" totalMass="1.0" /> <SphereModel radius="0.02" tags="CarvingTool"/> </Node>
++Erik
epernodBlockedHi,
@Binesh I just give a quick look at UncoupledConstraintCorrection. I saw that:
, d_handleTopologyChange(initData(&d_handleTopologyChange, true, "handleTopologyChange", "Enable support of topological changes for compliance vector (disable if another component takes care of this)"))
Do you know in which case “another component takes care of this” ? I assume it is not the default pipeline.
Then in the scene of @eunkyungbae there is
<include href="Objects/EdgeSetTopology.xml" src="@meshLoader" />
it is a shortcut to put all the edgeSetTopology.
@eunkyungbae does the scene crash as soon as you remove the first element when you put the uncoupledConstraint?
Could you just try to put the uncoupledC. but not the FixedConstraint. Maybe there is a concurrency problem.Thank you for raising the issue of different behavior with and without gmsh file…
Erik
epernodBlockedHi,
thank you for raising this issue up.
Regarding you scene, you have in the same node a Mesh and EdgeSet components.
I will add an issue on github regarding that because this should not be allowed.
This means you have 2 topologies in the same node so the other component like MechanicalObject and Spring don’t know which topology to rely on.Mesh Topology isn’t dynamic, this means it won’t handle the topological changes.
So to do more tests I suggest you change your scene like this:
<EdgeSetTopologyContainer name="Container" points="0 0 0 1 0 0 2 0 0 3 0 0 4 0 0 5 0 0 6 0 0 7 0 0 8 0 0 9 0 0" edges="0 1 1 2 2 3 3 4 4 5 5 6 6 7 7 8 8 9" /> <EdgeSetTopologyModifier name="Modifier" /> <EdgeSetTopologyAlgorithms template="Vec3d" name="TopoAlgo" /> <EdgeSetGeometryAlgorithms template="Vec3d" name="GeomAlgo" drawEdges="1"/> <MechanicalObject name="DOFs" template="Vec3d" translation="1 0 2" src="@Container" /> <UniformMass mass="1" /> <FixedConstraint name="FixedConstraint" indices="0 1" /> <MeshSpringForceField name="Springs" stiffness="100000" damping="0" /> <!-- <LineBendingSprings name="BS" stiffness="100" damping="0" />--> <UncoupledConstraintCorrection />
Then if it still breaks, could you do the same test without the UncoupledConstraintCorrection and then without the MeshSpringForceField. I’m not 100% sure those component handle topological changes.
thanks
Erik
-
AuthorPosts