Re: [Pythonocc-users] BRepAlgoAPI_Cut performance issues

Hi Charles,I made a rudimentary fix of your script.The memory magic ( I got 8GB and am feeling lucky ;) is most likely due to the boolean_fuse function using the .Destroy method )def boolean_fuse(shapeToCutFrom, joiningShape):    from OCC.BRepAlgoAPI import BRepAlgoAPI_Fuse    join = BRepAlgoAPI_Fu

Re: [Pythonocc-users] BRepAlgoAPI_Cut performance issues

Hi Charles, I've been working hard on this memory leaks issue. Here is a description on what's going on in your program. Let's take for example the two following lines: seg1 = OCC.GC.GC_MakeSegment(pnt1, pnt2) e1 = OCC.BRepBuilderAPI.BRepBuilderAPI_MakeEdge(OCC.Geom.Handle_Geom_TrimmedCur

Re: [Pythonocc-users] BRepAlgoAPI_Cut performance issues

Alas, the technique of merging 1 to 2, 3 to 4, and then (1,2) to (3,4), (5,6) to (7,8), ... and so on in parallel works, the memory requirements are huge. On a 64 GB memory machine, python-occ exhausts all available memory. The script is attached On Tue, Jun 22, 2010 at 11:10 AM, Charles McCr

Re: [Pythonocc-users] BRepAlgoAPI_Cut performance issues

Thanks! I was following the bottle example in which the thread is added to the bottle and came up with a similar solution. But how should I cut with the compound object? On Tue, Jun 22, 2010 at 8:27 AM, Fotios Sioutis wrote: > Below you can see a simplified code snippet from GEOM on how to creat

Re: [Pythonocc-users] BRepAlgoAPI_Cut performance issues

> Thanks for all of the very helpful suggestions. I've determined that creating > a thin slice, making the cuts on the thin slice, translate with copy 283 > times, then use multiprocessing with a map reduce algorithm to fuse the > slices together will be the fastest way to a solution (I haven't

Re: [Pythonocc-users] BRepAlgoAPI_Cut performance issues

Thanks for all of the very helpful suggestions. I've determined that creating a thin slice, making the cuts on the thin slice, translate with copy 283 times, then use multiprocessing with a map reduce algorithm to fuse the slices together will be the fastest way to a solution (I haven't verified th

Re: [Pythonocc-users] BRepAlgoAPI_Cut performance issues

I'm thinking of attacking this problem from a different direction. I could create a thin block with one transverse cut and 108 longitudinal cuts, copy this thin block 283 times and then sequentially fuse the thin blocks together. My thinking is that each fuse will be a simpler and faster operation

Re: [Pythonocc-users] BRepAlgoAPI_Cut performance issues

Thanks to all for helping out! Timing runs indicate that in this case, a cut with a compound object is actually slower than individual cuts. Is there any other way to make cuts on a box primitive other than using booleans? On Tue, Jun 22, 2010 at 8:40 AM, Charles McCreary < charles.r.mccre...@gmai

Re: [Pythonocc-users] BRepAlgoAPI_Cut performance issues

Thanks! I was following the bottle example in which the thread is added to the bottle and came up with a similar solution. But how should I cut with the compound object? On Tue, Jun 22, 2010 at 8:27 AM, Fotios Sioutis wrote: > Below you can see a simplified code snippet from GEOM on how to creat

Re: [Pythonocc-users] BRepAlgoAPI_Cut performance issues

Below you can see a simplified code snippet from GEOM on how to create a compound object. It is in c++ but i think it will not be so difficult to translate in python BRep_Builder B; TopoDS_Compound C; B.MakeCompound(C); for (ind = 1; ind <= nbshapes; ind++) { B.Add(C, aShape_

Re: [Pythonocc-users] BRepAlgoAPI_Cut performance issues

I've removed the display initialization until after all of the geometry calculations, not a factor in this case. The longitudinal cuts take ~10 minutes each! Thanks for the excellent suggestions. I don't think parallelization will work in this particular case, but I think that it will help in a va

Re: [Pythonocc-users] BRepAlgoAPI_Cut performance issues

> You can also speedup the slicing process by distributing the computation over > many cores (with the help of the multiprocess python module). Have a look to > the slides 17 and 18 of this slideshow: > http://www.pythonocc.org/resources/presentations_events/product-data-exchange-2009-conference

Re: [Pythonocc-users] BRepAlgoAPI_Cut performance issues

Hi Charles, You can also speedup the slicing process by distributing the computation over many cores (with the help of the multiprocess python module). Have a look to the slides 17 and 18 of this slideshow: http://www.pythonocc.org/resources/presentations_events/product-data-exchange-2009-conferen

Re: [Pythonocc-users] BRepAlgoAPI_Cut performance issues

Hi Charles Just an Idea : Try to create a compound object containing all the "groove" objects, and then try to call BRepAlgoAPI_Cut only once.Maybe it will help with the speed problem. Fotis On Tue, Jun 22, 2010 at 12:15 AM, Dave Cowden wrote: > Hi, Charles: > > I have implemented a slicer he

Re: [Pythonocc-users] BRepAlgoAPI_Cut performance issues

Hi, Charles: I have implemented a slicer here, which performs much much better than that: http://code.google.com/p/emcfab please feel free to steal code if it helps-- i have a couple of utility wraper classes for creating slices. Just looking briefly at your cod