algorithmic modeling for Rhino
Hello,
I am trying to apply a square "pipe" onto numerous edges (over 100). Can anyone help out? I have tried sweep1 but it is too timely to place a cross section along each vertex of the edge.
Any help would be greatly appreciated. I have spent HOURS with no luck!!
Tags:
Peace of cake ... actually not quite (see the setting for the offset corner type > sharp doesn't work).
PS: somehow we reinvent the wheel with that one (how the brep is created?)
I'll be back, best, Arnie S
Thank you Peter!
This looks like it works very well. Do you mind walking me through your thought process on this so I can learn a bit?
Would you be able to explain the SecBrepPlane command and how you made it? Would it be possible to accomplish this without creating a custom component?
Thank you once again!
Er... I did nothing actually since the only way to work that thing is with the round corner style (which I suspect IS NOT desired).
See PlanB as well (via Sweep1) that also doesn't work > but I took that @#$#@ sweep1 personally > more soon (It works in Rhino, mind):
As regards the SecBrepPlane "command": it's C# code (I had plans to include 2 ways to do it ... AND some other things as well: that's the reason that I've used the C# [see for instance the very poor sweep1 options available in the GH component] but let's wait for the trad V3 update).
It's possible to do it with plain components (I'll include a Plan C option to the V3).
In the mean time get the V2.
more soon
THIS is unacceptable: now it works with the sharp corner style (I swear that it didn't).
Moral: Karma
Strange. It worked for me too. Some sort of Glitch I guess.
I have one question. When I increase the number of segments in PFrames to 200 (desired amount) the extrusions become distorted. Is this because of the direction of the extrusion? I can't seem to think why this would happen? Thoughts?
Thank you so much for all of your help. This is great!
Strange * Strange I must say (This IS NOT great):
round corners (in offset):
sharp corners (bool op fails):
It's about time for the Plan Z: to handle this entirely with C# - and use a 2nd Method for the sections (sorry about that ... but all what matters is the proper result, he he).
What do you mean "distorted" ? In what sense? (the direction of the extrusion [PS: I'll add a flip option] is irrelevant).
1M Q: why all the cases that appear easy-busy are the most challenging? (Murphy's law N666).
By distorted I mean that when I increase the number of segments in PFrames to 200 the extrusion of the sections on the far right and far left of the object do not have any thickness. The below jpegs illustrate this, on the bottom image where the segments is 200 the many of the sections do not have a thickness. The extrusion thickness seems to decrease as the sections turn more parallel to the 'ground'.
Does that make sense?
Distorted == you have some perspective in your plan view (planes are perpendicular to Plane.WorldXY since the circle is on that plane).
Dealing with this entirely with code (Plan Z): It has to do with what actually happens when offsetting the sections inwards (works OK) or outwards (it doesn't [occasionally] works ... except if the corner style is round). I have C# code that deals with that situation (it's a bit complex to explain what happens in outwards offsets, mind - but don't bother with freaky C# things > just > stick to the end result, he he).
Until V3 is 100% working in all situations > study these - blue the section, yellow the offset :
Inwards (corner style sharp):
Find a couple of minutes to finish this (was some fit curve thingy when offsetting outwards, forget about it):
You have 4 options (Note: as delivered > all "links" to GH components are deactivated: meaning that the C# does all the work as a standalone "app"):
Plan B: Sweep1 > it doesn't work > "Karma" without doubt, he he.
Plan Z: use C# as a stand alone ring maker (Lot's of information is provided in case of failure(s) [for instance: outwards offset + sharp corners + fitOffsetCurve false]). If you opt for that, delete all the rest. To allow the C# to do the rings you just toggle createBreps true:
Plan A: toggle createBreps false and use gates to redirect flow to Plan A components.
Plan C: by pass C#, make your sections via components and connect the resulting List to the (top) Gate that controls the sections List. Not recommended for a variety of reasons ... but if you insist ...
best, Peter
Wow! Thank you so much for all of your help/time. I am trying to patch plan C into A as per your instructions. I think this will help me understand the processes better. However the Data receiver (in C) that you direct me to connect to A is not collecting any data. What should I attach it too?
thanks!
Elementary (my dear Watson): "some" things were deactivated in order to pass control to that freaky C# thingy (and a flatten tree was ... er ... "forgotten", he he )
Get Plan C as standalone (but I don't recommend that: use it only for getting the gist of the whole approach).
Now ... are you ready for some really WOW things with these rings?
BTW: Plan B is actually the right/smart thing to do (with C#) but that @#$@ Sweep1 doesn't work ... I really can't understand the reason.
best
Hi AdnFrs - Peter,
I think there are allready several discussions that are about the "square pipe" (try the search box on the right).
For this case I assumed that it would be okay if I made the planar intersections with your Brep to be just a four-segment-closed-polyline. If that was indeed an allowed assumption, you can try this:
Welcome to
Grasshopper
Added by Parametric House 0 Comments 0 Likes
Added by Parametric House 0 Comments 0 Likes
Added by Parametric House 0 Comments 0 Likes
Added by Parametric House 0 Comments 0 Likes
© 2024 Created by Scott Davidson. Powered by