Grasshopper

algorithmic modeling for Rhino

Well friends,

As everybody knows Loft can't "align"  a thing or two : i.e. adjust seams/directions (in most of cases) and hilarious results occur (in most of cases).

I mean this :

instead of that:

So I said to myself : post (again) something in the errors/bugs category. But then I said (also to myself) : why ? everybody knows that ... post something fun(?) in the examples that can(?) guide(??) people out of the rabbit hole.

And here we are : 4 test surfaces, 4 paneling methods, 2 profile "classes", 2 orientation options, 3 methods to skin a cat, 2 methods to find intact panels (in "any" surface - trimmed or not with or without holes), 2 presentation alternatives, 7 gates, 2 filters, 1 Branch controller(?), 1 secret component (related with sardines) = let me make the maths : about 123,45 Loft examples (a bit primitive to indicate the main issue). 

NOTE: GH quite frequently (a) fails to internalize data (b) internalizes them and reports the data as "null". Use Rhino file if this is your lucky day.

NOTE: Lunchbox is required

NOTE: Proper Named Views were defined ... but then components are moved ... blah blah: make your own.

best, Peter

Views: 1410

Attachments:

Replies to This Discussion

Hi Peter,

There's a useful method Curve.DoDirectionsMatch which can tell you whether the two curves you are about to loft, have the same direction or not. If not you could flip one of them, and then perform the loft.

Good catch my friend (I'll give it a try). Of course in this case things are easier since we are sure that the Lunchbox made panels are 100% OK (enable the disabled "check" components ...

...to see that) as regards a consistent origin and direction policy.

In the mean time :

1. Appears that the GH Loft messes things somehow with respect the curve's coordinate (planes) system "per Loft pair" . Explain this:

I mean that some pairs of profiles are "almost" OK whilst others are in a terrible mess (spot the gray thing) . Given the fact that the coordinate system deployment is highly problematic as well (notify if you want proof/test cases) I believe that the whole problem has 2 separate fault "categories".

2. Appears that the adjust seam ... er ... alters the direction (remove the flip stuff and test it).

3. Sweep1/2 are equally problematic - next forth coming case: 123,45 Sweep1/2 examples.

Update,

Good news: I've spend 5 minutes to do the C# thing (it works but without adjusting the seam(s) is useless, at least in most of real life cases).

Bad news: I've spend 5 hours searching where in SDK the curve adjust seam could(?)/may(?) be.

Moral: Long is the path (and hilly)

There isn't a specific RhinoCommon method which deals with adjustment of seams.
David posted a VB solution for adjusting the seam here. Check for the closest point between the first curve and the second one. If distance from that closest point to the startpoint of the second curve is larger than tolerance value, modify the start point of the second curve to value of the mentioned closest point.

Er...this is exactly the method that I've used in the gh posted (Plan A assumes that panels - the Lunchbox made stuff - are OK and adjusts the other profiles [seam/direction] and Plan B changes both panels and profiles [seam/direction]).

Anyway (in the Name of Science, he he) I'll modify that match direction(s) C# thing ASAP (new name : FireAndForget) in order to get rid of all the components shown.

In the usual update [V2 : more test surfaces, more options, more gates, more chaos, more is less] there's a honorable mention of djordje as the man who knows better than anyone where to search what.

PS: you would love Quest3D I suspect (the thing that pioneered the visual thing many years ago, best "SDK" (kinda) access imaginable, the best VR affordable app known to mankind - try it).

best, Peter

Thank you for the kind words Peter. I don't think I deserve it, though.
Wow, just checked on Quest3D! This is amazing. I have been using their architectural package Lumion3d, but Quest seems to have far better possibilities. And it's two times cheaper!
You are familiar with HLSL programming? Those are some nice software skills you have there Peter.

1. HLSL : yes. In fact the old days I was trying to convince Bentley Systems (Microstation) (a) to abandon the archaic way of making frames for animations (and buy Act3D) AND (b) fire all gurus responsible for the archaic rendering engines used by Microstation (and go to bed with Luxology). Plan succeeded 50% : Now Microstation uses the Luxo rendering engine (best around, bar none) ... and ... er... hmm ... animations are still archaic. The amusing thing is that at that time some Bentley gurus said to me that I'm entirely off-topic by supporting a weird thing that is based on a weird "visual programming" thing - but what do I know from things? he he.

Enjoy me searching the truth out there (it's the usual exe stuff made via Quest3D in nanoseconds). KPOD was my nickname at Bentley Systems (Known Prince Of Darkness, that is - see my avatar).

2. As regards the Loft chaos > get this very old Loft test as well > adjust seams false ( = good things), true (= chaos).

Moral: we all live in a yellow submarine.

Attachments:

Forgot to check this post, sorry.

Nice!! Both animation and twisted loft shape.

The Bentley gurus were "right" - seems like there's not future for "weird visual programming things". Just take a look at grasshopper :)

RSS

About

Translate

Search

Videos

  • Add Videos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service