Grasshopper

algorithmic modeling for Rhino

Sorting and grouping of points lying on the lines of the grid

Welcome colleagues


Please tell me whether it is possible as that sort points lie on the grid, so that they are in pairs as shown in figure !?

Meshedit http://www.food4rhino.com/project/meshedittools?etx

Kangaroo http://www.food4rhino.com/project/kangaroo?etx

Views: 1606

Attachments:

Replies are closed for this discussion.

Replies to This Discussion

BTW: Remember our Skype session?: after seeing what you are actually doing I said (was exactly when my dog started  complaining ... he he) that you need to evaluate a Curve AT A SPECIFIC LENGTH (in order to get your MERO nodes correctly): thus use this [Curve.PointAtLength Mathod] instead of the component that you are using [Curve.PointAt Method] - silly me that I've used that (NOT for your cases: forget it).

more soon

Peter, do not be so hard on me I'm just not long Padawan dark side)))))
I have not worked through [Curve.PointAtLengthMathod] (((((
help me please !!! ((((

Attachments:

Peter, thank you very much !!!
I only have one small question, how do I get these lengths here !? we did not get a closed loop? Now I have here is not correct!?

)))))))))))http://www.youtube.com/watch?v=q1K9EH90CyA

Attachments:

OK, let's forget all these (too messy for my primitive mind):

I'll prepare The Carrot ASAP: In plain English: get that #%$@ mesh and create:

1. Grid Points in order (a la U/V style).

2. Triad Pts in order to deal with the contents of the MERO structure (like glass, panels, polycarbonate). That is what the C# does already.

3. Vectors (a la "Umbrella" sticks) in order to place correctly your MERO nodes (the "hexagon" brackets - so to speak). That is what the big C# (the one that I've send to you some time ago) does already.

4. Calculations (lengths, angles) for each node against the other related nodes and the points derived from dividing the MERO square "tubes". For a given node these points are variable (from 2 [when in the "bounds" of mesh] to 6 ["typical" middle point, so to speak].

5. Demo block instances in order to see first hand what GH can actually do (that's WOW stuff: you slide a slider and "several" real-life components are placed in 3d space in real-time, he he).

6. Node connectivity data for the obvious (assembling the MERO on site).

7. Some assembly "simulation" capability (we do this today and this tomorrow ...)  

So forget the single carrot (plenty carrots for you soon) for a while and answer to the most critical question: Based on what you've displayed to me  (Skype) what is your policy against the MERO node itself?

I mean: we don't deal with a classic MERO ball type here (meaning variable drilling axis per ball). Meaning that the "hexagon" bracket (if I may use the term) IS VARIABLE. Meaning: you need a "module" that can being adapted against "every" possible (logical) angle value? (and compose the bracket?) Or you gonna fabricate the "brackets" on a per node basis?

And what if we had a planar glazing system? (same principle, more expensive, 100 times more WOW).

BTW: The best man in the world to do "similar things" with "hinged" custom aluminum systems (like doing the blue facade that you've displayed to me with some semi structural/structural system) he's a very close friend of mine. He's based in Dubai UAE.

BTW: Imagine doing this - quite "close" with what are you after (It's driven entirely by C# the yellow [obsolete] components are from another prehistoric GH test case, forget them).

You change the "canopy" topology and all these things are placed instantly in the correct Plane (classic PlaneToPlane transformations from Plane.WorldXY to any node Plane using block instances [shared components in CATIA/NX speach]).

So we are taking about a bunch of carrots here, he he (and that's the reason for using solely C# for that type of stuff - not to mention "consolidating" a myriad parameters that control this chaos).

BTW: This is a variable (very expensive, mind) custom designed planar glazing (or polycarbonate) node system that can adapt (up to a point) to topologies like the blue facade of yours (or your other "canopy" cases). 

It's obvious why we need an "umbrella" stick (sum of normal vectors per face per node) thing in order to place the main bracket at the correct plane (per node).

Compare VS the other (also very expensive) "static" system.

Attachments:

BTW: Carrots (a lot's of them) are under way > the mother of all C# scripts is under an intensive Beta(*) test (only 56.67 divisions by zero: but I'm trying to reduce that to a reasonable 56.66). The only thing that you have to do is to control a "few" variables (around 30, but who's counting? he he).

BTW: IF you have plans to modify data (either mesh Lists or surface Lists) then by NOT using normalized divisions ... we need some guidance (like getting the average length) other wise ... we should adjust EVERY time our EvaluateAtLength value. This obviously is not the case when we use normalized values (0 to 1) but that's 100% wrong for your case.

(*) satisfaction guarantied otherwise keep the Vodka frozen in Russia.

more soon, he he

Questionnaire (in order to reduce parameters from 30 to 29 ,he he):

1. Do you ever modify the mesh/surface (in order to "optimize" the MERO nodes of yours?). Or the client delivers this to you and asks for some solution "as it is" no matter the cost? (that's an extra stupid approach, very old fashioned). Do you use EvoluteTools Pro and/or Kangaroo for "optimization" ?

2. What is the FEA/FIM stuff in use? Do you expect "from/back" interactions? (If this is not doable ... increase this or that etc etc).

3. Do you validate real-life components with FEA/FIM? By what means you design these components? - present and/or future (inside Rhino?). This makes things "interesting" in a variety of ways (we need to extensively talk about that - Skype). The problem is that Rhino IS NOT  a feature driven solid modeling app and thus ... a "certain" bottleneck arrives in no time: In the CATIA world you design ("MANUALLY") a parametric history driven component that "complies" to his parent "directives" (say: the Topology) and/or "imposes" his rules to his parent. This is what we call top<>bottom design approach (would become a standard across the AEC industry pretty soon: in around 123 years give or take some). This is far and beyond from what Rhino can do - but we DO make real-life things don't we?

4. Are all these things under a BIM umbrella ? What BIM? What type of details (blue prints) you deliver? (or you just make the thing?).

5. By what means cost is restricting/encouraging the solution? By what means you get feedback from component(s) cost that is outsourced? (i.e. outside your company). Do you monitor all things via some RDBMS? (that's Data Base).

6. What are the long term plans for dealing with such solutions? Using what apps (even in theory for the moment).

Carrot report:

See this?

Now see that?

And that?

I hear you : big deal ... what are these white stupid things?

Well ... they are 256 VERY complex (and hugely expensive) variable MERO parametric nodes treated as instance definitions (designed by yours truly far and away from Rhino for some project "similar" with yours) each of them yields a 5Mb Rhino file. Did I mentioned that they are placed instantly and they can "follow" any change in your topology in real-time? No I guess that I've forgot that, he he.

This is what you'll get: a super carrot, that is. Keep that Vodka ready.

RSS

About

Translate

Search

Photos

  • Add Photos
  • View All

Videos

  • Add Videos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service