[Julien D.]

Hello everyone,

On my side, all the SoifaPython3 and Sofa v21.06 installation on Windows 10 are solved !

@NerioDev , if you are still using Sofa, I recommend you to try out the solution, proposed by akTheTimes, it works perfectly fine for me.

Best wishes

[Julien D.]

Hey everyone,

Installing pybind11 version 2.8.0 instead of 2.8.0 works, I could install succesfully sofaPython3 in tree with Sofa version 21.06. Everything is working !

Thank you very much again @Froy 🙂

For me, this topic is resolved uwu.

[Julien D.]

Hello @Froy,

ok, thank you, I’ll try that very soon (not today but soonie) and I’ll keep this forum in touch 🙂

Thank you very much for your help !

Julien

[Julien D.]

Okie, so to install Sofa21.06, I have copied the files SofaBase.lib and SofaGui.lib from the binaries of sofa to my sofa/build folder.

It allows me to finish compiling sofa successfully !

However, when I try to compile SofaPython3, I also have to add SofaPython3.lib to sofa\build\lib\release and Core.lib in ..\sofa\build\lib\python3\site-packages\Sofa\libraries. But when I do this very last operation, I have lots of errors like

Erreur	LNK2019	symbole externe non résolu "__declspec(dllimport) void __cdecl sofapython3::PrintTo(struct sofapython3::PythonTestData const &,class std::basic_ostream<char,struct std::char_traits<char> > *)" (__imp_?PrintTo@sofapython3@@YAXAEBUPythonTestData@1@PEAV?$basic_ostream@DU?$char_traits@D@std@@@std@@@Z) référencé dans la fonction "public: virtual void __cdecl testing::internal::ParameterizedTestSuiteInfo<class anonymous namespace::Sofa>::RegisterTests(void)" (?RegisterTests@?$ParameterizedTestSuiteInfo@VSofa@?A0x5ffb74db@@@internal@testing@@UEAAXXZ)	Bindings.Sofa.Tests	D:\Utilisateurs\jducrocq\Documents\Librairies\sofa\build\applications\plugins\SofaPython3\bindings\Sofa\tests\PythonModule_Sofa_test.obj	1	

which i don’t understand at all !

I also still have the same error

Erreur	C2011	'pybind11::attribute_error' : redéfinition du type 'class'	Bindings.Sofa.Core	D:\Utilisateurs\jducrocq\Documents\Librairies\sofa\src\applications\plugins\SofaPython3\bindings\Sofa\src\SofaPython3\Sofa\Core\Binding_BaseData.cpp 37

which I don’t know how to solve either.

I hope that my experience would help others facing similar issues.

Have a great day !

[Julien D.]

Hello you all,

I’ve tried to install sofa v21.06 on another computer that the one I’m using right now, with Windows 140 and using Visual Studio 2019 too !

I am going to try right now the solution proposed by @akTheTimes.

I also have an error while building in-tree sofaPython3 on Sofa v21, with still mission library files and also I have a pybind11 atritbute error.

Have a good day

[Julien D.]

Hey @Hugo

Yes I think you’re right, you can close this topic.

Thank you very much for your help and advices,

Best whishes,

Julien

[Julien D.]

Hiii @matriatirindelli, I had exactly the same error when trying to initialize the GUI in a Python3 interpreter ! Thank you so much for your hints to solve this issue.

[Julien D.]

Hello, I am NOT using Sofa 21 but Sofa 20.12 on Windows 10, so I dont have the same exact config as you, but perhaps my answer could help you to solve your issue.

After I’ve compiled IN-TREE the sofaPython3 plugin, when I executed -runSofa and went to the pluginManager to add the SofaPython3 plugin, I add an error loading the plugin: sofa was complaining that it did not find the folder sofa/build/bin/python3 .
Actually, this folder did exist but was automatically placed in sofa/build/python3.
So, to solve this issue, I just copied this folder to sofa/build/bin. And now, sofaPython3 is working perfectly, and I’ve been able to write my own scene already 🙂

I hope my experience had helped you.

Have a good sunday,

Best wishes,

Julien

[Julien D.]

Hello @Hugo, I

I’ll try to do one of those options, but the issue is probably more on the mathematical definition of the faces normals of a regularGridTopology than a code issue.
It’s more a thing like “do we want the faces normals to point inwards or outwards” ?
In my case, i would have liked them to be computed outwards, but perhaps some others would prefer them inwards so I don’t know if this is really an issue.

However, thanks to the awesome explanations of Damien I’ve understood that the vertices normals were poorly calculated, in my case, because some faces normals of my regularGridTopology were pointing inwards and others were pointing outwards.

Best wishes,

Julien

[Julien D.]

As an example, my scene :

<?xml version="1.0" ?>

<Node name="root" dt="0.1" gravity="0 0 0">
    <RequiredPlugin pluginName="SofaSparseSolver"/>
    <RequiredPlugin pluginName="SofaOpenglVisual"/>
    <RequiredPlugin pluginName="SofaMiscCollision"/>
    <RequiredPlugin pluginName='SofaBoundaryCondition'/>
    <RequiredPlugin pluginName='SofaGeneralDeformable'/>
    <RequiredPlugin pluginName='SofaImplicitOdeSolver'/>
    <RequiredPlugin pluginName='SofaLoader'/>
    <RequiredPlugin pluginName='SofaMiscFem'/>

	<VisualStyle displayFlags="showBehavior hideVisual hideCollision" />

	<EulerImplicit name="cg_odesolver" printLog="false" />
	<CGLinearSolver iterations="25" name="linear solver" tolerance="1.0e-9" threshold="1.0e-9" />
	
	<!-- define variables to reuse several times -->
	<MeshGmshLoader name="export_filename"  filename="C:/Users/jducr/Documents/Developpement/Sofa_ws/scenes/exports/membrane_7x7_quads"/> 
	
	<!-- The object to export -->
	<Node name="MyLittleObject">

		<MechanicalObject name="mo"/> 
		<UniformMass vertexMass="0.2" />
		<RegularGrid name="hexaGrid" nx="8" ny="8" nz="4" xmin="-10.0" xmax="10.0" ymin="-10.0" ymax="10.0" zmin="0" zmax="0.50"/>
		<HexahedronSetTopologyContainer name="Topo" src="@hexaGrid" />		
		<HexahedralFEMForceField name="FEM" youngModulus="1e13" poissonRatio="0.3" method="large" />
		
		<!-- Visual node to allow the exportation -->
		<Node name="VisualNode" >
			<OglModel name="Visual" color="green" />
			<IdentityMapping input="@.." output="@Visual" /> 
		</Node>
		
		<!-- <OBJExporter name="export_OBJ" filename="@../export_filename.filename"  exportAtBegin="true" exportEveryNumberOfSteps="0" /> -->
		<MeshExporter name="export_GMSH" filename="../exports/membrane_7x7_quads" position="@Visual.position" edges="@Visual.edges" triangles="@Visual.triangles" exportAtBegin="true" exportEveryNumberOfSteps="0" format="gmsh"/>
		
	</Node>
	

</Node>

[Julien D.]

Hey @Hugo,

I prefer being honest and say that I am NOT an expert regarding SOFA code, I barely understand it.
And I’m a beginner regarding git world and all of this, so I know what a Pull Request is but I’m not qualified enough yet to do it myself. More qualified people in SOFA code should modify the SOFA code if it need to be done.

Anyways, I have discussed this issue with Damien and a few others on Defrost team, and it came out were the issue “mathematically” came from. On regular grid topologies, the normals of the faces are oriented to the exterior or the interior of the mesh. Therefore, the normals of each vertex, which are an interpolation of the normals of the faces, are calculated wrong.

As a simple scene, you can just place a regularGridTopology component of any size in an empty scene, with a visual model being itself, and visualize its normals. If you export this models with the OBJExporter and visualize the model and display its faces normals, you’ll see the issue.

If he doesn’t mind, if think that you should ask @Damien from Defrost Team to give you more details about this, Hugo.

[Julien D.]

Everyone the issue is solved !

So actually, the only issue from Sofa is that it doesn’t calculate the normals of regular grids properly.
For a regular grid, some normals of edges point outside and some point inside of the volume, therefore the interpolated vertex normals are wrong.

Then, to calculate the normals properly, you do your geometric mesh on Blender (which I have done) and you make sure to recalculate the normals outside (very easy to do in Blender).
When the mesh is deformed, the normals stay well calculated.

Many thanks to @youness and @damien for their help !

[Julien D.]

Okie guys, we learn something every day, right ?
So today I’ve learnt that according to the model considered by SOFA (mechanical or visual, for instance), the normals aren’t the same at all !
You can compare by your own eyes the normals calculated from the FEM models (in red, green and blue) and the normals computed from the visual models (in white). The last ones are wrong while the others are good.

PS : I have an issue to send the image, so here’s the link

image

[Julien D.]

Okie guys, we learn something every day, right ?
So today I’ve learnt that according to the model considered by SOFA (mechanical or visual, for instance), the normals aren’t the same at all !
You can compare by your own eyes the normals calculated from the FEM models (in red, green and blue) and the normals computed from the visual models (in white). The last ones are wrong while the others are good.

image

(I don’t know how to set up images properly here so I’ve also put the link above)

So there’s a transformation between the axis of VISUAL and mechanical models. It’s very strange.

Have a good night/day

[Julien D.]

Hi @younessss , thank you a lot for your help 🙂

I’m gonna try it as soon as possible.

Have a great day 🙂

[Julien D.]

Thank you @jnbrunet 🙂

[Julien D.]

Hello, I don’t know why but the images cannot be displayed, even though I’ve used the proper tool and copied the links in my previous post…

So basically the normals displayed in SOFA are properly perpendicular to my planar surface, but they are not anymore after I’ve exported the mesh from SOFA and re-imported it either on Unity or on Blender.

However I’m getting on holidays, so I might be slower to answer too.

Thank you in advance for your help 🙂

[Julien D.]

So, to complete, here is the SOFA mesh with a top and side views, displaying the vertex normals in green :

Second image :

And here are the face normals, which are well rendered by Blender (and are correctly estimated) :

And there the vertex normals which are not properly calculated :

The normals data in the .obj file (vn) are effectively wrong and correspond to what is displayed in Blender. So the issue comes from the OBJExporter component and not from the mesh import on Blender (or Unity).

Thank you in advance for your help 🙂

[Julien D.]

Have you installed Qt properly? If I remember right, you have to install Qt (from the unified installer or any other) and add the location of your files FindQtXXX.cmake to your PATH. You can try that but I’m not sure it will 100% solve your issue. Hope that helps anyways.

Best wishes

[Julien D.]

Hey @Jake,

I faced the same problem a few weeks ago… But the members of the SOFA community helped me a lot ^^

So, if you have properly unzipped the WIN_dependency folder, you have to add several lines to your CMake file to detect all these dependencies properly.

First,

set(CMAKE_PREFIX_PATH ${LIBRARIES_PATH}/sofa/build/install/)
set(CMAKE_MODULE_PATH ${LIBRARIES_PATH}/sofa/src/cmake/Modules)

allows CMake to find the XXXtargets.cmake files of SOFA and the dependencies’ cmake files.

Then,

set(GLEW_INCLUDE_DIR ${LIBRARIES_PATH}/sofa/src/include)
set(GLEW_SHARED_LIBRARY_RELEASE ${LIBRARIES_PATH}/sofa/src/lib/win64/glew32.lib)

allows CMake to find the files required for GLEW.

Be careful to set ${LIBRARIES_PATH} to the root of your libraries folders.

Best wishes,

Julien D

[Julien D.]

Hello gliu,

A few weeks ago, I wanted to try the tutorials examples on the SOFT Robot plugin and I had similar issues… It seems that the STLIB plugin have to be installed through Python.

I have no clue how to solve this issue either, so if anyone has a solution feel free to share.

Best wishes to everyone,

[Julien D.]

I solved this isssue, it was just that I needed to add an environment variable to my PATH to use my files compiled with VISP.
So I can compile my plugin completely on one of my computer using Windows 🙂

However, in the second Windows computer I’m using, I still have another compiler CXXX errors even after having added the #define WIN32_LEAN_AND_MEAN to my config.h file.

These errors are not a priority to solve, since I can compile the plugin in a computer, I can still export the dlls to use them in the other one.

However, if I solve this little issue or if anyone find a solution, feel free to share it 🙂

Have a good end of day everyone 🙂

[Julien D.]

Hello again,

so I’ve added the line #include <SofaBaseTopology/TopologySubsetData.inl>
to the file config.h of my plugin.

And it worked ! I could go up to the generation of my plugin and got MyPrettyMirror.dll created without anymore issue 🙂

However, when I tried to import the plugin thanks to the plugin manager of SOFA, I add the following error [ERROR] [PluginManager] Plugin loading failed (D:/Utilisateurs/jducrocq/Documents/Librairies/sofa/build/plugins/MyPrettyMirror.dll): Le module spÚcifiÚ est introuvable.

I tried to copy my dll to the sofa/build/plugins but it is not working…
I also tried to compile it in both debug and release mod, without any more success…

Thanks again for your help, all 🙂

[Julien D.]

So thanks to @Guillaume , I solved these issues by adding the line

#define WIN32_LEAN_AND_MEAN to my file config.h

Now I have Linkers errors, which comes from the fact that I did the plugin on SOFA v19.04 and now want to move it to v20.12.

EDIT: I also had to set my C++ compile option in Visual Studio to /std::c++17 in Visual Studio.

I have to include inline files from SOFA to solve this error, according to Guillaume. I’m trying that and keeping you in touch. Hope that this post will help someone else someday 🙂

[Julien D.]

Hello everyone

Thanks to Guillaume and Hugo’s advices, I moved forward and almost solved the error.
During the SOFA installation, I forgot to compile the INSTALL project. Compiling this project placed all the files TargetsXXX.cmake inside subdirectories of sofa/build/install.

By setting CMAKE_PREFIX_PATH to the root path of the TargetsXXX.cmake files, my CMake configuration is working out nicely. However, after the configuration and generation steps on Cmake have been done, I have other issues of type
Erreur C2011 'sockaddr' : redéfinition du type 'struct'
and
Erreur (active) E0484 déclaration d'instanciation explicite non valide MyPrettyMirror D:\Utilisateurs\jducrocq\Documents\Developpement\Sofa_workspace\MyPrettyMirror_win\share\BorderForces.h

About to try solving it with Guillaume.

Thanks for your help, again

[Author]

Posts