Multipipe problem

I did some testing / learning with the new multipipe in grasshopper.
I am impressed.
but soon I wanted, needed to understand the Topology created, to manipulate the shape. still in GH.
initially I wanted to tween between 2 different SubD´s based on the same Line set but with different Strutsizes… but I Found out that the 2 SubD´s have different Point orders while they are topologically identical (1)
but I was provocated to jitter the input line lists and found that geomatrically identical inputs created different results. not good.(2)

How did you create the SubD’s?

It would help if you could upload your files with the relevant geometry.

i created the SubD using the Multipipe node.
or do You ask for the exact settings, numbers?

2files to explain a bit detailed attached.
Multipipe_problem2_jvs_250304.gh (14.9 KB)
Multipipe_problem1_jvs_250304.gh (30.4 KB)

Ok first thing, I’d say the end offset of 25 is too high.

If the jitter input asks for a value between 0 and 1, I would avoid other values (2.8)…

The pipes created with multipipe have 4 faces around. Your line network has asymmetrical nodes with up to 13 lines. The pipes can’t always be in the perfect rotation and I think this is the reason the shape can vary slightly. Depending on the order of the input, another line might be prioritised for the alignment.

wrong number in my explaination: jittering values above ca.0.28 create problems
not in the jittering but in the subD creation
and this is just an example. i am surprised that the multipipe result depends on the listorder at all.
jittering does only change the the order.

Let’s wait for @DanielPiker

If you add a Topologizer component, Multipipe works with most of your inputs.

hmmm…i made a random star out of lines and run the multipipe node on it:


i used two different strutsizes:

the two different results are:


as you can see, even though the linelist(same order of lines in the list) for the multipipe is the same, for some reason it creates two subd meshes with different order of controlpoints.
hopefully this is a bug and not a feature… :wink: