I tried ‘Cap holes’ and many other variations. Results are always the same. One surface has the opposite normal direction from the other two.
If there is no reasonable explanation for this, then I think we have to accept that part of being successful with Grasshopper is throwing crap against the wall to see what sticks.
Where’s there’s mystery, there’s no mastery. Where’s there’s mastery, there’s no mystery.
– Yogi Bhajan
hey Joseph,
I was looking at your script, i found that your brep at initial part was open.(i checked it with connecting volume)
And yes the normal’s are behaving bit weird. I fixed it with volume component(kindly check the screenshot) which actually fixed the extrusion in normal direction_(not opposite this time)._
i may not have answered your mystery question but maybe you get some lead in right direction.tet_fractal_2018Jan21d_rev_22jan_mia.k.gh (23.4 KB)
PS: I’VE UN-CLUSTER YOUR CODE.
Version ‘d’ deliberately left the bottom off of the tetrahedron. Earlier versions produced a closed brep and I considered the very same approach you used. What I’m trying to do with the ‘tetra’ cluster is to start with a triangular surface - which has no volume - and re-use the same cluster inside the loop on each of the triangular surfaces from the resulting tetrahedron(s).
Later… I just spent awhile trying to implement this kludge, faking the initial center point to be ‘0,0,-1’ to create the first normal vector. Almost works (hah, hah) but no cigar. Tired and disgusted with it.
No, you didn’t but thanks for trying. The mystery remains.
P.S. In case anyone else wants to tack a wack at this stubborn pinata, I suggest looking at either of these two simplified versions:
tet_fractal_2018Jan22c.gh (18.0 KB) - uses input surface to cap bottom of tetrahedron.
tet_fractal_2018Jan22d.gh (17.8 KB) - uses ‘Cap holes’ to cap bottom of tetrahedron.
I made a subtle change to the ‘tetra’ cluster that appeared to work, at first glance. Instead of extruding the edges to a point, I created lines to the peak point and lofted them, That’s all! On closer inspection, however, the same behavior as before can be found, though perhaps inconsistently? When the results are baked, the surface colors alternate in each generation through the loop, as if they have flipped UV normals? So, the mystery remains.
More grist for the mill… This version is the simplest yet. The ‘tetra’ cluster is used only once, inside the loop, and the model appears to work - except for the clue of flipped surface colors on alternate iterations of the loop. It fails when you change the ‘Segments’ slider from 3 to 4 sides on the base polygon. And once again, finding versions that work isn’t quite the same as explaining why so many versions fail?
The ‘tetra’ cluster:
