isseminated at the firms I've worked at:
Always write your scripts as though someone else is going to have to use and debug them without any instruction from you. This is kind of an overall governing principle that drives a lot of the other best practices.
Structure your definitions left to right. This way it is clear what is dependent on what, what executes in what order, and makes it easy to use the "Moses" tool (alt-click and drag on the canvas to spread components apart) to insert intermediate functionality to an already-existing definition.
For a given functional group (a set of components that does a well-defined thing) keep all the data going in to the group as labeled parameters on the left, and everything going out of the group as labeled parameters on the right. This is the intent of my "Best Practicizer" tool in Metahopper (now a menu item instead of a component). In essence, you're treating each group as though it's about to be clustered - you've defined what it does, what its inputs are, and what its outputs are. This makes troubleshooting much easier - if something is going wrong, you can easily isolate which group is causing the trouble by looking at inputs and outputs.3b. If you're grabbing some value or data (e.g. "STEP COUNT") many times from elsewhere in the definition, don't make a bunch of long wires that connect all the way back to the original source - grab that data into ONE labeled parameter and then connect all your inputs that need it to that - makes for one long wire instead of 20.
Annotate, annotate, annotate. Label your params (and if you're in icon mode, switch them manually to text). Label your groups. Use scribbles to mark larger regions of functionality. Use panels for "instructions" wherever it might not be clear how someone is supposed to use your tools.
Avoid "wireless" (Hidden Wires) connections. If you MUST use them, make sure you create params at both ends with matching names so it's clear what the data represents and where it comes from.
Cluster where possible. It's extremely helpful to isolate functional groups into clusters - it makes debugging faster and easier, since you don't have to wait for the whole definition to recompute when making small edits to the inside of a cluster, and it sets you up well to create code that can be re-used later on. However, don't take whole definitions and cluster them. As a rule of thumb, if a cluster has more than ~10 inputs, it should probably be broken into multiple clusters. There is a slight performance impact when clustering, because unlike an un-clustered group of components, which only executes the parts of the definition where something has changed, any time ANY input to a cluster changes, the WHOLE cluster re-computes. Because of this, a cluster shouldn't generally wrap any groups of components that are not related / don't connect with each other.
Color code your groups. Many firms develop a standard around group coloring so that it's easy to understand what parts of a definition are doing what kind of task. For instance, at Woods Bagot where I work, we have different colors for component groups that highlight inputs, outputs, rhino references, baking, and visualization. You may find that a different set is useful to you, but having a consistent standard can improve legibility. That's my 2c. At the end of the day, everyone works a little bit differently, and that's unavoidable (and not even a bad thing!) As long as you keep #1 in mind, all the rest will follow.
…
ers can be applied from the right click Context Menu of either a component's input or output parameters. With the exception of <Principal> and <Degrees> they work exactly like their corresponding Grasshopper Component. When a I/O Modifier is applied to a parameter a visual Tag (icon) is displayed. If you hover over a Tag a tool tip will be displayed showing what it is and what it does.
The full list of these Tags:
1) Principal
An input with the Principal Icon is designated the principal input of a component for the purposes of path assignment.
For example:
2) Reverse
The Reverse I/O Modifier will reverse the order of a list (or lists in a multiple path structure)
3) Flatten
The Flatten I/O Modifier will reduce a multi-path tree down to a single list on the {0} path
4) Graft
The Graft I/O Modifier will create a new branch for each individual item in a list (or lists)
5) Simplify
The Simplify I/O Modifier will remove the overlap shared amongst all branches. [Note that a single branch does not share any overlap with anything else.]
6) Degrees
The Degrees Input Modifier indicates that the numbers received are actually measured in Degrees rather than Radians. Think of it more like a preference setting for each angle input on a Grasshopper Component that state you prefer to work in Degrees. There is no Output option as this is only available on Angle Inputs.
7) Expression
The Expression I/O Modifier allows you change the input value by evaluating an expression such as -x/2 which will have the input and make it negative. If you hover over the Tag a tool tip will be displayed with the expression. Since the release of GH version 0.9.0068 all I/O Expression Modifiers use "x" instead of the nickname of the parameter.
8) Reparameterize
The Reparameterize I/O Modifier will only work on lines, curves and surfaces forcing the domains of all geometry to the [0.0 to 1.0] range.
9) Invert
The Invert Input Modifier works in a similar way to a Not Gate in Boolean Logic negating the input. A good example of when to use this is on [Cull Pattern] where you wish to invert the logic to get the opposite results. There is no Output option as this is only available on Boolean Inputs.
…
re
Minimum principal curvature
by the way, look at this picture.... if I only use surface curvature the result doesn't seems right as well. Maybe I did some mistakes? thanks :)
Gene
import rhinoscriptsyntax as rs
import Rhino as rc
a = []
b = []
if ((u or v) is None):
u = 0.5
v = 0.5
c_u = Srf.IsoCurve(0,u)
c_v = Srf.IsoCurve(1,v)
if (Density < 2 or Density is None):
Density = 2
if Scale is None:
Scale = 6
ScaleFactor = -Scale
for i in range(0, Density+1):
Normal_u = Srf.NormalAt(i/Density, u)
su = Srf.CurvatureAt(i/Density, u)
#s = Srf.CurvatureAt(0.5, 0.5)
#print(s.Kappa(0.5))
Normal_u_length = rs.VectorLength(c_u.CurvatureAt(i/Density))
#Normal_u_length = Normal_u_length*rs.VectorLength(s.Direction(0))
Normal_u_length = Normal_u_length * su.Kappa(0.5)
Normal_u= Normal_u*Normal_u_length
#print(type(Normal_u))
Point_u = c_u.PointAt(i/Density)
a.append(Point_u)
b.append(Point_u + Normal_u*ScaleFactor)
for i in range(Density+1):
Normal_v = Srf.NormalAt(v, i/Density)
sv = Srf.CurvatureAt(v, i/Density)
Normal_v_length = rs.VectorLength(c_v.CurvatureAt(i/Density))
Normal_v_lengthTuple = rs.SurfaceCurvature(Srf, [v,i/Density])
Normal_v_length = Normal_v_length * Normal_v_lengthTuple[7]
Normal_v = Normal_v*Normal_v_length
Point_v = c_v.PointAt((i)/Density)
a.append(Point_v)
b.append(Point_v + Normal_v*ScaleFactor)
mid = int(len(b)/2)
bu = b[:mid]
bv = b[mid:]…
teraction for its Correlations cycle, AA Athens Visiting School scales up its design intentions in order to investigate links among discrete individual architectural systems in its 2013 version, Recharged.
Recharged with interconnectivity on different levels, the theme of investigation will revolve around the design of semi-independent design prototypes acting together to form elaborate unified results. The driving force in Cipher City: Recharged is the synergistic effect behind complex form-making systems where interactive design patterns arise out of a multiplicity of relatively simple rules.
In collaboration with the National Technical University of Athens, Cipher City: Recharged will explore participatory design and active engagement modeling and will continue building novel prototypes upon horizontal planes.
As in 2012, the design agendas of AA Athens and AA Istanbul Visiting Schools will directly create feedback on one another, allowing participation in either one or both Programmes.
Discounts
The AA offers several discount options for participants wishing to apply as a group or participants wishing to apply for both AA Istanbul and AA Athens Visiting Schools:
1. Standard application
The AA Visiting School requires a fee of £695 per participant, which includes a £60 Visiting Membership. If you are already a member, the total fee will be reduced automatically by £60 by the online payment system. Fees are non refundable.
2. Group registration
For group applications, there will be a range of discounts depending on the number of people in the group. The discounted fee will be applied to each individual in the group.
Type A. 3-6 people group: £60 (AA Membership fee) + 635*0.75 = £536.25 (25 %) Type B. 6-15 people group: £60 + 635*0.70 = £504.5 (30%) Type C. more than 15 people group: £60 + 635*0.65 = £472.75 (35%)
3. Participants attending both AA Istanbul and AA Athens | 40% discount
For people wishing to attend both AA Istanbul 2013 and AA Athens 2013, a discount of 40% will be made for each participant. (The participant will pay the £60 membership fee only once.)
£60 (AA Membership fee) + (635*0.60)*2 = £822
For more information in discounts, please visit:
http://ai.aaschool.ac.uk/athens/portfolio/discounts-2013/
Applications
The deadline for applications is 11 March 2013. A portfolio or CV is not required, only the online application form and payment. The online application can be reached from:
http://www.aaschool.ac.uk/STUDY/VISITING/athens…
Added by elif erdine at 12:33pm on December 13, 2012
y (movement, protection, temperature regulation) but also the evolution of cultural expression precisely by exceeding the purely indexical performative relations. Designing not only for the needs but for the desires.
Computational couture looks at the creation of exclusive custom-fitted clothing (typical of haute couture) through the lens of a systemic approach, extending the sartorial techniques with 3D modeling and computation-based approaches developed in Rhinoceros and the visual programming environment Grasshopper.
Aim of the workshop is to exert, infuse and expand the sartorial sensibilities to body proportions and dress making into an algorithmic approach that loops through design and fabrication by means of laser cutting and 3d printing for the design and production of a garment. Participants will be divided in teams focusing on specific aspects of the garment related to the production technique (laser cutting or 3D printing).
////////////////////////////////////
WORKSHOP | calendar
Day 1
Introduction to algorithms and computational design for creative disciplines Basics of 3D modeling in Rhinoceros Basics of Grasshopper Introduction to basic sartorial techniques
Day 2 Testing design options for the dress in Grasshopper (tutored work)
Day 3 Fabrication session . file preparation . parts testing and pre-assembly
Day 4 dress fabrication and assembly
Day 05 finalization of dress final presentation
////////////////////////////////////
WORKSHOP | registration
FEE FOR PARTICIPANTS
Early bird (until 4/5): 250 € Full fee (from 5/5 until 15/5): 350 €
The fee includes materials and fabrication. Plane tickets and accommodation are not included in the fee.
////////////////////////////////////
REGISTRATION (until 15/5/2015)
For registration please write at :
beyond@iaac.net
for more info visit:
http://beyond.iaac.net/?page_id=1620
…
umbers behave differently from the reals, in that when they are squared they give a negative result. They are written as multiples of the imaginary unit i, which is defined so that:
i*i=-1
Complex numbers are numbers which have two parts (hence the name complex) - a real part and an imaginary part.
For example:
3+4i,
or more generally:
a+bi, where a and b are some real numbers.
Well that's a definition, but I guess you might be wondering what is the point of them - I've not said anything yet about why they are interesting and useful...
Solving cubic equations was one of their first uses, but I doubt that is what most of you are interested in.
Where they really get fun is when you start looking at them geometrically.
The Argand plane is a setting that allows us to treat complex numbers a bit like vectors.
Each complex number a+bi defines a point relative to an origin (0,0), much the same as a vector with an x and y component.
Like vectors we can add and subtract them to get a new point.
But when we multiply them, unlike vectors, we add the angles (measured anti-clockwise from the positive real axis, also called the argument) and multiply the lengths (or the modulus of each number).
This all follows naturally as a consequence of the definition of i as the square root of minus one.
........
That is just dipping a toe into the great depths.
Complex number math, and in particular complex Analysis (calculus with complex numbers) is a vast subject that I obviously can't cover much of here.
If you are interested in learning more :
The Math department at Cal State Fullerton has some very nice Complex Analysis pages.
Chapters 5 and 6 of the film Dimensions covers complex numbers very visually. You can watch it online here, or read the description here.
Complex numbers on Wikipedia
on MathWorld
Hans Lundmark's complex analysis pages
The book Indra's Pearls is about making certain types of fractals with complex numbers, and includes a good introduction, along with lots of pseudocode.
To really engage with some of the true depth and power of complex numbers I particularly recommend the beautiful Visual Complex Analysis. This was the book that made me love this subject.
I'm really looking forward to seeing more designers make use of complex numbers. I think it is a wonderful tool. It is an advanced branch of mathematics, requiring some serious study to understand, but because of its strong geometric connections, I think relatively accessible to those who tend to think more visually. Now that David has included them in Grasshopper, starting to explore them should be easier than ever.…
Added by Daniel Piker at 4:38am on November 25, 2009
can work in any node of a given hierarchy tree (loaded in your work session) by making the node "active". "Nodes" can be other things as well (like workplane, clip definitions etc).
Why to do that weird thing? Well, think any design being "flat" > meaning that all objects are placed in a single file (and in a single layer). Not that good > although the items are present you barely can handle them (because power is nothing without control, he he).
Let's go one step further: we can start classifying objects in "groups" (like a directories/files organization in any O/S). This means, in MCAD speak, creating assemblies (a void thing kinda like a directory) that contain components/entities (kinda like files).
Several steps further we end up with severely nested "arrangements" of entities (an assembly could be parent of something and child of something else).
For instance, it could be rather obvious the logical classification of a "geodetic" (so to speak) structure like this : a 40000m2 "hangar" defining some thematic park.
I mean : a void master that owns 4 equal void segment sets that own 4 "legs" that own various geodesic structural members + cables + membranes + you name it etc etc.
Each "leg" owns the concrete base (Shared) and a rather complex set of objects.
Notice that some tensile membrane "fixture" combos (see above)...act as perimeter light fixtures as well...meaning that the membrane tension plate may could be a child of a void "light" parent...or may could be a "stand alone" assembly etc etc.
These arrangements can be internal (belonging in, say, a x node within the current active file) or external (belonging in a y node within another file). If they deal with the same (topologically speaking) object they define clusters of Shared entities (or variations)- where only the view transformation matrix changes (in the simple scenario, he he). For instance the disk shown above is a Shared Assembly that owns the bolts, the plates, the tension member etc etc. Selective Instancing allows modifying some attributes without affecting the topology (i.e. the geometry).
The whole (terrible) mess is controlled by some tree like "dialog" (in Catia is "transparent") that is called Structure Browser. By controlled I mean (1) display/display mode with regard any tree member combo/selection set (assembly and/or component) in any View (2) clip state control (3) active status (for modifications/variations) (4) workplane control (5) drag and drop ownership control (6) ....
Now...what if I would chan…
this occasion, but it could be converted for DT in no time). Requires some minutes more as regards ... some things, but the usual update is due to some days.
Bad news: it's C#
Good news: User's Manual :
1. That thing (the C#, not me) after sorting (in a "sequential way", so tho speak) the panels (their order was chaotic) allows you to start the massacre by locating a focus of interest (and the user controllable +/- Range derived from it).2. The Range is variable (obviously) and takes care not to exceed the indices of the panel list (OK, that's elementary).
3. If you click the right button (Sadistic Q: where is it? he he) things are deleted and a new constantly self-updating list is your new List. Thus the massacre of panels is totally controllable. An autoZoom thing is also included (free of charge, but it's a bit nerve braking). Zoom factor is variable as well.
4. Then you move over (via the index slider) and start the massacre again. Notice the change of Range.
5. If you turn begin to false (initialization) and then begin to true > start all over again.
6. The other C# thing allows you to increment the index slider in a rather more convenient way. It's a bit weird: it uses delegates (A delegate is an object that knows how to call a method) and events (An event is a construct that exposes just the subset of delegate features required for the broadcaster/subscriber model - but don't ask what this means, he he) in order to talk with your slider (with a defined NickName) and perform the required value control.
NOTE: without realizing it you've just (indirectly) asked one of the most important questions even exposed in this Noble Forum. I hear you : what question? Well ... wait some days for the mother of all threads: "Total control in collections on a per Item basis"
may the Force (the dark option) be with you (and me)
best, Peter…