How to represent the entire path by a token in path mapper?

[Joseph_Oster]

@Haiming

I thought the comments might have concluded but there seems to be so much more to be discussed! The quick fix by PnC is really nice, love it! I added a function so that the increment of height will reduce in each iteration. However, I have to agree with you on that there are anomalies in which the extruding direction doesn’t always follow the normal direction of its mother plane.

Regardless of details, I believe we have demonstrated that Path Mapper isn’t required for this. In my experience, it is never required!

Much can be learned by reading other people’s code, for sure, but discoveries we make ourselves are often the sweetest. My own frequently used tools are summarized here, including “temporary text panels and the Point List component”:

Interpolate curve through points in data tree

In addition to temporary text panels and the Point List component, these are the tools I use to visualize and understand data trees of geometry: [data_tree_tools_2022_Nov3a] data_tree_tools_2022_Nov3a.gh (46.6 KB) Recently I added ‘A’ (alpha) inputs and ‘C’ (color) outputs to ColorB and ColorJ but I rarely need them or use them. They tend to interfere with each other so I often use them one at a time.

I’ve played with this “loop function to create fractal geometries” enough now to have some insights.

Getting surface normals to properly lift the center point for each pyramid is one of the issues, and I have a new method in version ‘f’ below. Better than the quirky “reversing normal direction on alternate cycles of the loop” in version ‘e’ (above), this is a variant of a method I used earlier but apparently didn’t post. A “Closed Brep” is created using Join and Cap, then deconstructed and “filtered” to get the original three triangular faces. But now we know the surface normals always face out because of the temporary “Closed Brep” (GH magic). I’ve tested this and am confident they are correct.

The other feature of version ‘f’ is that heights of the center points are determined using a fraction of the area of their base triangles (‘F’ slider in blue group). Other methods work as well but again, I am reasonably confident that this model is working correctly.

tree growth_2023Jun10f.gh (25.9 KB)

The ‘Iterations’ slider is set to 3.

The yellow group is not part of the solution but it confirms a guess I made based on observation of the geometry produced. The original three triangles you provided are not all the same! This explains some of the anomalies visible in the geometry - it’s not symmetrical because they are different.

The other anomaly I can see is because pyramids at the edges of the three original triangles begin to wrap under as the ‘Iterations’ value is increased, You can see that in the bottom view (below) as three triangles are facing downwards after just three iterations.

As I recall, similar models I’ve seen on this forum scale down the size of each iteration, perhaps to deal with this phenomenon ? I experimented briefly but prefer to end this here. Have fun.

P.S. This code is the same but the gray group creates a pyramid of three identical triangles:

tree growth_2023Jun10ff.gh (27.0 KB)