Hey,
I am trying to offset (or scale?) different surfaces with a certain distance (approximately 0,06). I can imagine how to do this for a flat surface (top surface in attached image), however my model also contains ‘surfaces’ which are bent (basically formed from two surfaces as can be seen in the bottom surface).
Any ideas would be much appreciated.
Kind regards!
Sounds like you want the holy grail of CAD, to thicken polysurfaces. No magic that I know of. Two recent similar threads:
Thanks for the reply!
Not really trying to thicken the brep. What I am trying to do is to scale down the brep it in its own plane(s) with the final difference between the original and scaled breps being a width of 0.06.
The component ‘‘offset curve on surface’’ comes very close to what I want to achieve, as does ‘scale’ relative to the center of the surface. But both don’t work since the edge of the brep is spread over two surfaces.
Hope I made myself understandable, its hard to explain conceptually with English not being my native language.
It’s a little more obvious looking at your file, which I didn’t do until now… This doesn’t address your issue, it’s just a suggestion for treating “faces” as curves.
This is heavily relying on Brep.CreateOffsetBrep…
The first row of components is just sorting your surfaces by row and two by two on odd rows…
I tried to split the contour and assign the edges to each surface then offset them separately on each subface but the result didn’t join.
OffsetCurves.gh (64.7 KB)
Would it be taking the long way around if from this point you:
OR After groups of 2, join them → extract external curve → cap …
Seems a bit much, but i cant think of something easier right now.
Too bad your surfaces are a flat list instead of branches by Z values. The white group below does that.
I didn’t know if these offsets are supposed to be holes in the original surfaces? Easily done.
P.S. The overlapping pairs are single polysurfaces with a crease at the vertical seams
(yellow group at the bottom)
P.P.S. Not quite as easy as I thought but not too bad. Teal group added at the bottom. Best to disable this group unless and until needed since SplitMul (Split Brep Multiple) is slow (~4 seconds).
I was looking at something else in this code I posted - a little mystery that I might comment on later if I figure it out. Hint: Why does Scale NU require only one value for ‘X’ instead of the two values I was using, +X and -X?
But what got my attention was the slow profiler time on OffsetS (Offset on Srf) - 1.5s 
So I replaced it with Offset Curve which requires a plane, hence the added cntrPl (Center Plane) cluster that I wrote for something else. The profiler difference is dramatic: 24ms or less combined for two clusters vs. 1.5s for OffsetS.
(full size)
offset_2023Aug24bb.gh (73.6 KB)
Which reminds me… this thread title is misleading. Instead of “Offsetting surfaces” it should be more like “Offsetting surface edge curves”, eh?
Hello magicteddy, （Rainbow display）what kind of plugin is this?
Looks very similar to a pair of clusters I wrote that were based on a cluster called
‘Colorful’ from @HS_Kim.
Okay, thank you
Great ! I’ll lokk at your code later. You did succeed in joining everything into one offset, where I had gaps with a very similar method.
And yes, OffsetOnSrf is one of the slowest things I’ve ever encountered. Note that it can sometimes be faster to flip the curve and offset with a positive distance, rather than offset with a negative distance.
It does the same thing as the clusters indicated by Joseph : one color per tree branch. I just absolutely hate clusters so made it my own plugin (unreleased).
Interesting, @Joseph_Oster 's first interpretation of my question could also lead to a solution!
Thats it! I like that you still kept it relatively elegant. Its always educational seeing different solutions.
I have two clusters, ColorB which assigns a different color to each branch and ColorJ which assigns a different color to each item in a list (each branch is a separate list). Both are very handy for different purposes. Later I added ‘A’ (Alpha transparency) inputs to both (ColorBa and ColorJa) and a ‘C’ (Color) output which occasionally is useful for assigning the same colors to “parallel” sets of geometry. I mostly use the newer versions now because transparency softens the colors, which can otherwise be too harsh.
Clusters can be annoying if they are used to hide large blocks of essential code, though the same might be said of Hops? I find them very useful for small reusable bits that I save as “User Objects”.
P.S. Here is an example of how those two clusters are used in practice. Same code as version ‘bb’ from yesterday with the addition of ColorBa and ColorJa. If you look closely, they make a lot of sense. Very helpful when coding. Alternate frames of this animation disable preview on ColorJa.
(full size)
offset_2023Aug24bb2.gh (89.4 KB)
One more question regarding the solution. I was playing around with different geometries and found some unexpected behaviour of the ‘offset on surface’ component.
It seems like the orientation of the panels suddenly changes after the component, any ideas of why this is? I have attached your solution file in which I added the new geometry and the proof of the orientations changing.
offset_2023Aug24breply.gh (58.2 KB)
I can imagine various reasons but why are you still using OffsetS (Offset on Srf) 
Yesterday’s version ‘bb’ works fine with your new list of surfaces.
offset_2023Aug25a.gh (60.8 KB)
totally missed that part of the discussion in my enthousiasm of seeing the initial file function. You are correct it works!
