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 than one longitudinal cut. What is the procedure for making a
translated copy of a shape?
On Tue, Jun 22, 2010 at 9:40 AM, Charles McCreary <
charles.r.mccre...@gmail.com> wrote:
> 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...@gmail.com> wrote:
>
>> 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 <sfo...@gmail.com> wrote:
>>
>>> 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_i);
>>> }
>>> aCompoundShape = C;
>>>
>>> Fotis
>>>
>>>
>>> On Tue, Jun 22, 2010 at 3:54 PM, Charles McCreary <
>>> charles.r.mccre...@gmail.com> wrote:
>>>
>>>> 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 variant of
>>>> this case, i'll be examining the referenced code.
>>>>
>>>> I'd like to try the cut with compound object but I cannot find any
>>>> examples. Perhaps some pseudo-code indicating how to make a compound object
>>>> out of a list of solids.
>>>>
>>>> On Tue, Jun 22, 2010 at 3:42 AM, Jelle Feringa
>>>> <jelleferi...@gmail.com>wrote:
>>>>
>>>>> 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-pde2009/.
>>>>> This multiprocess slicing is enabled by the shared serialization of
>>>>> TopoDS_Shape objects.
>>>>>
>>>>> The source code is available at:
>>>>> http://code.google.com/p/pythonocc/source/browse/trunk/src/examples/Level2/Concurrency/parallel_slicer.py
>>>>>
>>>>>
>>>>> True, for computing slices the multi-core approach works.
>>>>> However -and I think this is the case we're dealing with- if you change
>>>>> the object than of course using several processes doesn't speed things up,
>>>>> since the processes will simple be waiting for another process to finish.
>>>>> Fotios advice on constructing a compound object and than performing the
>>>>> boolean operation is most likely the way to go. I also used that trick a
>>>>> number of times with success.
>>>>>
>>>>> A note on display speed; by default, the display.DisplayShape method
>>>>> updates the viewer. If you use the display.DisplayShape( someShape,
>>>>> update=False ) the viewer will not redraw, which results in a considerable
>>>>> speed up. Note that you can also supply a list of TopoDS_* instances as
>>>>> argument.
>>>>>
>>>>> -jelle
>>>>>
>>>>> _______________________________________________
>>>>> Pythonocc-users mailing list
>>>>> Pythonocc-users@gna.org
>>>>> https://mail.gna.org/listinfo/pythonocc-users
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Charles McCreary P.E.
>>>> CRM Engineering
>>>> 903.643.3490 - office
>>>> 903.224.5701 - mobile/GV
>>>>
>>>> _______________________________________________
>>>> Pythonocc-users mailing list
>>>> Pythonocc-users@gna.org
>>>> https://mail.gna.org/listinfo/pythonocc-users
>>>>
>>>>
>>>
>>
>>
>> --
>> Charles McCreary P.E.
>> CRM Engineering
>> 903.643.3490 - office
>> 903.224.5701 - mobile/GV
>>
>
>
>
> --
> Charles McCreary P.E.
> CRM Engineering
> 903.643.3490 - office
> 903.224.5701 - mobile/GV
>
--
Charles McCreary P.E.
CRM Engineering
903.643.3490 - office
903.224.5701 - mobile/GV
_______________________________________________
Pythonocc-users mailing list
Pythonocc-users@gna.org
https://mail.gna.org/listinfo/pythonocc-users
