Comparison CREO / Openscad / CadQuery

[bragostin]

This is not an issue but information. I thought it would be of interest to the community so I put it here. So I made the same model (like #180 (comment) but more complex and with ~4000 parts in total) with CREO 5, Openscad and Cadquery. Here is the comparison:

Item	CREO 5	Openscad 5.2019	CadQuery 2.0
STL File size	462 MB	250 MB	341 MB
Render time	<1 min	~24 h	167 min
Holes	0	25516	4
Shells	206	4315	1

CadQuery produced the best quality STL in a still reasonable time for practical use. Of course to compare with CREO does not make much sense since CREO has no python capability.
The only real issue was #179 (comment), which prevented holes from being made at predefined coordinates. Overall CadQuery is a really awesome piece of work! I will be happy to contribute more usefully once I am more familiar with pythonOCC.

[dcowden]

@bragostin thank you for posting this!

Did you happen to try using oythonoc. Directly?

I am sure OCE can't match a commercial Cad kernel (parasolid probably), but there may be performance optimizations possible in cadquery. It might be nice to see what the fastest possible performance is using OCC libs directly.

[adam-urbanczyk]

Thanks for the comparison @bragostin . You could mabe shave off same STL generation time by playing with the export tolerance. For my understanding what is the meaning of the Shells value?

[bragostin]

@dcowden I am not familiar with pythonocc yet unfortunately, but I want to start looking into it. But it seems that such a comparison was made here #183 (comment)

@adam-urbanczyk without the STL generation it still takes 164 min, so that's not the main time consumer. It seems the union are.
Shells appear when 2 parts are not correctly joined so that an enclosed void appears. 3D printing softwares like Netfabb have holes/shells repairing capabilities, but it might work or not. Thus it's better to aim at 0 holes and 1 shell in the original STL.

[bragostin]

I have continued this study to try to optimize the CAD generation time. I have realized that in my model CREO does not perform any union, parts are just saved together, that's why it is so fast. So I used the same principle whenever possible with CadQuery, using

vals = []
for o in my_object.all(): vals.extend(o.vals())
my_object = cq.Compound.makeCompound(vals)

and a minimum of unions, and now execution is time is down to 45 mins.

[dcowden]

@bragostin cool, very interesting!

45 minutes is still a really long time but that's much better

[bragostin]

@dcowden to be fair, if I removed all unions, the execution time would be down to a few minutes, but then I would have to apply holes and cuts to all parts separately and that would be cumbersome. I suppose CREO does that automatically. Also, the union improves a lot the quality of the STL file by, I suppose, eliminating small holes. Then I my opinion 45 mins is worth the wait considering the obtained results.

[bragostin]

I worked on this comparison further. After replacing all unions by makeCompounds in my CadQuery model (holes are then made separately on each elements of the compound), the computation time goes down to a couple of minutes, very comparable to CREO actually. Reversely, when I tried to make the unions in CREO it crashed. So from a result point of view and for my specific needs I would rate CadQuery superior to CREO. Of course the resulting STEP file has holes and shells, but Netfabb, for example, repairs them nicely when importing the STEP file.

[dcowden]

@bragostin thank you for sharing this result!

[adam-urbanczyk]

Glad to hear @bragostin! I'm curious what the number is going to be with opencsacade 7.4.

[adam-urbanczyk]

@bragostin could you share the code or rerun on 7.4?

[bragostin]

@adam-urbanczyk
Here are the resutls:

Item	CREO 5	Openscad 5.2019	CQ OCC 6.9	CQ OCP 7.4
STL File size	462 MB	250 MB	341 MB	796 MB
Render time	<1 min	~24 h	167 min	30 min
Holes	0	25516	4	0
Shells	206	4315	1	1

Overall much better results: Unions 5.6 times faster, no holes. So better quality for 3D printing.
STL file is much bigger now, no idea why, precision was set to 0.01 in both cases. However after cleaning with Pymesh it reduces to 64 MB only.
So from my perspective it's much better so far.
What I have learned with this comparison is that Unions, unless trivial, are never going to be fast. However, most of the time, simple Compounds are sufficient.

[adam-urbanczyk]

Thanks, 5x speedup is not bad! Are those real unions or are you just gluing touching objects? If the latter is true, there might be additional speed-up possible with the glue mode of boolean ops (see #336 ). It is not exposed in CQ yet.

fop = OCP.BRepAlgoAPI.BRepAlgoAPI_Fuse()
fop.SetGlue(OCP.BOPAlgo.BOPAlgo_GlueEnum.BOPAlgo_GlueShift)

[bragostin]

This was run with normal Unions, so x5 faster is good indeed. I will investigate Gluing and compare. However Gluing requires flat parallel surfaces if I understand correctly, so some precautions must be taken when designing the parts, it cannot be a general workaround.

[bragostin]

@adam-urbanczyk
I have tested gluing:

Item	CREO 5	Openscad 5.2019	CQ OCC 6.9	CQ OCP 7.4	7.4 + Gluing
STL File size	462 MB	250 MB	341 MB	796 MB	791 MB
Render time	<1 min	~24 h	167 min	30 min	16 min
Holes	0	25516	4	0	0
Shells	206	4315	1	1	1

So I get a x2 speed increase.
In my case however, I have overlaping and slightly intersecting faces of many solids, so that to make Gluing work I had to use SetFuzzyValue at the same time as gluing. The tolerance value to use will depend on the degree of intersection. Would it be possible to have this option also in your PR #375?

    def fuse(self, *toFuse, glue=False, tol=1e-2):
        """
        Fuse shapes together
        """
        
        fuse_op = BRepAlgoAPI_Fuse()
             
        #TODO
        if glue:
            print("START GLUING")
            fuse_op.SetFuzzyValue(tol)
            fuse_op.SetGlue(BOPAlgo_GlueShift)
        # TODO

        rv = self._bool_op((self,), toFuse, fuse_op)

        return rv

N.B. In my case a significant amount of time is spent writing the output files, so the speedup due to gluing is probably larger.