Hello. I am trying a loop function to create fractal geometries in grasshopper, which you can expect to have a lot of layers of path. I am wondering if there is a way to represent an entire path with a token in path mapper? such as {A;B;C;D;E} represented by something like {…;D;E}? as the looping continues, I will only expect more and more layers added behind the path, so it will be very helpful to be able to represent the whole path without typing everything out in the path mapper.
Avoid Path Mapper! There are better ways to manage data trees.
3. Attach minimal versions of all the relevant files
Thank you! Could you enlighten me with other possible directions regarding the problem?
I am trying to generate smaller tetrahedrons on each face of the existing ones. Here is a screenshot of both the preview and the code.
tree growth.gh (42.6 KB)
2 Likes
I made a few simplifications but left your code intact. Eight copies of Path Mapper!!! I’m sure they can all be avoided. Where is your loop?
tree growth_2023Jun10a.gh (22.3 KB)
This is the same code with all Path Mapper components removed. None!
tree growth_2023Jun10b.gh (20.9 KB)
Ready for the loop (Anemone).
tree growth_1st_revision.gh (18.5 KB)
Thank you so much! Sorry about the messy undeleted functions on the side. I have added my desired input and output of the loop to your revised file. Ideally, it starts from one tetrahedron, then expands to three, then nine on top of it, then 27, and so on. As the complexity of the data structure increases(the trunk or the lower part of the tree got thicker), I only need to make changes to the last two branches on the tip of the tree to help me generate those fractal geometries.
Sorry for missing your latest comment! I am looking into it now.
It’s possible that looping might break parts of what I did…
But it probably breaks a Path Mapper solution too?
That’s very understandable! Thank you for helping me to get rid of path mappers! Path mapper doesn’t work in this case also because I haven’t found a way to represent the idea of “all path” without literally typing in the {A;B;C;D…} structure. I guess the length of path should grow as the looping continues. However, in the loop, I am now trying to erase the previous data structure by flattening the output, so that I don’t have to deal with growing length of the paths. Else, if you have any ideas for how to enable the loop without the flattening that would be awesome!
I don’t believe this is correct yet, but I’m tired of playing with it, for now. I’m 100% sure this kind of thing has been done before on this forum.
tree growth_2023Jun10c.gh (24.2 KB)
1 Like
Thank you so much!! This looks great! I am still struggling to find a way lmao. Definitely will search for similar solutions in the forum. This is my first post and I am so happy there is someone willing to cure my noobness
Here I changed from normal direction to z-direction and added a variable such that the height increment is decreased by .75 each loop. Here’s the result. I plan to use this as a way to generate a 3d force diagram to achieve parametric structures, though I still have a long way to go. Have a beautiful day!
The trouble with stepping away is that’s when the creativity flows… other ideas. This one extrudes the triangle perimeter curve instead of the surface, resulting in an “Open Brep” with three faces instead of a “Closed Brep” pyramid where one face needs to be removed.
I also “solved” the Z direction problem by reversing normal direction on alternate cycles of the loop (yellow group). Why? Because it works. 
I noticed that pyramids start colliding with each other after a few iterations so added a slider (blue group) to reduce their height. It occurs to me now that height could be reduced with each iteration. 
tree growth_2023Jun10d.gh (21.1 KB)
Images of code without the GH file are useless to me.
P.S. Here is a quick implementation of reducing height with each iteration:
tree growth_2023Jun10e.gh (23.0 KB)
Five versions by 9:00am! Oh dear… Again, I’m not sure this is really correct. I see anomalies…
Thank you so much for the follow-up. 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. Sorry I have to go to sleep, sadly, greetings from another hemisphere!
tree growth_3rd_revision.gh (26.6 KB)
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”:
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)
1 Like
Thank you so so much! Indeed the need value for path mappers in this project is proven to be null and your code achieved exactly what I wanted-- a growing data tree with each iteration! The way you controlled the normal direction from flipping to the other side by the capping-decapping method is also something I learned a lot from too. The extrusion along the z-axis is a lazy way proposed by me to avoid any intersections, but in the local normal vector way, if I can find a way to detect intersections between tetrahedrons and avoid them from being generated from the first place, normal vector way is definitely the way to go. Now I am trying to do just that–like tree branches in the rainforest elegantly grow to never touch each other–to detect intersections and avoid their further generations while keep others growing. I will post an update if I figure anything out! Also your tool to visualize data trees of geometry is very useful, many thanks for sharing!!
