Hi All,
I’m getting in trouble finding the angle between faces and how to use the Brep Topology.
My goal is to calculate the average bending angle between the faces in multiple Breps
This are the (partial) 3D model and the GH:
20260621_angolo facce.3dm (144.6 KB)
20260621_angolo facce.gh (16.5 KB)
could you help me to manage it?
Thanks in advance.
Thanks,
I know the faces aren’t flat but it’s not a problem becasue the company has a more powerfull tool named “the Hammer” 
Being serious this will not be a problem becasue the shape is still in the acceptable bending tolerance.
This is my solution at the moment:
20260621_angolo facce_b.gh (16.6 KB)
But other suggestion or improved version will be very welcome!
Something like this:
Not sure, why I did not see there were other posts in the meantime. Sure it’s my internet.
first solution use topology
second solution doesn’t use topology, and keep the brep ash whole, intersecting it with small circles… spare a couple of components but operate slower… i find this useful with extremely complex datatrees… but it is already WAY simpler to tackle this problem through c# coding
20260621_angolo facce_b c#.gh (5.8 KB)
under 30 rows of code… almost the same amount of components used above in other solutions.
The intresting part is this:
See the image, the c# component executed 3 times, once for each brep you have.
The input “B” can have whatever datatree structure, but inside the c# code your B is just a simple Brep object with no additional fuss to handle.
Inside the c# code you can totally forget about everything else of your gh script and just focus on your target.
Once the code execute, the output will follow original “B” input datatree accordignly.
(this can be achieved also by Hops, but I find it more complex to handle to just put up a c# script most of the times… still, give Hops a go!)
I don’t know. People always complain about the difficulty of data trees in Grasshopper scripts… Are they? Really that complicated? I assume looping makes coding much easier. But I also think alot of people look at the componentry of a script, and think that it is “so much”, when once you learn to read and understand components that make up a script, scripts seem much smaller. Mostly people are super undisciplined about clean component work. That annoys me to no end. Scripts that start on the left and sprawl out to nirvana on the right. As if wouldn’t occur to someone to work in blocks or steps stacked vertically just because they are working in a visual programming language.
Both grasshopper solutions I posted above would have been much simpler if working with just a single Brep. c# may looks simpler just because we can easily “cut” a datatree depth level of the initial dataset… Otherwise, managing the 3 breps simultaneously on the code, would result in more rows totally… but as said, we don’t have a reason to do that.
In grasshopper you HAVE to constantly take into account of the global datatree structure, otherwise the code won’t work correctly… but it’s much simpler to edit parts of an algorythm, and if you have to “shift paths” to interwine data between iterations you can do on the fly, on c# it would be more complex.
Each have its pros and cons.
Best is to mix both worlds.
Happens often for me to have a wide and broad situation, where to manage, filter, select and group the correct geometries to work with, is much easier with grasshopper.
Then, once I have the correct geometries, I work with each group (or sub-set) with c#, where often I need to go deep with complex algorithm and where I need performance (so I can optimize everything with multithreading).
Everybody should learn both…
Thanks Riccardo,
I’m not really a fan of code inside GH becasue it will be harder to maintain and I can’t pass it to a collaborator with fewer knowledge.
The pure GH solutions look better to my eye for this reason.
As you see, at the end, my secondo script works pretty well too (maybe less elegant).
… if a definition have many datatree with 2 levels paths ( like {x,y}(i) no zeroes…) , I find it bothersome to maintain even if I created it myself.
I think with c# you are much less lickely to reach complex datatrees, and even when that happens, it means they would have been even worse ifwithout c#.
Some script components really simplify everything.
And If the collaborator has fewer knowledge… from a grasshopper algorythm made by 30 components with 2-level datatree, or a single compact c# script… the last one is more reachable.
Anyway, I understand what you say.
Dear @maje90 and others
Did you see my old topic that did not get much attention:
This topic basically addresses the aspects you are discussing above.
If a Cluster would have an Access type (item, list, datatree) on the input - like a script component this would be a great win.
it would give exactly the power you describe in your code comment
// this script component uses "B" input as a single item, not a list! so our problem is already "down a level" of complexity! No datatree here.
thanks for having a look at the other topic. - kind regards -tom
Yes. Absolutely.
I also asked this here:
No idea if this is currently adressed in GH2 …
Maybe this thread helps:
https://discourse.mcneel.com/t/determining-bending-angles-for-a-brep
FACE ANGLE.gh (13.0 KB)
