[SOLVED] Bindings python for new data types

[Bruno Marques]

Hi!

I am implementing python bindings for a new data type (Opencv matrices), and looked into the image plugin and SofaPython’s bindings for inspiration, but didn’t succeed.

I also implemented this little test scene to check that my bindings work, that looks like this:

https://pastebin.com/cA3NQTJT

With my current implementation (that I will detail further), I get the following error messages:

on pastebin.com: https://pastebin.com/Hs1v6f5U
It seems to me that there are 2 issues here:

1. The warning shows that despite my implementation of the bindings, it still falls back to the base implementation of the BaseData Python bindings.
2. The Python object retrieved, on which getPtr() is then called, is of type str (since BaseData returns a PyString when not recognising a native Sofa type), which of course doesn’t have my custom method, and causes the crash.

Concerning the code:

CMakeLists.txt: https://pastebin.com/rVug1Unx

My sofa data is of type sofa::Data<cvMat>. It is a simple wrapper over the cv::Mat class from OpenCV, with overloaded stream operators. DataTypeNames and DataTypeInfos structures are also implemented here. The content of cvMat.h:

cvMat.h ( https://pastebin.com/EBkwEY4A )

The Binding_cvMatData.h ( https://pastebin.com/W7ZDmd5A ) is a bit more complex:

Finally, the content of __init__.py ( https://pastebin.com/2fVrfaJA )

I apologise for the length of this post. I used pastebin to refactor it a bit But I don’t think I can be more succinct than that…

I’m looking forward to your answers! My code is very similar to the image Plugin’s bindings, yet it doesn’t work. I ran out of ideas to fix this, and hope you’ll see where I went wrong.
Thanks in advance!

[lionel]

Take a look into the compliant and flexible plugins. I think you will find python bindings for new types and for Eigen matrices

[Bruno Marques]

Hi Lionel,

Thanks for your input!
I did that too. There are bindings for AssembledSystem in the compliant plugin, that is slightly different (it has a constructor and destructor, which uses a different SP_* macro.
But fundamentally, the implementation is the same:

1. a SP_DECLARE_TYPE(MyPythonType)
2. multiple static methods for python with the signature static PyObject* MyPythonType_methodName(PyObject*, PyObject*)
3. same for attributes accessors, ctors and dtors if any

4.

SP_CLASS_METHODS_BEGIN(MyPythonType)
SP_CLASS_METHOD(methodName)
[...]
SP_CLASS_METHODS_END

5. same for attributes, ctors, dtors etc if any

6. SP_CLASS_TYPE_BASE_PTR(MyPythonType, MyCppType) or other variants {ATTRS,NEW_FREE,…}

My implementation seems to be respecting this declaration structure, but something is missing, and I can’t find out what… :/

[Bruno Marques]

Alright!

We ended up finding what was missing.
Whiile my new class type was well declared, it wasn’t registered to the PythonFactory, which handles the lookup of typenames to find out if the BaseData* object provided could be downcasted.

In order to get the new type registered, a call to SP_ADD_CLASS_IN_FACTORY(cvMatData, sofa::Data<sofaor::common::cvMat>) must be done when initializing the plugin.

a function is present in most plugins, called initExternalModule(). This function is used for any external modules, such as plugin widgets for the new GUI (runSofa2) or SofaPython’s Factory.

Here’s the final implementation of this method in my plugin, as an example:

void initExternalModule()
{
  static bool first = true;
  if (first)
  {
    first = false;
#ifdef QT_PLUGIN
    initResources();
#endif  // QT_PLUGIN
#ifdef SOFA_HAVE_SOFAPYTHON
    if (PythonFactory::s_sofaPythonModule)
    {
      simulation::PythonEnvironment::gil lock(__func__);

      // adding new bindings for Data<cvMat>
      SP_ADD_CLASS_IN_FACTORY(cvMatData, sofa::Data<sofaor::common::cvMat>)
    }
#endif
  }
}

I close the topic!

[Author]

Posts