New Py method of Part.Shape - generalFuse

Info about new community or project announcements, implemented features, classes, modules or APIs. Might get technical!
User avatar
Posts: 6523
Joined: Fri Aug 29, 2014 12:45 am
Location: Saint-Petersburg, Russia

New Py method of Part.Shape - generalFuse

Postby DeepSOIC » Mon Jul 04, 2016 11:51 pm

New method was recently added to Part.Shape. The method is called "generalFuse", it does what in OCC is called "general fuse operator", or "general fuse algorithm" (GFA). It is the generalized version of all Boolean operations, and Fuse, Cut and Common are just simple post-processing of the output of GFA.

generalFuse takes a list of shapes as input, and outputs a tuple of two: (result, map). Result is a compound of all shapes that result from intersecting and splitting the input shapes. Map is the list of lists to identify, what pieces stored in result belong to which input shape.

Example: feeding two spheres outputs a compound of three solids. Note that the faces and edges that the pieces share are actually shared, so valid compsolids can be made from the output of generalFuse.
I have split the compound apart to reveal it.
GFA-2.png (225.83 KiB) Viewed 849 times
Some potential applications of the algorithm are:
* making CompSolids
* custom BOP-like operations, like Connect (I plan re-implementing Connect to take the advantage of GFA, which will probably make it as fast as a single BOP - now it is about 5 times slower than a single BOP).
* maybe a new, more efficient solution for generating mosaic set of faces from intersecting edges
* switch on your imagination and invent some other use ;)

I didn't test, how does generalFuse react to feeding in various non-solid geometry, but from OCC manual it seems that any combinations of shape types are supported.

Note. generalFuse requires OCC 6.9.0 or later.
Note2. I haven't found a nice way of joining pieces obtained from generalFuse. Curently, for joining solids, I have extended Part.Solid() constructor to accept CompSolid as input (it will join the compsolid into one solid). So, to emulate fuse method, run generalFuse, then convert result to CompSolid, and then to Solid. I will expose a better way as a separate method if I find one.
User avatar
Site Admin
Posts: 11034
Joined: Tue Feb 17, 2009 9:16 pm
Location: São Paulo, Brazil

Re: New Py method of Part.Shape - generalFuse

Postby yorik » Tue Jul 05, 2016 12:09 am

Great! I haven't explored much the concept of compsolids yet, but it might be interesting for building design... Lots of things could benefit from this compsolids <-> solids workflow...
User avatar
Posts: 179
Joined: Sun Feb 16, 2014 12:05 am
Location: Far side of the moon

Re: New Py method of Part.Shape - generalFuse

Postby Pauvres_honteux » Tue Jul 05, 2016 5:15 am

Hi DeepSOIC, while trying to interpret "generalFuse" I started thinking about, what I think is, something similar in the big french program.
There there is a, from user perspective, a function called "join" which does just that. The thing with this function is that it treats everything as one object and they do not need to be connected. However, the vast majority are using it as a "bundler" with the added benefit of checking for connectivity and tangency and/or c3 blends. As you have figured out by now it only operate on things NOT solid.

Having the above in mind I'm wondering if this "generalFusion" is intended to be used in a similar fashion but for ALL objects?
And, will it be possible hold these object together without them touching each other while treating them as one object from the following operators/functions point of view?

E.G. to cut all contact surfaces on a casting one usually makes a lot of "cut surfaces" and bundle them together with the function "join" (n.b. these surfaces are not intended to be connected, can be connected but more likely crossing each other) to able to make one operation/cut sometime later on in the tree. This due to surfaces and solids beeing kept separated in the tree.