Hello,
I am stuck in a very mysterious situation. I’ve tracked the issue down to the following MWE (attached to this post).
It seems that the “Boundary Surfaces” component mess up the order of the input list. I think this might come from its multithreading behavior.
Could anyone confirm that this is (or not) a bug ?
Thanks,
If the output changes if you disable the parallel option, then that’s probably a bug. However it looks like both your Boundary components are already parallel=off.
The Boundary Surfaces component tries to create as few output surfaces as possible. This may involve joining open curves into closed loops, as well as using some loops to cut holes into surrounding surfaces.
Because of this, the number of output surfaces of the component is not typically the same as the number of input curves. Hopefully, many input curves all contribute to a single output surface. If we cannot even count on the amount of data to remain constant, we certainly cannot expect the ordering to be the same.
If you have a situation where you want each individual curve to yield an individual surface, then you should just connect your curves into a Surface parameter, which will perform this conversion automatically (the curves do all have to be planar and closed for this to work), while preserving order.
Or graft the input of the boundary surface component?
Ok I see.
If I graft the input of the Boundary Surfaces Component and flatten its output to make sure the component is called once per input closed curve then I get the correct ordering.
Thank you David for your valuable answer.
