dive into more complex parametric models. We’ll also learn tricks to keep our project responsive and enjoyable to use. Course outline
covering similar content as the first part of the primer (http://www.grasshopper3d.com/page/tutorials-1)
novel material
duration: 3 days (24 hours)
Including
An understanding of the Grasshopper interface and the visual programming theory
Base parameters, large numbers of points and vectors, and small geometrical instances
Data flow
Troubleshooting definition problems and solutions
Know the main component types
Be able to join, and manage connections and trees
Expressions for both calculation and boolean creation
Understand Data Matching and casting
Managing long lists of objects within Grasshopper
Have an understanding of the functioning of Grasshopper components
Experience creating definitions
Parametric geometry examples, like attractors and list culling
Re-utilizable modeling examples: colored panelization, surface population, gradient and picture sampling and manipulation, catenary line and weaving
Spline animation examples
Getting ready to prepare own definitions in groups
More information...
…
here are my questions.
1. The difference in general attractor transition is that, i only want the points are moving toward x axis, so if i just have ONE curve to distinguish, which is'nt the problem to find points location are in the right of left side of curve, but if i have TWO or THREE curves need to be distinguished, that is totally confused to me!
2. The points near curve which moved too big, how can i make it more equal?
3. I hope all the points can stay in the square boundary.
If anyone can give me some hint, i would be very appreciate with that.
thanks a lot!!
Shaun
…
ay how many valid permutations exist.
But allow me to guesstimate a number for 20 components (no more, no less). Here are my starting assumptions:
Let's say the average input and output parameter count of any component is 2. So we have 20 components, each with 2 inputs and 2 outputs.
There are roughly 35 types of parameter, so the odds of connecting two parameters at random that have the same type are roughly 3%. However there are many conversions defined and often you want a parameter of type A to seed a parameter of type B. So let's say that 10% of random connections are in fact valid. (This assumption ignores the obvious fact that certain parameters (number, point, vector) are far more common than others, so the odds of connecting identical types are actually much higher than 3%)
Now even when data can be shared between two parameters, that doesn't mean that hooking them up will result in a valid operation (let's ignore for the time being that the far majority of combinations that are valid are also bullshit). So let's say that even when we manage to pick two parameters that can communicate, the odds of us ending up with a valid component combo are still only 1 in 2.
We will limit ourselves to only single connections between parameters. At no point will a single parameter seed more than one recipient and at no point will any parameter have more than one source. We do allow for parameters which do not share or receive data.
So let's start by creating the total number of permutations that are possible simply by positioning all 20 components from left to right. This is important because we're not allowed to make wires go from right to left. The left most component can be any one of 20. So we have 20 possible permutations for the first one. Then for each of those we have 19 options to fill the second-left-most slot. 20×19×18×17×...×3×2×1 = 20! ~2.5×1018.
We can now start drawing wires from the output of component #1 to the inputs of any of the other components. We can choose to share no outputs, output #1, output #2 or both with any of the downstream components (19 of them, with two inputs each). That's 2×(19×2) + (19×2)×(19×2-1) ~ 1500 possible connections we can make for the outputs of the first component. The second component is very similar, but it only has 18 possible targets and some of the inputs will already have been used. So now we have 2×(18×2-1) + (18×2-1)×(18×2-1) ~1300. If we very roughly (not to mention very incorrectly, but I'm too tired to do the math properly) extrapolate to the other 18 components where the number of possible connections decreases in a similar fashion thoughout, we end up with a total number of 1500×1300×1140×1007×891×789×697×...×83×51×24×1 which is roughly 6.5×1050. However note that only 10% of these wires connect compatible parameters and only 50% of those will connect compatible components. So the number of valid connections we can make is roughly 3×1049.
All we have to do now is multiply the total number of valid connection per permutation with the total number of possible permutations; 20! × 3×1049 which comes to 7×1067 or 72 unvigintillion as Wolfram|Alpha tells me.
Impressive as these numbers sound, remember that by far the most of these permutations result in utter nonsense. Nonsense that produces a result, but not a meaningful one.
EDIT: This computation is way off, see this response for an improved estimate.
--
David Rutten
david@mcneel.com
Poprad, Slovakia…
Added by David Rutten at 12:06pm on March 15, 2013
ther math and logic. i can usually conceptualise what i want to do and cobble some semi working thing together but don't know which components to use and how to patch it. so i'm super happy to have someone who knows what he's doing to find this interesting.
and i'm glad you mention the fanned frets again, there is one input parameter that's still missing for the multiscale frets to be fully parametric, it's the angle of the nut or which fret should be straight. it depends a bit on personal preferences and playing posture what is more comfortable. so being able to adjust this easily would be cool. again i have no idea how the maths for that work or if you can just rotate each fret the same amount around it's middle point. The input either as fret number (for the straight fret) or as a simple slider from bridge to nut should do as input setting.
Here are the two extremes and the middle ground:
i've been thinkin today while analysing your patches and cleaning up my mess what exactly the monster should do.
Here are the input parameters needed, i think it's the complete list
scale length low E string
scale length high e string
fret angle/straight fret
string width at nut
string width at bridge
number of frets
fretboard overhang at nut (distance from string to fretboard bounds)
fretboard overhang at last fret
string gauges
string tensions
fretboard radius at nut (for compound radius fretboard radius at bridge is calculated with the stewmac formula)
fretwire crown width
fretwire crown height
action height at nut (distance between bottom of string and fretwire crown top)
action height at last fret
pickup 1 neck position
pickup 2 middle position
pickup 3 bridge position
nut width
the pickup positions should be used to draw circles for the magnet poles on each string so they are perfectly aligned and can be used for the pickup flatwork construction. ideally they would need a rotation control aligning the center line of the pickup so it's somewher between the last fret angle and bridge angle. personally i do this visually depending on the design i'm looking for, some people have huge theories on pickup positioning but personally i don't believe in it.
that should result in everything needed to quickly generate all the necessary construction curves or geometry for nut/fingerboard/frets/pickups. this is the core of what makes a guitar work, the more precise this dynamic system is the better the guitar plays and sounds.
i posted another thread trying to understand how i could use datasets form spreadsheets,databse, csv to organize the input parameters. What would make sense for the strings for example is hook into a spreadsheet with the different string sets, i attached one for the d'Addario NYXL string line which basically covers all combos that make sense.
The string tension is an interesting one, and implmenting it would sure be overkill albeit super interesting to try. it should be possible to extrapolate from the scale length of each string what the tension for a given string gauge of that string would be so that you could say 'i want a fully balanced set' or 'heavy top light bottom) and it would calculate which SKU from d'addario would best match the required tension. All the strings listed in the spreadsheet are available as single strings to buy.
i'm trying to reorganize everything which helps me understand it. i just discovered the 'hidden wires' feature which is great since once i understood what a certain block does or have finished one of my own, i can get the wires out of the way to carry on undistracted. a bit risky to hide so many wires but it makes it so much easier not to get completely lost :-)
btw, the 'fanned fret' term is trademarked, some guy tried to patent it in the 80's which is a bit silly since it has been done for centuries. there is a level of sophistication above this as well, check out http://www.truetemperament.com/ and that really is something else. it really is astounding how superior the tuning is on those wigglefrets, the problem is that it's rather awkward for string bending and also you can't easily recrown or level the frets when they are used. …
e matching with a dedicated component which creates combinations of items. You can find the [Cross Reference] component in the Sets.List panel.
When Grasshopper iterates over lists of items, it will match the first item in list A with the first item in list B. Then the second item in list A with the second item in list B and so on and so forth. Sometimes however you want all items in list A to combine with all items in list B, the [Cross Reference] component allows you to do this.
Here we have two input lists {A,B,C} and {X,Y,Z}. Normally Grasshopper would iterate over these lists and only consider the combinations {A,X}, {B,Y} and {C,Z}. There are however six more combinations that are not typically considered, to wit: {A,Y}, {A,Z}, {B,X}, {B,Z}, {C,X} and {C,Y}. As you can see the output of the [Cross Reference] component is such that all nine permutations are indeed present.
We can denote the behaviour of data cross referencing using a table. The rows represent the first list of items, the columns the second. If we create all possible permutations, the table will have a dot in every single cell, as every cell represents a unique combination of two source list indices:
Sometimes however you don't want all possible permutations. Sometimes you wish to exclude certain areas because they would result in meaningless or invalid computations. A common exclusion principle is to ignore all cells that are on the diagonal of the table. The image above shows a 'holistic' matching, whereas the 'diagonal' option (available from the [Cross Reference] component menu) has gaps for {0,0}, {1,1}, {2,2} and {3,3}:
If we apply this to our {A,B,C}, {X,Y,Z} example, we should expect to not see the combinations for {A,X}, {B,Y} and {C,Z}:
The rule that is applied to 'diagonal' matching is: "Skip all permutations where all items have the same list index". 'Coincident' matching is the same as 'diagonal' matching in the case of two input lists which is why I won't show an example of it here (since we are only dealing with 2-list examples), but the rule is subtly different: "Skip all permutations where any two items have the same list index".
The four remaining matching algorithms are all variations on the same theme. 'Lower triangle' matching applies the rule: "Skip all permutations where the index of an item is less than the index of the item in the next list", resulting in an empty triangle but with items on the diagonal.
'Lower triangle (strict)' matching goes one step further and also eliminates the items on the diagonal:
'Upper Triangle' and 'Upper Triangle (strict)' are mirror images of the previous two algorithms, resulting in empty triangles on the other side of the diagonal line:
…
ake a modest notice about the two new Ladybug components, one of which creates a 3d terrain shading mask and another one which visualizes and exports horizon angles. A terrain shading mask is essentially a diagram which maps the silhouette of the surrounding terrain (hills, valleys, mountains, tree tops...) around the chosen location, and account for the shading losses from the terrain. It can be used as a context_ input in mountainous or higher latitude regions for any kind of sun related analysis: sunlight hours analysis, solar radiation analysis, view analysis, photovoltaics/solar water heating sunpath shading...
My home town is an example of the shading caused by the terrain. Here is how it looks from the tallest building in the town:
And the created terrain shading mask:
A mask for any land location up to 60 degrees North can be created:
There will also be a support for a few major cities above this limit.
Both Terrain shading mask and Horizon angles components can be downloaded from here. An example .gh file can be found in here.
Component will prompt the user to download and copy certain files in order to be able to run.
It was created with assistance from Dr. Bojan Savric. Support on various issues was further given by: Dr. Graham Dawson, Dr. Alec Bennett, Dr. Ulrich Deuschle, Andrew T. Young, LiMinlu, Jonathan de Ferranti, Michal Migurski, Christopher Crosby, Even Rouault, Tamas Szekeres, Izabela Spasic, Mostapha Sadeghipour Roudsari, Dragan Milenkovic, Chen Weiqing, Menno Deij-van Rijswijk and gis.stackexchange.com community.
I hope somebody might find the components useful.…
te some cut sheets, but not to optmize material, rather define some cut lines. Everything that I am cutting is made of planar wood elements, but there are very specific geometries (mostly straight lines) and I have to put tolerances and radiasas at the corners in order to cut on the cnc mill. Spending time to figure out how to automate is necessary, but I am stuck!
One thing the definition is doing is taking my brep modeled components in rhino and makking them into 2d close curves and laying them side by side. It works...not ideal as its not layed out in a sheet, but that is not the most important part.
Another particular problem is that you will see some notches in the curves, which other pieces will slip into, so different slots need different specific offsets (making them larger) as a toelrance to allow for material play. This I don't even know how to set up so maybe it will just have to wait.
THE MAIN QUESTION, and super important would be, LIFESAVER:
At all 'inward' corners...which I think will always mean concave corners (most are 90 degrees, but are within to sides, instead of a corner sticking out). I'm sure its obviousy, but the reason being the outward corners a circular dril bit can cut, but inward ones need an arc profile extended beyond where the corner of the other piece will fit into. The drill bit i am using is 6mm, so 6mm diamters arcs is what i'm working with.
I have managed to put such an arc at every vertices of each cut piece. The problem being some stick outward isntead of cutting into the piece. So each one needs to be orieneted correctly. Ideally they would also only draw into inward corners, but I can always delete them out. I think maybe I am missing a more logical mathematical way of defining?
For these geometries it is not very important which side the half circle arc in on in the inward corners, but I also have some geometries that I will have to control where the circles face according to the rest of the cut piece.
The cutouts in the middle of the pieces that are curves do not need such corners obviously.
The picture is an example drawn
I hope this isn't too specific and long. in general though automating fabrication, and controling pracitcal math and orientation problems like this is itnersting to me!
THANKS…
derstanding of the graphical algorithm editor, and then dive into more complex parametric models. We’ll also learn tricks to keep our project responsive and enjoyable to use.Course outline
covering similar content as the first part of the primer(http://www.grasshopper3d.com/page/tutorials-1)
novel material
duration: 3 days (24 hours)
Including
An understanding of the Grasshopper interface and the visual programming theory
Base parameters, large numbers of points and vectors, and small geometrical instances
Data flow
Troubleshooting definition problems and solutions
Know the main component types
Be able to join, and manage connections and trees
Expressions for both calculation and boolean creation
Understand Data Matching and casting
Managing long lists of objects within Grasshopper
Have an understanding of the functioning of Grasshopper components
Experience creating definitions
Parametric geometry examples, like attractors and list culling
Re-utilizable modeling examples: colored panelization, surface population, gradient and picture sampling and manipulation, catenary line and weaving
Spline animation examples
Getting ready to prepare own definitions in groups
More information...
…
see in my bottom post image there is only one isocurve showing in U and V.
In Grasshopper there's no surface rebuild? Well, the same old Grasshopper Patch command will let you specify spans I guess, to make a surface from a planar curve, but it won't work for things with holes since they will just fill in!
You can recreate a surface painfully by untrimming, adding many UV points, rebuilding from those points, then retrimming with the original surface info, but the retrimming simply fails.
If you make a planar surface from a curve in Rhino, you end up with utterly no point editability:
No wonder my CreatePatch tests were a failure. The starting surface could not be distorted except in the extreme case of moving four corner points!
I have no idea how to successfully rebuild a surface akin to the Rhino rebuild command. It's great to be able to prototype in Grasshopper, but with Python I can rebuild easily ( http://4.rhino3d.com/5/rhinocommon/?topic=html/M_Rhino_Geometry_Surface_Rebuild.htm ;), so I guess I should start a collection, like peter, of little script components for prototyping with.…
Added by Nik Willmore at 6:18am on February 26, 2016
try now to integrate Geco in an interdisciplinary architectural engineering studio: hoping we can show you some nice applications of your tool, I'll keep you update and sending now details by e-mail. Here the file (very welcome to be shared). It most probably contais trivial errors by me, thanks for helping and giving some tip! Gr. Michela
FILE:
Ok, right, I see the outputs update correctly. Origin of problems must be in some different mistake I do:
- Incident radiation: I am not sure I understand what is going on: why I get so many 'not a number' ? (The Galapagos report is full of NaNs).
Bio-Diversity: 0.887 Genome[0], Fitness=NaN, Genes [89% · 44%] { Record: Too many fitness values supplied } ...
Genome[7], Fitness=NaN, Genes [74%] { Record: No fitness value was supplied } ....
Genome[9], Fitness=NaN, Genes [37% · 11%] { Record: Genome was mutated to avoid collision Record: Too many fitness values supplied }
- Daylight calculations: the geometry accumulates withouth deleting the previous models. As a consequance, results almost do not change after few varations (so, outputs get updated but do not vary). In current daylight definition: the first object being imported is the one where the grid has to fit; its setting makes it cancelling all the other objects during import. All the others, do not delete anything when imported. When running loops (manual or GA) that vary parameters, the entire geometry do not get cancelled - so I guess the loop does not pass back by the cancelling step, but imports only the geometry which has been varied by the parameters using the setting of that import component only? I will then try again by changing the order of the operations, but if you have specfic tips, let me know.
THANKS!
…