Hi, Im trying koch tetrahedron fractal with the ‘Anemone’ plug-in. but unfortunately i’m not getting the same results as displayed in image below.
i’ve attached my grasshopper script(it is using Anemone)
_gh script _ tet fractal.gh (25.9 KB)
reference image here :
referred page for tetrahedron koch fractal : http://www.grasshopper3d.com/forum/topics/koch-tetrahedron-with-hoopsnake
Any help would be appreciable.
I looked a bit at it, too complex, there are some inversion for the choice in edges, use this green buttom to follow the flow !
You will see that an edge is not the good one
It means that edges must always have the same order… So O don’t go deeper in that.
Edges must be extracted from face.
And why not giving adress of previous post !
Just for playing I made one with mesh
Edit : previous version with material name for custom preview made crash on Rhino !!
I found it difficult to follow your code. I used bits of it to write what should be a simpler approach, and it sort of works… I may get back to this later but have developed a bad attitude about Grasshopper at the moment, due to its inconsistency with surface normal vectors on the faces of the tetrahedrons. I don’t see a simple way to resolve this ANNOYING behavior so will post this as is, for whatever it’s worth (not much, since I see @laurent_delrieu has posted a working solution).
I created a cluster called “tetra” that takes a “face” (triangular surface) and creates a tetrahedron from it. Then, in the Anemone loop, I create the “nested” triangle for each surface and use the ‘tetra’ cluster to complete the job. SO FRUSTRATING that it appears to require some messy complexity to deal with inconsistent surface normals that cause it to fail on one of three sides.
The ‘tetra’ cluster:
The main problem in that definition is change in surface normal with every iteration. which is getting pain to resolve. your def looks short and sweet.
PS : and yes i just added the address to my previous post,
I can understand your frustration, its really annoying the way surface normal’s vector of tetrahedron are behaving. i"ll keep on trying to resolve this and post if any good can be done with this… (@laurent_delrieu’s solution looks good to me tho.)
Thank you for your solution
Here a new definition that make a solid mesh. So it could be printed if wanted.
koch recursion subdivided.gh
It uses weavebird for subdividing, smoothing …
Incredibly annoying! Absurdly arcane, far more difficult than it should be. There is no good reason to use a mesh for this, other than the fact it appears to work while the NURBS solution fails miserably so far, for no good reason. It’s no wonder people give up on Grasshopper.
I made a version that works with brep (I hope ). The only trick I had to use is a flip curve as the extrude to point change orientation. No a big deal !
I just used 2 deconstruct brep, one to get face one to get edges of faces.
koch recursion brep.gh
From what I can see in your code, the first copy (above the canvas) using ‘XProd (Cross Product)’ looks very good. Brilliant. I flipped curves and tried every trick in the book and failed so am still hating Grasshopper right now.
amazing @laurent_delrieu flip curve was really smart trick!!!
thank you for you brilliant solution.
brep closest point is new in V6 GH1 it gives the normal of closest point.
@mia.k, no problem, some Sunday recreations. With Brep it works also with other shape. You have just to tune the height of extrusions. Instead of dividing by 3 divide by another number
I’ve spent a ridiculous amount of time banging my head against the wall on this and still don’t understand why, in my code, two of the top surfaces behave differently than the third one? GH is great when it works, but it often doesn’t work as it should, and that’s just wrong, tiresome and very frustrating. I’m not quite a novice anymore so to be stopped cold by yet another inexplicable Grasshopper quirk/flaw/defect/trap on something this simple is almost a deal breaker. Not happy with it at all today!
Sure you are not a novice. I struggle also a lot with many things, tree, brep, C# … and most of the time with my own script. Most of the time there are workaround, also many examples on many places (too many ?). In this case I am not sure it is Grasshopper, it could be Rhinocommon and Topology of Brep. Topology of mesh is here more easily controlled.
By the way, magic of Grasshopper still there.
Recursion on Dodecahedron
A special Joseph Version without Brep Closest Point !! I hope it works in Rhino 5.0
koch recursion brep2v5.gh
I don’t know where the problem here is, and this is a very simple model. I am increasingly intolerant of obvious software flaws that make our lives more difficult, like the nightmare technology in the 1985 movie Brazil. So many people are forced to struggle futilely and walk away in failure.
Does the code I posted above work in Rhino 6/GH2? I’d be very interested to know if anyone can explain why that code fails? And justify/defend that explanation?
And, of course, you are filing bug reports with clear steps to reproduce the issue? I haven’t seen any - but I could be looking in the wrong place…
Rhino 6 runs GH1 - GH2 is for the future…
My guess is you’ve used planar surface after polyline just before your cluster that might be the cause of the problem.
Closed Brep(solid–>by capping)allows you to ensure the consistency of surface normal direction, so you don’t have to generate planar surface again…
And solid union in the end will eliminate leftovers inside the biggest.tet_fractal_2018Jan21a_reV2.gh
I’m not on the QA team and have managed to work around most of the GH limitations I’ve encountered over the last ~four years. GH quirks are way too many to count. The GH forum archives are littered with issues related to surface normals dating WAY back.
Thanks for looking @HS_Kim, I see that yours works but:
- I don’t see how ‘Cap holes’ has anything to do with it? and
- you’ve made many other changes that could also explain the different results, though I don’t see how?
I eliminated the ‘Boundary’ surface, tried ‘Cap holes’ and ‘EdgeSrf’ and many more alternatives. All give the same result, including version ‘d’ (attached) which eliminates the bottom surface of the tetrahedrons altogether. The mystery remains.
Why is one of the three surfaces “evolving” in the opposite direction from the other two?
tet_fractal_2018Jan21c.gh (19.4 KB)
tet_fractal_2018Jan21d.gh (18.3 KB)
Please check the clusters inside attachment.tet_fractal_2018Jan21d_re.gh
Thanks, but another working example doesn’t answer my question: why does mine fail?
I looked very carefully, comparing this version from you to my last (tet_fractal_2018Jan21d.gh) and cannot see any significant difference to explain your success and my failure? ‘PCen’ (yours) and ‘Avr’ (mine), for example, return identical points.
Until I understand why mine fails, this remains a perfect example of “try this, try that” mentality required to deal with GH quirks. I have no idea what fatal flaw I’m tying to work around? The mystery remains.
i can’t load these files since Anemone doesn’t work on Mac but…
capping then working with solid pyramids will ensure the normals point outwards.