Home › Forum › SOFA › Using SOFA › [SOLVED] How to do feasible and stable physical acceleration in force feedback scene?
Tagged: 64_bits, Cuda, physical acceleration, SOFA_1706, Windows_7
- This topic has 40 replies, 4 voices, and was last updated 5 years, 8 months ago by Wong.
-
AuthorPosts
-
5 November 2018 at 10:04 #12336WongBlocked
Hello everyone,
I notice that the fps would decrease dramatically if the deformable meshes are complex in Sofa, not like other foreign simulators perform. So I try to find and use SofaCUDA in Sofa. But after I have successfully compiled the SofaCUDA plugin, I found that there are many bugs within it.
The default scenes are quite simple and many components already in Sofa cannot be used in SofaCUDA, such as ConstantForceField (could not be created in the SofaCUDA scene) and it is easy to crash and there is no default scene about haptic control and feedback. So I do not think it would be a feasible way to be used in stable interactive scene.
My graphics card is GTX 1050 Ti and CUDA version is 8.0.
Could any one give some hints and help about it?
15 November 2018 at 10:15 #12481HugoKeymasterHi @outtt
Using very irregular or bad-quality meshes results in bad-conditioned system matrix, which makes the convergence of any linear solver complicated. Moreover, if the number of nodes/elements increases significantly, the size of the system increases in a quadratic form, which obviously will impact the performances. These two remarks are generic, thus valid for any physics engine.
CUDA is a way to accelerate computation. However, writing efficient code using the CUDA toolkit is very complicated. It is therefore worth implementing CUDA version only for complex (computationally demanding) algorithm. ConstantForceField is simple and indeed not implemented. We would be glad to welcome your contribution in the core of SOFA!
Finally, to speed up simulation, a recent plugin on Model Order Reduction has been made open-source. It may be worth it to consider.
Never forget, SOFA is open-source, therefore not perfect. But any contribution in any way is always welcome.
Best wishes,
Hugo
16 November 2018 at 16:03 #12497WongBlockedThank you @hugo,
After a lot of testing, the performance can be indeed improved if I simplify the mesh of the model. I will try my utmost to make my scene simple afterwards.
Thank you for your theoretical and detailed reply again.
18 December 2018 at 07:20 #12613WongBlockedHello @hugo,
I tried to build ModelOrderReduction, but failed.
I got errors like1>HyperReducedHexahedronFEMForceField.obj : error LNK2019: unresolved external symbol “__declspec(dllimport)
So how to solve this kind of problem?
18 December 2018 at 11:55 #12617HugoKeymasterThanks for the feedback @outtt
This plugin is a plugin developed by a research team. They are not providing support on this. However, I will catch them up and ask for information.
Let us know whether you solved your issue.
What is your exact configuration (OS, version, version of SOFA etc)Hugo
18 December 2018 at 15:18 #12619WongBlockedHello, @hugo
Well, I have not solved this issue.
I tried this plugin in both Sofa 17.06 and 17.12 on Win10 64bit. The plugin requires some classes missed in the current stable Sofa revision, obviously, both 17.06 and 17.12 included.
So I search the missing classes on GitHub and add them into my Sofa. And also check the option SOFA_WITH_EXPERIMENTAL_FEATURES at CMake.
But when I compile the plugin, errors like error LNK2019: unresolved external symbol still occurs after all. So I think it is likely that the plugin is not updated to fit the current revision of Sofa.
Can you help me?
19 December 2018 at 12:05 #12622FélixBlockedHello @outtt,
The plugin is normally up to date with Sofa but here you are using the version 17.06 & 17.12 of Sofa and we are now at version 18.06.
Is there a special reason for you to use these previous versions ?
Félix
20 December 2018 at 03:32 #12630WongBlockedHello @felixvanneste
The reason why I do not use the version 18.06 is that the Geomagic plugin works abnormally at that version.
When I run the offcial example Geomagic-RigidSkull.scn, the instrument would penetrate into the skull with little force feedback, which, however, can behave normally at 17.12.
Even so, I do not think the ModelOrderReduction plugin can be compiled successfully at 18.06 because there is no significant difference between 18.06 and 17.12. The missing class MechanicalMatrixMapper can still not be found in 18.06.
20 December 2018 at 15:03 #12672FélixBlockedHello @outtt,
Yes you are right for the Geomagic plugin there is an issue for this that has been fixed recently.
Concerning MOR you are right also, the necessary modification in sofa to make this plugin work isn’t included in the current last version 18.06.
Sorry for the false informations.
So currently for you in order to have a working MOR & Geomagic plugin you need to build it yourself from source as explained here:
Or if you can, wait till the next release that will include all the necessary adjustment
and will be public around mid-January normally.I hope this help you,
Félix24 January 2019 at 15:15 #12879WongBlockedHello @felixvanneste
Now I use version 18.12 to compile the MOR plugin and, however, the similar problems described from my previous post still arise.
But I tried to solve the compile errors by modifying the source code and finally I succeeded, albeit through tremendous efforts.
However, it seems that there is no standalone scn example for the MOR plugin and it should be used with the soft robot plugin. So I even downloaded the soft robot plugin later and then compiled it to see if it would work. But unfortunately, it crashed once I launched the reducedMultiGait-softRobot.pyscn.
So can you give me some guidance about it?
Wong
28 January 2019 at 15:45 #12917FélixBlockedHello @outtt,
sorry for all the trouble compiling on windows,
we never really test it on this OS…There is some standalone scn for this plugin but I didn’t write it anywhere explicitly.
Its in doc/examples/SOFIA.Anyways can you give me your error ? I would be glad to help you resolve it.
Félix
29 January 2019 at 05:12 #12920WongBlockedHello @felixvanneste
I tried to launch the DemoSofia.py but failed because the component OglSceneFrame has been removed from Sofa since v18.12.
So I commented out the line
#node.createObject('OglSceneFrame', style="Arrows", alignment="TopRight")
at mainheader.py in Plugin STLIB and then launched the DemoSofia.py again.But it still did not run normally because the component SparseLDLSolver always output the message “Failed to factorize, D(k,k) is zero”
30 January 2019 at 05:17 #12956WongBlocked30 January 2019 at 10:34 #12959FélixBlockedHi @outtt,
concernig OglSceneFrame component (and others), it was wrongly removed in the last binaries and is being put back maybe for this current week…
I am interested to know what finally was the error with the SparseLDLSolver and if it was concerning our plugin.
Also don’t hesitate to make some pull/issue request to ModelOrderReduction if you find some errors, thanks in advance for that.
Again if you need help or explanations to use MOR, don’t hesitate to ask or search within the documentation that I hope is helpful.
Félix
2 February 2019 at 07:57 #12978WongBlockedHello @felixvanneste,
I want to generate the data and the python scene of hexaBeam.pyscn.
So how can I specify the parameters at modelOrderReduction.py to generate it?Thanks,
Wong6 February 2019 at 11:09 #13003FélixBlockedHi @outtt,
sorry for the delay…
The hexaBeam example was made by @olivier-goury, here are the arguments:
### HEXABEAM
nodesToReduce =[‘/M1’]
actuator = ObjToAnimate(“M1/cableNode”, incr=1,incrPeriod=5,rangeOfAction=5)
listObjToAnimate = [actuator]
addRigidBodyModes = [0,0,0]We recently corrected the compilation issue of ModelOrderReduction plugin on Windows. The problem was two-fold : so PR have been made in MOR & SOFA to correct it, so for the moment the fix isn’t in any binaries. Sorry that you have to debug it yourself.
I will test today to run the different examples and tell you if everything work fine to avoid you some trouble.
Félix
6 February 2019 at 11:51 #13004WongBlockedHello @felixvanneste,
Thank you for your reply.
I want to know why these values of the parameters are the best ones. Can you give some hints to me that how I can choose the proper parameters?
And I want to report an issue on Windows: the directory separator on Windows, ‘\’, is different from that on Linux, ‘/’. So it would cause errors if reduceModel.py is directly used.
Wong
7 February 2019 at 11:24 #13014FélixBlockedHi @outtt,
there is a little tutorial here about that but basically:
– nodesToReduce : path to the node we want to reduce in our scene
– listObjToAnimate : here we want specify with which components we will shake our model to do the reduction and with which parameters.
– ObjToAnimate : with ObjToAnimate we can specify an animation, here we want to pull with a CableConstraint with an increment of 1 each 5 steps until 5 -> (“M1/cableNode”, incr=1,incrPeriod=5,rangeOfAction=5)
Giving him only the path to a node (here M1/cableNode) it will search in it an actuator to control (here CableConstraint).– addRigidBodyModes : finally this argument indicate if our reduced model will be fixed ([0,0,0] -> without any translation) or if it will be able to translate and along which axes.
For the windows path I just made some fixes to (normally) correct that for the script modelOrderReduction.py… But I find there are some issues with the sofa-launcher when I launch the reduction examples (diamondRobot.py) that I will try to correct for the end of this week with also fixes to the GUI part.
Sorry for all the trouble but you are our first windows user.
Hopes this helps !Félix
8 February 2019 at 14:43 #13016FélixBlockedHi @outtt,
I just finish to test & fix the different problems, so now it works both for the script and the GUI normally, at least for the diamondRobot & hexaBeam examples which I have tested but the quadruped_snapshotGeneration.py doesn’t seems to work and I don’t know (yet) why…
You can now try it out again if you want.
Just a precision for the hexaBeam example its :
nodesToReduce =‘/M1’Félix
12 February 2019 at 08:45 #13027WongBlockedHello @felixvanneste,
I just tried your new updated MOR and it still has some compile issues on my platform.
Well,
#include <SofaGeneralSimpleFem/TetrahedralCorotationalFEMForceField.inl>
and
#include <SofaMiscFem/TetrahedronHyperelasticityFEMForceField.inl>
should be respectively added in HyperReducedTetrahedralCorotationalFEMForceField.cpp and HyperReducedTetrahedronHyperelasticityFEMForceField.cpp.It is the solution.
And I want to ask two questions.
1) How can I add FreeMotionAnimationLoop into the liverFine.pyscn?
I tried to add FreeMotionAnimationLoop and GenericConstraintSolver and GenericConstraintCorrection into the scene, and then directly launched the modelOrderReduction.py.
But the generated reduced_test.py did not work properly. So what is the problem?
2) Can the reduced model be used for force feedback interaction, for instance, in a Geomagic scene? If it can, could you give me an example?
Thanks
Wong12 February 2019 at 17:19 #13028olivierBlockedHello Wong @outtt,
First of all, well done if you solved some compile issues and got the plugin to compile for your computer.
About your two questions:
1) Could you give us your modified version of liverFine.pyscn? In principle, there is no reason why this should not function.
2) About using the MOR plugin in a scene with haptic feedback.
To be honest, we have not tried yet, but it should be working as it stands. An optimised version of the haptic loop when used with an FEM model reduced with the plugin could be implemented in the future however.Let us know!
Olivier13 February 2019 at 03:11 #13029WongBlockedHello @olivier-goury
I have shared the scene file. You can use it to have a test.
https://www.dropbox.com/s/thogel4vp0av3o2/liverFine2.pyscn?dl=0Wong
14 February 2019 at 17:19 #13040olivierBlockedHello @outtt,
I am coming back to you. I modified your scene slightly and it is working now. Check the scene following the link: https://pastebin.com/fRQmKFmaThe reduced scene generated will not contain what you added in your rootnode (FreeMotionAnimationLoop, GenericConstraintSolver), but can just edit the reduced scene generated and add it.
Please try it and see if it works on your computer.Best Regards,
Olivier15 February 2019 at 03:46 #13041WongBlockedHello @olivier-goury,
I tried to modify the scene:
https://www.dropbox.com/s/eslf3emvc8mmy8o/reduced_test2.py?dl=0But it seemed that the HyperReducedRestShapeSpringsForceField reducedFF_liver_2 could not fix.
Was it normal?
Wong
15 February 2019 at 10:32 #13044olivierBlockedHello @outtt,
Yes that is normal because the reduced scene does not include the node “actuator”, with the mechanical object “actuatorState” by default (you removed the “external_rest_shape” link in “HyperReducedRestShapeSpringsForceField” ?). If you want to keep it in the reduced scene you also need to add it:
actuator = rootNode.createChild('actuator') actuator.createObject('MechanicalObject', name = 'actuatorState', position = '@'+boxActuation.getPathName()+".pointsInROI", template = 'Vec3d')
Olivier
-
AuthorPosts
- You must be logged in to reply to this topic.