Grasshopper

algorithmic modeling for Rhino

Well friends

1. I've imported some rails/profiles from Microstation (on purpose with different directions) - see in other layers the imported MS sweep (tool used: loft N curves across M guides).

2. Then I've tried the VB sweep component: results are odd to say the least, especially after reading the VB script.

3. Then I've tried Lofting the very same curves : appears that each component interprets differently the directions in curves (compare true/false flip combos between the two cases, curves are picked with the same sequence).

Best, Peter 

Views: 530

Attachments:

Replies to This Discussion

Seems to work ok with the GH sweep, but perhaps I misunderstood the question.

Distance for 10000 points between the sweep and the surface in your default layer:

average 0.015, max 0.1486, standard deviation 0.024

Thanks for replying,

In fact I use this approach of yours always since the Sweep/Loft algos they lack any co-direction sorting capability (but I wonder why, this "sort" should be provided by the component algorithm anyway...at least with regard 99.99999% of cases).

To further clarify the thread:

In fact this is an indirect way to suggest the obvious enhancement required concerning the Loft/Sweep logic (that said, I can think several other cases with input "sorting" issues)

Other than that and since there's only one direction per curve it's rather clear that there's some bug around in the way that the 2 components understand the term direction.

But out of curiosity can you explain why the VB Sweep does what it does?

Best, Peter

I agree with you about enhancing loft and sweep, they sometimes are tricky to use correctly.

The VB component is written using the old Rhinocommon SDK, that may be the cause of the bug.

RSS

About

Translate

Search

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service