I’d like to confirm great speed improvements using node in code to the vanilla components. Great job guys!
However using parallel gives me different output to non parallel scenario. Probably I’m just doing something wrong.
Please could someone have a look?
parallel.gh (277.1 KB)
Hi Lukasz
sorry if it took a little to study this definition. I need to start saying that there is no bug.
The operation as laid out with the SrfSplit component is not parallelizable by code. If you run it in parallel, you will get the intersection of each curve, independently. This makes sense – the operation of splitting gives two results (in this case) each time, and you want to use these results in the next splitting operation. This operation is not logically re-dividable in parallel, as you need all results each time.
Instead, you get the split of a copy of the surface with a curve each time. I use ghpythonlib.treehelpes.list_to_tree to visualize the result in Grasshopper.
As usual, parallelism in code is not for a casual look. It need a lot of patience and understanding of the process. However, this new parallelization makes sense if, later, you are able to distinguish the two surface groups (the first one has 3 because there is a seam).
I hope this helps,
Giulio Piacentino
for Robert McNeel & Associates
giulio@mcneel.com
parallel2.gh (270.5 KB)
This is truly fantastic Giulio, thank you…there is plenty to learn for me.
One more thing I’ve noticed (also in my original definition) is different result of SrfSplit called from within Python.
If you notice the one on the left is output of standard SrfSplit component (and the one I actually need) and result of ghpythonlib on the right. Why they differ from each other?
Because the function needs to be run serially to give a single result for the main surface. Parallel runs need to give 2/3 results for each invocation.
