Using Geometry Gym Unroll, I get an untrimmed surface, that wont join to the neighbouring piece even although it has a straight edge the same length?
Why is this happening?
You need to be running GG_Unroll
J
Unroll-Untrimmed.gh (9.7 KB)
I don’t work with add-ons of any kind (except Kangaroo) so no idea what’s happening.
But on the other hand you may find the attached usefull. Load Rhino file first for the demo cases (including yours).
Brep_unroll_V1A.gh (134.3 KB)
Brep_unroll_V1.3dm (1.7 MB)
1 Like
Thanks. Nice script. Very nice for investigations. However I am after the pieces staying together in their developed pattern, and I do wonder if this script is drawing a bounding box around the trimmed surfaces? It could be I simply need to rebuild the surfaces before I use my Unroll system, for it to work? Or I do wonder if your script can do it? Am I missing something here? Let me know?
J
I’m afraid that this (entry level) thingy is written with focus on BrepFaces (AEC: facades, roofs, envelopes, sheet claddings and the likes) meaning “stand alone” pieces. Works with other Methods that pack the pieces in order to minimize wasted material (that’s strictly internal, meaning no public version). If a facade is made from an expensive material (say: titanium) an efficient packing makes a very big difference, Very rarely in AEC one needs one continuous combo (if possible anyway).
Creating “äutonomous” (not overlapping) combos (on a Brep basis) is not that easy at least having in mind general cases and the fact that some BrepFaces may classify as non developable ones. A combo means bending. But bending in real-life is a very complex task: in fact one needs sheet metal (the best are made in Israel) “add-ons” as offered in CATIA, Siemens NX and the likes.
With regard the C# posted, the boxes are used for layout purposes (in X, the Y intelligent packing is removed). Boxes provide a hint with regard the packing need as well. Some Methods focusing on layout/assemply aids (textDot on edges based on FE/EF classic connectivity) are removed as well.
But your case is very simple and thus I could add an option that could attempt to unroll on a Brep basis. Results may be hilarious in the vast majority of cases.
BTW: The unfold GH native thingy works on simple stuff as well (not so on other things)
Found a couple of minutes for the unroll on a Brep basis option (mode =1). Yields amusing results in most of cases (other than the very simple ones) for good reason: Rhino is NOT a sheet metal app nor has any relation with solid MCAD stuff. That said just a pro level sheet advisor costs 3++ times as much the Rhino (to that add a lot of cash for the host app) … therefor one must rate things within the right perspective.
BTW: Unroller appears failing if finds a non delelopable Brep Face. iInfo panel informs failures accordingly.
Brep_unroll_V2.gh (134.9 KB)
Added the yPerBrep option (mode =2) that overrides the xCount value and makes a long layout of faces in a row that is occupied solely with developable faces that belong to a given Brep in the List:
Note: in mode = 1 the deltaY gets some intelligence: is the offset between frames … meaning that you should use a much smaller value than the one required for mode = 2. Try setting it to 0 (frames “touch” each other in Y as they do when deltaX = 0 in mode == 2). Maybe for mode = 1 I should use deltaX …er… for moving along Y (a bit paranoid but then again why not?) or just deploy things along X. Anyway.