Hello everyone,
I'm trying to flatten a cutting pattern, that I want to generate with GH. The tricky part are the dynamic seam holes, which I believe are destroying my "clean" srf.
In the attached images you can see a comparison of the original (clean, left) surface without stitch holes. I then process it in GH to get the holes (right). Unfortunately, the resulting (baked) surface does not behave the same way as the original does. As you can see below, it's all wrinkled up (red arrow).
1. I'm pretty new to GH and Rhino, so creating the holes in this way might be a non-standard approach to start with? Or does it seem legit this way?
(I went through some tutorials [THANKS!!], but I'm not yet familiar with any best practice)
2. could someone please give me a hint, how i could tackle this? Obviously I need the same clean squish (green arrow), only WITH the holes...
3. Currently I'm working on a MBair i5 (2core) inside Parallels and the computational drag for this little problem feels already quite significant (~10-20 secs to compute or so). Would you consider this normal for GH, or have I gone down a resource intensive path?
here's a screenshot of my GH-file:
Any hint is very well appreciated,
thanks,
vincent
Armin Seltz
Could you not "cut" the holes into the flattened surface?
It almost looks like its converting it into a mesh when flattening with the holes.
Can you attach the .gh and rhino file?
Regarding performance: This is quite normal, especially if you are using Parallels. If its not worth using Bootcamp, then you will just have to live with the waiting time. But yeah, its totally normal for some stuff to take long, going up to a few minutes for heavy stuff.
Aug 5, 2016
Armin Seltz
Ok, so I checked your file. I am not sure what command you used to unroll your surface, because it is obviously not done in GH, but in Rhino.
I tried using UnrollSrf, but it told me that the surface is doubly curved und therefore not unrollable (developable). I then used UnrollSrfUV, which worked and also lets you unroll any curve/edge you select. I did that with the surface and the bottom edge and then used those in your GH file, which actually worked straight away and is much faster (by the way, your original GH file took 14 seconds to calculate on a 2013 iMac with and i7 and Windows 7 using Bootcamp - so your times using Parallels are not so bad).
I have made a few other improvements to your GH script. I have internalised the data in the curve and surface input, which means they are not referenced from Rhino any more. But you can set them again the usual way by right-clicking and setting one geometry.
If you bake the output right at the end of the GH file, you get a clean surface in Rhino.
Aug 8, 2016