Tube Bundling/Branching

I’m working on a script that would turn a branching tree structure into a bundle of tubes. The first thing I do is analyze the network to find out how many tubes are at each node (assuming a branch continues from the base all the way to the top).

After this, I have a little python code that creates a polygon with fixed edge lengths that would be the diameter of the tube. The midpoints of these polygons edges would be the new location of the tube centers.

Finally, I have a python script that runs through each route and replaces its original node with one of the points from the polygon. This makes it so I have perfectly packed tubes at the nodes.

The problem is the ordering of how the points on the polygon are picked. I essentially want to find a way to pick points on the polygon in an order that avoids tubes intersecting with each other.

I tried a method that used a rough closest point search from the previous node to the current node. That seems like a step in the right direction but creates other messier problems at the same time.

Anyways, most of what I’m doing is in the python nodes. File is attached. If anyone has any ideas on how this could happen logically that would be great.

Wire_Bundling_WIP.gh (20.1 KB)

6 Likes

Inspiration:

I would use a compass :slight_smile: …this will sound silly :slight_smile:

consider the very first points group on the bottom of your trunk, make the average of them: that point is the center of the compass (I would project everything on XY plane)

the aim is then to connect one given point of a branch to one of the available points of the next branch, in such a way the angle between their respective vectors is as close to 0 as possible

rinse and repeat for each branch
[edit: I think it’s important that each point “inherits” the last vector that has led to him, and that that vector should be used for next-point computation. Or maybe not…]

in other words, when you are on point P and are looking at the next branch searching for a point to connect to, instead of picking the closest point I would pick the point that has the most similar vector-direction

I definitely should have gone to sleep .___.

:+1: That’s an interesting approach. I will definitely explore that route.


… problem:

:see_no_evil: … and this for a single node.
Wire_Bundling_WIP_re.gh (42.5 KB)

Some points:
You made already each pipe as a full length polyline, from start (48) to end (1) … I think this will not help you.
Try to make a list of lines (no duplicates) and for each line have a int, for the number of pipes around it.
Then, I would work per-node, with each node calculated from:

  • a point, central;
  • an “entering” vector, for the starting branch (B)
  • a list of “exiting” vectors, for the exiting branches (b)
  • a list of integers, defining the number of pipes for each b
    (the number of pipes around the entering branch B is the sum of the integers list)
    This would be a custom class object in a scripting environment, be it python or c#.

The logic i’ve use is rougly this:

  • sort new branches (b) vectors clockwise around the big starting one (B);
  • shift and partition the points (later tubes) around B so they align with outgoing branches b (I did use some sort of weighted average, starting from a 20-tube Branch, we want a 3-tubes branch to suffer more deformation compared to a 7-tubes branch, because that is looking best!)
    Here now we have a sequence of lists of points on B of the same size of the sorted b lists.
  • center of B (blue)
  • center of b (green)
  • for each sub-list on B, find the average point (red)
  • make a surface passing by blue-green-red
  • find the intersection of that surface with the polygon on b (white) and adjust the seam there

    Now, given the fact no branches point downward, they should all be oriented the same seen from above.
  • simply sort the point of each b with the seam-adjusted polygon and match them with the already-sorted points on B

Headache? Make sense. :rofl:

WAY more difficult to explain than doing this.
Spent 30 min on the definition and like an hour making the video, re codec it (hoping it works), and writing explanation.

2 Likes

Daniel Piker released a topologizer component some time ago. It might be helpful. I tried to create a tree out of single line segments without duplicates but couldn’t really get my head around it yet

Download from one of his posts…

@Ryan_Whitby @maje90, this is a nice topic. I am not sure to manage to make something usable. I wrote the first class that put n circles on a plane. It is already useful to make tubes around a curve.


I hope to get somewhere :sweat_smile:

2 Likes

I think I’d approach this by making a mesh for the branching part which can be sorted into warp/weft directions, where half the faces of the trunk flow into each branch (or however many branches it splits into).
Then for each level, place a scaled copy of the mesh on the branch, subdivide the trunk so the edge counts match, then join, sort the mesh directions and extract the curves:
image
meshtubesplit.gh (15.3 KB)

4 Likes

I think the cables should be bundled differently, with their centers not on a curve but their cross sections filling a smallest possible circle. That could be a circle packing optimization for each section of a polyline. Basically simulating zip-ties… I tried to solve this with collision goals but it’s not perfect and still has a lot of unwanted intersections.

20_11_21_wire_bundling_mrtn.gh (69.0 KB)

Yes it seems a good idea more compact but more difficult. I am there at the moment. I know it is an horrible picture. Still WIP

1 Like

This looks promising, I will need to take some time to parse through it.

Looking a lot cleaner!

I had a feeling there would be a mesh solution. I guess the difficult part of this approach I can imagine is generating the appropriate mesh from the centerline model.

That’s nice!
I’m still working on the single node object/method …
Have you already solved cases with sub-branches with 2 or 1 tubes?
I’m stuck there rearranging the IFs … XD

I have a tree representation of the tree so I can calculate how many tubes there are on each branch depending on how many tubes are on the end. I made some classes (C#) to make arcs (tubes centers are on arc). For the blending I have to implement the variation on a arc in order to have tubes well ordered and not going on each other.
Still to optimize placement of tubes, propagation from trunk to leaves for tubes placement …
I also will be making a mesh model (no tubes) of that. Same classes to do both mesh or pipes.

Tried a different approach that takes the points around each node and splits them up into groups based on proximity to a point near the end of the incoming branch. After this I just reordered the points along the original polygon so the point within a group are at least in some kind of order. Working alot better but still needs some tweaks.


I think if I can correctly adjust the seams of the circles this would clean it up a bit more.

Wire_Bundling_WIP_v2.gh (27.9 KB)

4 Likes

Hello
you bring a very interesting subject. There are many subjects to take care of.
One of the subject is to bring pipes from a branch to another.
I consider that the pipes are on an arc. Each arc has some properties:

  • Width Angle (2*PI for a circle)
  • A plane (it gives the orientation Z and the center)
  • An angle shift from the plane, it rotates the arc around Z of the plane
  • A number of pipes
  • A radius for the pipes.

here 2 arcs in White.
I first make a blending curve between the middle of the 2 arcs. Blending curve will carry many others arcs.



There are many parameters in order to have some nice transition.
Blending curve is important.

I use S-function for some of the parameters of the arc.



There are some errors !! But quite beautiful

10 Likes

Hello
just to say that I am still on this project. I am having hard time figuring the good way to tackle this subject. I have some angles problems depending on odd or even numbers.

Some blending problems, blending is OK, I have 2 methods, the Rhinoceros one and mine. But the looking is not good and there are pipes intersections …

Don’t know if I will end in something useful. But I think it will be easy to output a mesh of that, it will be faster than piping. It will also allow to have a radius variation more realistic of real tree (r^n parent = r^n child1 +r^n child2 (n=3)
see there

Some nice looking




Bad looking

Wire_Bundling_LEGACY.gh (77.2 KB)

7 Likes