I have a number of closed polyhedra rhino models that I am considering making into physical models. In the past, I have enjoyed the use of the “unroll surface” command to summarize how I might make paper models of these objects. Now I am considering making something out of plywood and I would like to have the usual labels associated with the unroll surface, also indicate a dihedral angle at the joinst. Is this possible with Grasshopper? Does anyone have any recommendations on where to start?
If I’m understanding correctly, you could use the “Unroll Polysurface” component from the plugin Pufferfish, available on food4rhino. Also a similar component exists in the “TT Toolbox” plugin.
It allows you to unroll curves and points along with the brep, so what you could do is have your list of angles, and a list of edges on the brep that they correspond to.
You then unroll those edges along with the brep and so you can use those to place the angles as text labels to be lasercut/cnc’d etc.
There is a tool for Brep topology that gives you, for each edge, the indices of the adjacent faces. You can use this to work out the angle between the Z axis of the face planes.
Does this give you the dihedral angle? I always get paranoid that I’ve calculated the wrong angle…
FACE_ANGLES.gh (18.6 KB)
(I don’t know if the Brep Topology component is standard GH or not.)
I’m not sure I entirely understand the details of your explanation yet, but it sounds promising. I’ll checkout those two tool. It sounds like deriving the indexed list (I.e. angle to edge id) might be the easy part. Placing those value back on the unrolled image has me concerned. Thank you for the help. It would be really powerful to have this functionality.
If I understand you correctly, “the z axis of the face planes” is the same thing as the angle angle between normal vectors? I believe this is where most calculations of dihedral angles start, since the cross product (if I am recalling right term) is a pretty straightforward linear algebra equation. If this is what you meant, the dihedral angle is usually that, subtracted from a straight angle (I.e. 180 degrees). In other words, even if it’s not the dihedral angle, the dihedral be angle should be cake to derive. Thank you. I will check this out soon. On a phone at the moment.
So I had a chance to poke around your cool grasshopper script (if I’m using the right term). Very illuminating. A couple issues I’m going to need to sort out if I am going to really use this approach.
The normal vectors all need to point out for me to get accurate dihedral angles. There appears to be a bit written about this on the forum but I haven’t found a definitive methodology for this. It does appear some of your vectors point inward and a consistent orientation is going to necessary for this routine to truly be useful.
I did find the FaceNormal command but I haven’t figured out a way to actually see the length of this vector (as commentary on my noob status) so I can’t tell if it is facing the right direction.
I did manage to download the TT toolbox and install it. Thank you for your help.
I included a Vector Display component in that GH definition that shows the direction of the face normals (or face plane Z-axes) and on the example I included they all seem to point outwards but if you plug your polyhedron into the Brep component at the start you might find that some of your face normals point inwards and some outwards. You are right to spot that this will need fixing somehow. If they all point the wrong way you can use a Flip component I believe - FlipPolysurface if you are working with a Brep and FlipMesh for a mesh!
If the normals are inconsistent you can use UnifyMeshNormals if you are working with a mesh but if you have a Brep with mixed up face normals I would try and fix that manually in Rhino first.
FaceNormals often refer to those of a mesh not a Brep and meshes are typically made up of faces with 3 or 4 edges although if you are working with meshes with faces that have more than 4 edges check out the NGon plugin.
There are excellent Mesh Topology components that give you the Face-Face, Face-Edge and Edge-Face topology of a mesh but I’m not sure if this exists for nGon meshes.
Top tip… if you right click your Brep component and select “Internalise Data” it includes the geometry in the GH definition so we can see what you are working with.
I can see you have converted your Brep to a mesh. Use the MeshEdges component to understand what that has done… it will have converted it to a mesh made up of faces with 3 edges and this is probably not helpful…
Red is a Brep, purple is a mesh. You can see that the polyhedrons faces in the purple mesh have been split into mesh faces that have 3 and 4 edges. I imagine, for fabrication, you will want to keep the faces of the polyhedron intact, not split into more faces?
After a quick first read, I can tell you are right that the limitations on face shape with a mesh will be problematic. Thank you for pointing that out.
Yes, manually checking the orientation of the normals before sending it to grasshopper is an excellent methodology and frankly the only reliable method that I can think of.
This is particularly true because the poly surface I make are not always closed and the orientation of “out” and “in” is ambiguous. A better terminology when referring to the normals of the faces, is that they all point either up or down when the object is “unrolled”. If one had, for example, an object that was similar to the topology of a faceted Möbius strip. If I understand this correctly, I believe there would inevitably be one joint that was required to violate any normal convention. This would be at the edge of the unrolled faceted Möbius strip. I would think this possible reality would make a purely automated process problematic. As you imply: align your normals. After that, stay keenly aware of any “normal conflicting” conditions (for lack of a better term).
…this normal situation might be more automated at some point if one identified internal edges in an open polyhedra where the face normals flipped.
Would this _addngonstomesh python script component help?
It might if the non-triangulated mesh can then be used with the mesh topology components to give the Edge-Face topology.
I’m on R5 so won’t be able to check it as I assume nGon is R6?
I don’t know if it’ll give you that using standard r5 or r6 components. @Petras_Vestartas might have something that’ll do it in r6?
Thanks for the “internalize data tip.” This may have been known to you already but I realized tonight (if I did this correctly) that if I have a brep has all its normal vectors pointing outward, the deconstructed version will not necessarily have faces with the same properties. I’m attaching a simple grasshopper file that I believe shows this to be true. If you could confirm this is consistent with your understanding that would be very helpful.
Aligning Normals Exercise.gh (7.3 KB)
This gentleman appears to have found a solution to aligning normals that may rely less heavily on determining what is “out” and what is “in” but I don’t entirely understand his deductions yet. His methodology appears to relate to the order in which vectors describe the perimeter of a face. It would make sense that all edge vectors for a given face should should “stack” tip to tail in either a clockwise or a counterclockwise direction consistently for normals oriented the same way. Hard to believe this isn’t a problem someone has found an elegant way to solve…
I am also sure that you can do this with standard components, since BRep has correct topology before exploding:
For correct orientation of Normals in Meshes I am using NGon.
You can either directly convert BRep to Mesh or if it is not working, use UnifyMeshWindings.
For Unroll you can unroll Mesh or Brep with OpenNest or TToolbox including additional tags, curves or points.
Can you explain or show a 3D model that you want to have as a result?
Aligning Normals Exercise.gh (22.4 KB)
Before unify windings:
After unifying windings (also works with polygons not only triangles):
Which version of Rhino are you using? I am on R5. I have TT Toolbox plugin installed but I don’t have the Unfold component. I will check my TT Toolbox version.
From what I can see, your polyhedron has 2 face normals pointing inwards and 2 pointing outwards. I would have thought you would need all normals pointing outwards but I have no experience of using the unfold tools so I am not sure!
Also… I do not think doing this gives you the face normal…
You have plugged a Surface (from the “F” output of DeconstructBrep) into a Vector parameter. I am not sure what this is giving you but it might not be the face normal!
I tried using the FlipSurface component and using the Surface plane as an input for Guide…
This appeared to flip the bottom face of the polyhedra but when I then went to check the surface normal using the Planar component it showed no difference so I am now not confident that this is how to get the surface normals!
Surface normals could be to do with the order of the vertices around the face (and direction of the edges)
Can I just check with you what the end goal is…
Are you aiming to lay out each face on a flat plane and label the dihedral angle on each edge (along with a panel ID number and edge ID to aid assembly)?Aligning Normals Exercise MH.gh (11.9 KB)
Follow this discussion!
I looked into this specific question of face normals a bit more in another forum and it appears I was being somewhat sloppy in my generation of the normal vector using the “vec” node. I think this methodology is somewhat arbitrary in its assignment of vector direction. Joseph appears to have a much better work flow here.
Thank you for all your help. Yes, I’m on Rhino 5 as well.