[Froy]

Hello @Scheikl,
1 – You may have a look at the picking part (i.e class PickHandler) where raycasting is used to identify one pixel = one state. But it could be expensive in your case I suppose. One other idea (I think it was implemented in the past but I dont really remember why it was not used anymore) is to draw your meshes each with a different color, get back the color buffer (with a FBO) and read the pixels (where you can do the mapping color = object).
2- We dont do that in SOFA but I suppose the easiest way would be to get the modelview and the projection matrices, and then use those to get the NDC of your positions and test if (X,Y) is [-1, 1].

Fred

[Froy]

Hello,

This problem is due to an update of pybind (I am expecting you to have a recent version of pybind, i.e > 2.8).
This is fixed in this PR https://github.com/sofa-framework/SofaPython3/pull/216
You can also fix it by downgrading your own version of pybind.

Fred

[Froy]

Hello @jonny,

I tried to create a very simple textured mesh in Blender, and it seemed there was no problem doing Blender -> SOFA. But it is (very) possible that the example is TOO simple 🙃.
If you want to see/try my test: https://filesender.renater.fr/?s=download&token=064d8e75-9d7d-42c4-913f-5f74a93249f4
(Link valid for 1 month, i.e until the 14th of November approx)

As for the OBJExporter, it seems there is a problem where with the number of normals/texcoords wrt the vertices (probably due to the fact that vertices are duplicated when there is texcoords). It is already on our extended schedule to rewrite this component, as it is not really reliable.

Best regards,

Frederick

[Froy]

Hello,

Few hints I would look to find the problem:
– texture coordinates are wrongly loaded, maybe a discrepancy between Blender and SOFA?
– the faces are flipped (and normals are backwards).
You can try to see if this is the 2nd case by simply flipping the normals in the mesh loader (flipNormals="true").
If it is about the texcoords, you can play with the scaleTex parameter in OglModel (for example, scaleTex=”-1 0″ will mirror the texcoords on X axis)
Keep us in touch if it solves the problem (or not)…

Fred

[Froy]

Great @Brunob81hk,
Keep us in touch, it will be interesting to see your results 🤠

++
Fred

[Froy]

Hello @brunob81hk

– if runSofa reports that it cannot find the gui “glfw”, it would mean that the plugin has not been loaded. You may want to force loading it while running runSofa, with this command runSofa.exe -l SofaGLFW .....
– where do you call initTrexUI() ? This is important as the BaseObject::init() is not supposed to be enclosed in a OpenGL context. In BaseObject, only draw() has an OpenGL context, for debugging purpose usually.

I would advise you to make your component inheriting VisualModel, as this abstract class is more suited for “custom” draw commands. This comes with initVisual() (init things like vertex buffer, etc), updateVisual() (update buffer, vbo stuff like that) and drawVisual(calling draw commands). In your case, I would call initTrexUI() in initVisual() and drawTrexUI() in drawVisual()

[Froy]

@jnbunet

I cannot really see well on the screenshot (the pipe is a bit far from the camera 🧐) but seems like there is a problem with depth; maybe depth testing is disabled ? (i.e a glEnable(GL_DEPTH_TEST); is missing)

[Froy]

Hello,

It seems that this issue was fixed in the master branch, so two solutions (again)
– you compile by yourself the current master (could be bothersome)
– a new release will be available very soon so if you could wait a few days… 😉

Sorry for the inconvenience!

[Froy]

Hello,

it seems you dont have ffmpeg (or at least SOFA does not know where it is).
With the SOFA binaries, you have 3 ways:
– put ffmpeg.exe in the same dir as runSofa.exe
– add the path of ffmpeg.exe into the PATH environment variable.
– edit the file plugins/SofaGuiQt/etc/SofaGuiQt.ini and modify the value of FFMPEG_EXEC_PATH

(Here is a link where to get binaries for ffmpeg: https://www.gyan.dev/ffmpeg/builds/ if you dont want to compile it yourself.)

We realized that there is nothing in the doc about ffmpeg, so we will update the doc accordingly.

[Froy]

Hello, I got the same error few months ago:

and I set up an issue for a short explanation: Issue1716

The registry thing did solve the issue on my setup. (Win10 20H2)

If it really does not help, a commit has been implemented starting from v20.12.01 to shorten paths.
Could you tell us what is your syntax error when you try to compile v20.12.01 ?

[Froy]

Hello @amendiza,

First thing first, your problem seems to be located while using the so-called “OpenCVPlugin” which seems to be a private plugin of yours.
In such cases, it is hard for us to provide appropriate support.

From what I know, it seems the draw() in OpenCVProjectivePointSelector is conditioned with
if (f_listening.getValue() && d_draw.getValue())
Did these two Data are true while executing with Python3 ?

As stated, this plugin is purely private to your team and not really useful for the whole SOFA community so it may be more appropriate to ask those questions in an other medium. (your team’s gitlab for example?)

[Froy]

Hi,

I stumbled on this bug myself yesterday 😤, and it should be fixed with the PR #1698. (hopefully it will be quickly merged in the master branch)

[Froy]

The current implementation in the GUI does not allow to change the resolution of the output (either for the video or the screenshots actually) and it takes the current size of the widget. 😕
The recording function itself does allow any custom size, so it should not be difficult to add fields in the GUI, and feed it in the function.

[Froy]

2-3 weeks ago, a PR related to this issue has been merged.
https://github.com/sofa-framework/sofa/pull/1615
It may solve this error. 🤔

[Froy]

No idea; can you tell us the version of SOFA ? (master, release, etc)

[Froy]

First time I see this error 😅
According to the code, PluginManager calls the function
getModuleName()
from your plugin (without checking if it is defined by the dll 😑).

So I suppose there is a problem with this function in your plugin (not defined ? nullptr?)

[Froy]

According to the demangler,
You would need the definition of

sofa::component::topology::NumericalIntegrationDescriptor<float, 3>::getQuadratureMethod(sofa::component::topology::NumericalIntegrationDescriptor<float, 3>::QuadratureMethod, unsigned long) const

And this NumericalIntegrationDescriptor is currently only compiled with double (BaseTopology/NumericalIntegrationDescriptor.cpp)

Therefore, you will need to add the templated definition with

#include <SofaBaseTopology/NumericalIntegrationDescriptor.inl>

to be able to instanciate with new templated class with float

[Froy]

For your first error, please give some more information from your class NonFoldingTetrahedralConstraint
But 🧐:
– there is no more compilation (by default) of Vec3fTypes (no more #ifndef SOFA_DOUBLE …)
– SofaComponentBase has been renamed one or two releases ago (?), now this package is called SofaBase. So you will need to link against SofaBase (instead of SofaComponentBase)

[Froy]

My advice would be:
– first start with the defaults choices
– build successfully 🧐
– add/remove other options later on, to play with them

[Froy]

Hello,

Is there any need for GuiGlut and SofaHAPI ?
Those two plugins/applications are not supported anymore and nobody is taking care of them.
-GuiGlut is creating a GUI using Glut (a really old framework for creating GUIs with OpenGL)
– SofaHAPI is (was?) created to support haptics devices if I remember well.

I am really not surprised those two do not compile anymore 🤐

[Froy]

There is no documentation right now on how to add a new Type for MechanicalObject.

What I can tell you from your linking error is that you need to include sofa/core/State.inl, as this file defines your missing symbols.
I suppose you did somewhere an instanciation like MechanicalObject. As MechanicalObject inherits State, it will the implementation in State.inl (you can see that State.cpp does an explicit instanciation on all standard datatypes).

In any case, we appreciate your feedback and we are considering on writing a how-to on how to add a custom datatype in the future.

[Froy]

Hello,
There is no doc on this because it was not really intended to changeable easily, but could be a good idea to make it .
Anyway, I never really created a new “type” as Vect3Types or Rigid3Types (types instanced with MechanicalObject) but as I could see rapidly, your new “type” needs to implement some conditions/types/functions. For example it has to implement on what is a Coord, what is a Deriv, etc (see the lists of typedef in MechanicalObject.h).
It could be great also to know if you are starting from scratch; or if you already implemented some things and you are stuck on some technicalities.

[Froy]

Hello,

Fixing this plugin is not that simple, as it seems that nobody was compiling for a few years (let alone using it).
I have spent some time to make it work somehow (compile + example scene with quadspring) in VS2019.
The PR is yet to be integrated into the master branch but if you want to test it nevertheless, you can fetch my branch on my repo:
https://github.com/fredroy/sofa/tree/opencl_compile_20_06

(NB: I dont know OpenCL that much so if there is any problem in the CL kernels… I will be unable to help 😅 )

[Froy]

(I am not related with the sofa-framework website, nor the binaries from there)

Can you try to execute the binary directly, i.e

$ /Applications/runSofa.app/Contents/MacOS/bin/runSofa

in a terminal ?

[Froy]

Hello,

Did you compile your own version? or do you try to launch the compiled runSofa.app from the sofa-framework website ?

I am on OSX 10.14.6 and the (downloaded) .app seems to work on my side, either by double-clicking it or by executing the command
$ open -a /Applications/runSofa.app

[Author]

Posts