generative modeling for Rhino
I'm doing some kind of hangar these days. Definition attached is in the very early stages. I'll post the Full stuff in a couple(?) of days(?).
However...this $@^% Pline (use Saved View) when geared with a Tube component..er...makes me crazy (see alternative method to check points > (a) their order is 100% OK and (b) when applying an IntCurve on these...no problem at all).
WARNING: Tree8 is used ( http://www.grasshopper3d.com/profiles/blogs/tree8-list-management-c... )
Anyone brave enouph to find the cause of the PLine issue?
Moral: Karma, what else?
OK, appears that GH mess things when you "sample" data (in this case all 3 truss curves into one curve component)
OK, forget the previous reply (blame the triple espresso required for a proper problem solving).
The issue is in the Planer component.
Do the following : connect the flip+3 branch combo with the initial circle (connect blue to blue). See that GH can properly create a 3 branch structure (circles in the correct order etc etc). Now connect the Planar component with the flip+3 branch combo (blue to blue):
But since GH has not even the elementary solid capabilities...how to "extrude" the circle into a solid object (in this case the connecting "flange") without a Planar component?
can you not use the loft component for several circular cross sections and then use the cap brep component?
After locating the cause of the havoc (that $@%@ Planar thing) > here's a working definition (with regard the 10% of the whole, he he)
This issue cost me:
1. a postponed windsurf session (wave obviously) with a gorgeous girl (she's learning the basics).
2. 5 Cigars (Partagas obviously)
3. 7 triple espressos (Huan Valdez obviously)
Next phases: canopy stressed cables, design the base of the whole thing, planar glazing facade, putting real stuff (made in Microstation) into place.
i don't know the full ins and outs of your definition. However, I suggest you, may want to read up on trees and how grasshopper data is organized in to trees. The sets tab in gh gives a lot of options for working with data, reverse, insert etc. Path mapper, simplify and flip matrix components are also very useful.
Trees and path mappers have nothing to do with a component that alters (without any reason) the data index sequence (the Planar) or a Pipe that partially appears (or planes that orient with their own mind > see http://www.grasshopper3d.com/forum/topics/planes-on-closed-periodic...).
The point here (up to this phase) is not to avoid "cut and paste" (thus creating a far more elaborated definition) but to expose issues that can't be ignored for some future GH build.
Anyway a far more elaborated version (with far less components and no "cut and paste") is under way.
See my reply. Try using planes built using perpindicular to curve component. These frames/planes are always consistent and the XY axis never varies.
Here's a more politically correct stuff (no cut and paste - but I couldn't care less for such "correctness", he he).
PS: Definition is up to v11 by now ( = a terrible complex mess by mixing unsuccessfully apples to sardines).
Well, bad news (as usual):
Again that Loft "tolerance" problem - actually a clear dead end (see : http://www.grasshopper3d.com/forum/topics/straight-loft-puzzles-fac...)
With regard the planar glazing WIP part of the definition, a couple of lines (that belong to the corresponding transverse truss planes - the ones indicated by the "sec" designation) are attempted being lofted:
Purpose is to explode the resulting open breps (straight Loft obviously = poly surfaces) and then divide the resulting modular "faces" in order to define the planar glazing modules and then the supporting mini trusses etc etc etc.
For the very same reason as in the above link ...er... straight Loft fails to "pass" from all profiles (i.e. lines) ...and therefor the brep/explode is useless. Notice that you can't Loft the lines with other than the straight option for more than obvious reasons (the canopy triad of curves that must intersect can you tell the reason).
Only solution is to write a VB/C thing that lofts pairs of lines (1st to 2nd, 2nd to 3rd, 3rd to 4th etc etc).
Easy...provided that the Rhino SDK "API" could be like Generative Components (a paragon of clarity - so easy to come across classes and methods).