TopoDS_Shape from a pointer?

[jf---]

Would it be possible for pythonocc to get a TopoDS_Shape from a pointer?
This would encourage experimentation from other OCE related projects.

I do realize this would open the gate for segfault hell probably 🙉

[tpaviot]

What do you mean with "get a TopoDS_Shape from a pointer" ?

[tpaviot]

@jf--- can you please detail what you expect from this issue report ?

[jf---]

Sure, the being able to send / receive a pointer to a TopoDS_Shape from another dylib would encourage interoperability with other OCC / OCE related projects.

A practical example: the IfcOpenShell ( IFC is the STEP/Express format for the building industry ). As OCC has a STEP import mechanism, this has been extended to IFC. So, something really powerful. Now, the outcome of this process is a TopoDS_Shape. Which has to be serialized before being able to make use of that in pythonocc. Being able to send a pointer would be pretty cool. I know that its an architecturally really gross idea though ;)

This idea of course can be generalized but I think it could contribute to interoperability, between the various OCC projects. The other lowest common denominator would be serializing I guess.

This begs the question to, how I could extent a project like IfcOpenShell to be interoperable with pythonocc? How do I expose the TopoDS_Shape such that I can utilize these in pythonocc?

[tpaviot]

I have no idea if it's possible to share objects between applications using this mechanism. It's a c++ issue, I'm afraid my skills in this area aren't enough to answer this question. The serialize mechanism works quite well, and at some point it's safer, since applications does not share a common memory space.

[jf---]

True. So could you please comment on how to extent something like IfcOpenShell to pythonocc?
In a sense you would be creating / extending the pythonocc wrapper concept.

[tpaviot]

@jf--- Here is a blogpost for working with both ifcopenshell/pythonocc http://blog.ifcopenshell.org/2014/12/combining-ifcopenshell-and-pythonocc.html

[jf---]

Yeah, really cool right...
So the thing is that moving TopoDS_Shape from ifcopenshell -> pythonocc is handled by serializing them. I'm kind of curious if we can create those instances from a pointer?

I guess the underlying question really comes down to how one extends the pythonocc wrappers.
That would be the right way to bind these projects closer together, since ifcopenshell effectively is generating SWIG wrapper code for exactly the same entities. That creates fragmentation and a friction while I think these projects should work hand in hand.