algorithmic modeling for Rhino
I am new to this group and to Grasshopper as well.
Maybe this is an easy question but as I am a beginner I haven't found the answer so far. I would like to propagate the rhombus module designed in th gh file to the designed surface. First I try to propagate the module to the surface, (with the guidance of this tutorial: http://www.p-o-p-u-l-a-t-i-o-n-s.org/video%20tutorials/INTRO%20TO%2...) but some points of the rhombus were still stay behind. I want to be designed parametrically in order to change dimensions in GH. Here I am trying to construct the module onto the diagrid pattern, I was trying to connect the points that are higher to those that are lower, but I think that I haven't understand well the trees and brunches, so I couldn't make it.
Is it possible the points that are higher to change their position regarding the sun path?
I have seen some older cases with a vector simulating the sun incidence, but I was thinking to do something similar in Ladybag.
Thank you in advance!
Several things to consider:
Diagrids are hard to work with as they generate triangular and quad faces and even the quad faces have even and odd numbers per row. If you want to panel a full surface, make sure your module works for both triangles and rectangles.
There are several (extra) components out there to generate a diagrids from surfaces. Go look for them. They typically return cells in vertices or outlines. Make sure, your module definition can work with this type of input.
Your module definition needs to be adaptable. A single point and a few sliders won't do. Look at what your diagrid output is like. Define your module relative to the diagrid base geometry (cell outlines, corner points, surface normal vector, whatever)
Thank you Hannes for your kind answer, finally I managed to to it manually from a secondary grid of lines with the cull component to clarify the pattern, because it was easier for me to define the information of the items and vectors with this way.
Now I have some troubles to offset the pattern because then I want to extrude it in order to have a printed model in the end. I hope I will manage it.
Lemonia (nice name, BTW)
In fact is the easiest of things to do stuff with "patterns" but only if you deal directly with data (datatrees, that is) via straight code. I mean ... all these GH components they make me feel a bit dizzy, he he (but the majority of users find them very handy).
Get a 10 minute job in a very "compact" thing (it's not a cluster). Obviously the points data tree could be derived from any (untrimmed) Surface of a BrepFace ... and thus doing anything imaginable it's just some lines of code more.
Notify if you want a V2 (with a myriad of options and your "surfaces" in place).
BTW: If you want to offset stuff (polylines and the likes) on surfaces ... the offset on surface IS VERY SLOW and you may encounter RAM issues as well.
Get this "hybrid" quite old def (I don't use GH components any more these days: I could easily replace all what Lunchbox does with code) on that matter. Read my comments carefully.
Thank you for the files, the first one is very useful, I will have a look on the other one as well!
I think I have to learn programming, gh work will be a lot easier this way!
Well... as I said many times (but some others disagree) the visual thing (and components et all) are just the appetizer: in fact it's impossible to do (AND maintain/evolve with some sort of teamwork) any real-life AEC thing that way (but some others disagree).
On the other hand we are engineers: we always think "in sequence" (that's the reason that I use Generative Components for my real-life AEC stuff). Thus ... the visual thing ... I mean in real-life/complex cases ... well ... (but some others disagree).
Anyway, get another 15 minutes "development" work on that one (cut and paste from many scripts of mine, you know, he he) that can be used in many ways (but requires in depth acclimatization with what it does - and why).
BTW: Some hints:
This starts from where the other was: a flat collection of points sampled in some pattern (one out of 1M):
and finally by pressing the right buttons (but where they are? he he) you get a rather clear indication about how to "offset" things on "modules" (NEVER offset things ... just Trim the "modules" with the appropriate Interval). It's a bit reverse engineering that one (since we have points and make surfaces instead of the other thing) ... but that's a matter of some lines of code more.
(a) make patterns (and torture the CPU with that barbaric try/catch thing, he he).
(b) make "frames" the fastest possible way.
I am doing a Master's project based on the manipulation of a rhomboid grid by attractor points. Starting off in a very similar way to you Lemonia. I have managed to manipulate the grid in 2D but am struggling to form the rhomboid grid in 3 dimensions. I have searched through discussions and they have helped so far.. until now..
Someone has suggested I use hoopsnake?? What I really need to do is repeat the current weaving of the grid in the y direction. Maybe the file attached will help to visualise.
Any help will be greatly appreciated!!
See these black dots? Is a grid (one dimension tree) derived via the classic way. Some other thing (a complex C#) does "patterns" (about 20) by combining the points.
Using a very simple "diamond" schema for clarity.
See these yellow spheres? These are attractors (as many as you like) working in either push or pull mode. You can remap their "influence" at will (min/max) or use some freaky random result (for freaks).
Now comes the pain: see these blue dots? These are the ex black dots that are "shifted along" the surface (in fact brep) according ... well ... some sort of complex logic based on the attractors "influence" on them (explanations later on). The main puzzle here with regard the "shift" is to use the fastest method imaginable in order to enjoy some real-time response.
But forget how these things work > the fact is that we have a NEW data tree of points on the brep (meaning: respect holes if you like so etc etc) due to the attractors and then ... well ... we can combine them with any pattern imaginable.
Bad news: only code is used for all that freaky stuff that are actually 2 separated C#: the first does the "shifting" (you can "anchor" points of interest [say at perimeter etc] as well) and the other does a variety of things related with "patterns".
Is this what you want? (forget the hexagons ... stick to the grid deformation)
Thank you for such a quick reply Peter!
The manipulation by attractors is what I am looking for but within a densely packed rhomboid grid. I am creating a similar volume of space like the Hive in Kew Gardens (2015 Milan Expo) but I am trying to manipulate the density through attractors.
In the PDF I have tried to explain graphically what I am trying to achieve
OK, got it.
I'll try to post here soon something that is "as simple" (and fast) as possible.
Speaking about speed: Imagine a point and a unitized vector and an amplitude value (due to the attractors and/or some influence restrictions etc etc).
Doing the "shift" by the book requires in fact creating a curve on the surface (the method is: surf.InterpolatedCurveOnSurface - not sure if this even exists as native GH component) and then defining a point at a length proportional to the amplitude. The curve direction depends on the push/pull desired mode as well.
Fine ... but for a zillion of points this requires a zillion of milliseconds (and soon there's no real-time response at all). Meaning that some sort of compromise is rather a must especially in artistic cases like this where we are after just about a "rough" approximation of some distortion.
On the other hand ... when time arrives to translate all that academic stuff into some kind of envelope (a truss) ... well ... this is not something easy for a novice. I'm taking having real-life cases in mind where planarity and other "trivial" things impose a lot of puzzles.
On the other hand ... approaching this via a flat grid (forget the surface shown insofar and the "shift" puzzles) and just modifying the points ( using Kangaroo) ... hmm ... tempting to exploit this way (as Plan A).
Rhombus modules appear OK at first ... only to discover later on that pose more questions than provide answers.
Think: if an observer sees a "similar" thingy ... has any meaning how the form is made?
Of course these days anything is possible.