ceros.
Public concerné /
Architectes et designers, utilisateurs de Rhino souhaitant paramétrer Rhinocéros à l’aide de Grasshopper, programme
associant des composants et une structure de graphe interagissants avec le modèle Rhino.
Une bonne connaissance de Rhinocéros est nécessaire. La langue de la formation est le français.
Structure et Objectif de la formation /
La formation se déroule sur 3 jours : les 2 premières journées sont consacrées aux « fondamentaux » de Grasshopper
avec en préambule une introduction au design et à l’architecture paramétrique et leurs impacts dans la conception, la
création et la construction.
La troisième journée sous forme d’atelier est dédiée à l’étude de cas concrets proposés par les stagiaires, qui, quelques
jours avant la formation, pourront envoyer leurs projets par mail à info AT rhinoforyou DOT com
Les stagiaires, après la formation, pourront rester en contact avec les formateurs de HDA par le biais du blog
complexitys.com et le twitter @HDA_Paris. La durée de cette formation permettra d’atteindre une autonomie et une
bonne compréhension basée sur des exemples concrets.
3 Formules possibles /
3 jours ( Initiation+Atelier ) : du lundi 20 septembre au mercredi 22 septembre
2 jours ( Initiation ) : lundi 20 et mardi 21 septembre
1 jour ( Atelier ) : mercredi 22 septembre
Programme ind icatif des notions traitéES pendan t la formation /
Introduction à la conception Paramétrique . Rhinoscript, Grasshopper: différences et similarités . Interface
graphique de Grasshopper . Objets, Données, Listes . Opérateurs scalaires : La mathématique de
Grasshopper . Gestions des données : la logique de Grasshopper . Vecteurs, Points, Lignes, Surfaces : La
géométrie de Grasshopper . Listes, Arbres, Branches . Le dessin paramétrique: exercices divers et exemples
. Références, Bibliographie, Support de cours . Ateliers d’architecture et design paramétrique (3ème jour) .
Moda lité de la formation /
Venir avec un PC portable équipé de Rhinocéros version 4.0 SR 7 et de la dernière version du plug-in
Grasshopper (téléchargeable sur www.grasshopper3d.com).
Le coût du stage est de 350 € HT/jour par personne.
Réserver votre place dès que possible car les places sont limitées à 10 participants maximum.
Inscriptions et renseignements: Jacques Hababou, info AT rhinoforyou DOT com
Pour en savoir plus sur l’architecture paramétrique: www.complexitys.com…
uired information, a poor representation of data evolve misreading messages and by turn ambiguous responses especially with complex data. Inforgraphics are graphic visual representations of information, data or knowledge intended to present complex information quickly and clearly. In the nowadays flow of complex information, Infographics is the key for optimized visual communication. The use of infographics is an important step towards developing a pedagogical approach that draws on visuals where 90% of Information is transmitted to the brain so it is crucial to tickle the optic nerves to get people excited about data. The workshop investigates how computational tools can aid in designing and controlling complex information to be easily understood in addition to improve cognition by utilizing graphics to enhance the human visual system’s ability to see patterns and trends and much more likely to be remembered in today’s fast – paced environment. This workshop investigates multiple computational tools and techniques of developing coefficient visualization of data types including; network, statistical and hierarchal data. The workshop objective is to reconsider visual representation a promising design tool for architects, artists and designers. /// Application To apply, please follow this link to fill the application form https://docs.google.com/forms/d/1HOv6c1_LzhHNJU5n_FLvuhC-Yg75HDfbEcq6TN6mulI/viewform /// Fees 1200 EGP for students / 1500 EGP for graduates and young professionals more info on the workshop webpage: http://www.encodestudio.net/#!infographics/cqvl
POSTS
…
ike using something like the Z vector, but technically you can use any vector you want. This vector will actually determine the static rotatation of all the planes, so you can control that here if you like. One important thing that I've noticed is that the closer the vector is to the plane of the curve or if its too similar to one of the tangent vectors, the more likely you'll have "flipping"
2) Take the cross product between the tangent and the static vector. This will be your first perpendicular vector, which you can use for the X component of the plane.
3) Take the cross product between the tangent and the result of the previous cross product. Use this result as the Y component of the plane. All three components (X, Y, and Z (which is the tangent vector)) are all perpendicular to each other now.
After you've done that you should have planes that decrease twisting. If your curve is not planar, then there will always be some twisting in the frames, but it will be minimal enough to use them effectively.
There also may be "flipping" within the frames, which means one (or both) of two things. First, you could have planes that have reversed their vectors, so the X vector is properly oriented, but pointing down when it should be pointing up. Second, the X and Y vectors could have potentially swapped, so that Y "should" be X and X "should" be Y. In order to check these things, you'll need to do a few tests. The first one is find out whether the vector (X or Y) of the plane your testing is pointing in the opposite direction of previous vector. The second test is to find out whether the vector (X or Y) of the plane your testing is perpendicular to the previous vector. In both cases, an angle test between the two vectors will be able to tell you what you need to know, but you will likely NEVER get exactly 180 for an opposite test or 90 for a perpendicular test. That means that you have to choose a range with which to determine that a given vector is opposite or perpendicular.
You should start testing the X vector to see if anything is wrong. If you find that the X vector is fine, then just move on because Rhino will only allow you to create right handed planes, and the Z vector (the tangent) will always be the same.
I don't believe that there's a native function within the old dotNET SDK for calculating angles, so use the example at the link below. It basically takes the arcCosine of the Dot Product of the two vectors your testing to return the angle in Radians. I'm not sure if this function is included in RhinoCommon or not....
http://wiki.mcneel.com/developer/sdksamples/anglebetweenvectors…
ed when membrane cones are invited to the party (then mesh (via Starling is the best way) the brep and send data to Kangaroo : the easiest thing to do). But patch doesn't trim the inner Loops and ... well initially I thought to find this in SDK and do the job:
Well... I confess that I can't get the gist of the Brep.Trim (as explained in SDK).
Thus go to plan B: having already the closed breps (the "cones") as cutters ... attempt a Boolean difference
but this does that (this looks to me a bit paranoid, but some reason must exist):
What I want is this:
the code that mess things is (open the script inside definition attached):
BTW: where in SDK is that DeBrep thing?
BTW: Delaunay GH syntax is still cryptic to me (but this is not an issue anymore)
I would greatly appreciate any help on that final step (to greatness).
The full working definition soon (v5: with 90% of components replaced by C# stuff).
best, Peter
…
bout angle since the exact same wires can suddenly start working fine later! Just adding new items to Rhino and then using undo to get back to your failing geometry will fix it sometimes?! Flipping the pair of curves' directions, either one or both, fixes it. It's just black box broken. It happens for really boring angles near 90 degrees.
Rotating the entire pair in space has no effect.
Rescaling the lines from their joint point has no effect.
Simply cutting and pasting the lines out of Rhino back in *sometimes* fixes it, so it's angle and something else that makes certain lines "toxic."
Duplicating the pair of failed lines via alt-dragging the Rhino gumball fails to fix it.
Running the "line-like curves" through a Line component to give "lines" doesn't fix it.
Re-creating the lines by extracting endpoints fails to fix it.
Each line, if separated from each other works fine.
Grafting makes each line into its own little cylinder minus a hub.
The error is the boilerplate "Object reference not set to an instance of an object."
Once the pair spontaneously starts working I cannot reproduce the error with that pair again, though sometimes Rhino undo will get me back to failing.
CAN ANYBODY REPRODUCE THIS WITH MY FILE? If so I can submit a bug report.
Exoskeleton is here: http://www.grasshopper3d.com/group/exoskeleton
Source code is here but it's for compiling, not something I can just test in a C# component out of the box:
https://github.com/davestasiuk/Exoskeleton2/commit/f63c4aa691a7f26b...
…
s is like flattening your data PARTIALLY - chopping an index off the end of the branch paths without obliterating the tree entirely. When working with one "set" of input data, a flatten works to get these lists to match up - but when working with multiple sets, we need to be careful to preserve the original branch indices that keep all four of your original regions separate. As a rule, whenever you're feeding two data trees into any component, they should have the same number of branches. (or one should have branches and the other should be a flat list, in other cases).
The rule of thumb I tend to teach is this:
In 90% of cases...
For lists, all your inputs should either have 1 item or N items. That is to say, if you're feeding 4 items into one input and 9 items into another, something is probably wrong.
For trees, all your inputs should have either 1 branch or M branches. That is to say, if you're feeding a tree w/ branches {0;0} to {0;3} into one input, and a tree w branches {0;0;0} to {0;3;8} into the other input, something is probably wrong.
Grasshopper essentially matches up branches first, then lists second. By "matching" I mean it processes them together. Simple example of the Line component - it will match the first branch of points in the A input to the first branch of points in the B input, creating lines between those points, then match the second branches, the third branches, etc. THEN, it applies the same logic to the level of the list (with a pair of matched branches {0;2}, match all the items in those branches to each other - first item in one branch to the first item in the other branch, etc.)
This is a tricky concept but it seems like you're already well on your way to understanding it from your definition - "PShift" is a critical tool in your path management arsenal. I hope this (overly long) response helps clear things up for you!
…
he TOF and TSRF indices. They show, how "distant" is your _PV_SWHsurface from the optimal _PV_SWHsurface surface in terms of tilt and azimuth angles.However, in your case we are not interested in TOF and TSRF indices. We would just like to know what are the _PV_SWHsurface optimal tilt and azimuth angles, regardless of the supplied _PV_SWHsurface.
So the circular surface supplied to the "TOF" component's _PV_SWHsurface input is irrelevant. It can be of any area, and any tilt/azimuth angle.The PV_SWHsurfacesArea output of the "PV SWH system size" component depends on a couple of factors:moduleActiveAreaPercent_ (leave it at 90%).
moduleEfficiency_,
systemSize_.Calculation of systemSize_ depends on your electricity demand, cost of the PV system, type of the object, country, local regulations etc. This is something that an engineer needs to determine.For example, in USA for a residential house in the Sunbelt, depending on finances, a household would try to cover 100% of its annual electricity needs with their PV system. Which means that the systemSize_ you chose needs to cover the annual electricity consumption. You can perform EnergyPlus simulation or use any other way to get the annual electricity consumption.
Ladybug "Photovoltaics Performance" component can calculate the optimal systemSize_ by given the annual electricity consumption.However the component is made to address fixed tilt and azimuth PV systems only.An approximate way to overcome this is to calculate the optimal systemSize_ for fixed tilt and azimuth PV system, and then multiply it with the "difference in %s" panel at the very right of the fixed_vs_tracker_PV2.gh file. Again, this is not what Ladybug "Photovoltaics Performance" component is made to do, but it will probably get you in a ball park.
Inputted 32 degrees for north_ direction is actually 328 degrees.This is due to Ladybug Photovoltaics being based on NREL model which uses clockwise angles convention. This convention is also most commonly used in solar radiation analysis.
Dubai weather data files are uploaded in here.
…
GH, same as using sweep2 command in Rhino.
The one on the right is what I got so far (the output smooth our the kink of the original rails). Basically I am just following the methods provided by sdk sample: http://wiki.mcneel.com/developer/sdksamples/sweep2 .
The following is the function I copy and use directly from the SDK sample. By using this function, I can generate the sweep surface at right. But I want to have is the one in the middle with the kink edges. Can anyone show me how and where to modify he settings? I guess some sweep arguments need to be changed? I have try couples, such m_simplify, m_bSimpleSweep, m_bSameHeight, m_rebuild_count... but still cannot find a right combination for this function to output the sweep surface I want. Any suggestions or helps are very appreciated. Thanks for your help and time on this.
'Sweep2 function'----------------
Sub Sweep2( ByVal Rail1 As IOnCurve, _
ByVal Rail2 As IOnCurve, _
ByVal sCurves As List(Of IOnCurve), _
ByRef Sweep2_Breps As List(Of OnBrep))
'Define a new class that contains sweep2 arguments
Dim args As New MArgsRhinoSweep2
'Set the 2 rails
Dim Edge1 As New MRhinoPolyEdge
Dim Edge2 As New MRhinoPolyEdge
Edge1.Append(Rail1.DuplicateCurve())
Edge2.Append(Rail2.DuplicateCurve())
'Add rails to sweep arguments
args.m_rail_curves(0) = Edge1
args.m_rail_curves(1) = Edge2
args.m_bClosed = False
Dim section_curves As New List(Of OnCurve)
'Loop through sections to set parameters
For Each Section As IOnCurve In sCurves
Dim sCurve As OnCurve = Section.DuplicateCurve()
section_curves.Add(sCurve)
Dim t0 As Double = 0
If Not Edge1.GetClosestPoint(sCurve.PointAtStart(), t0) Then
If Not Edge1.GetClosestPoint(sCurve.PointAtEnd(), t0) Then
Dim s As Double = 0
sCurve.GetNormalizedArcLengthPoint(0.5, s)
Edge1.GetClosestPoint(sCurve.PointAt(s), t0)
End If
End If
args.m_rail_params(0).Append(t0)
Dim t1 As Double = 0
If Not Edge2.GetClosestPoint(sCurve.PointAtStart(), t1) Then
If Not Edge2.GetClosestPoint(sCurve.PointAtEnd(), t1) Then
Dim s As Double = 0
sCurve.GetNormalizedArcLengthPoint(0.5, s)
Edge2.GetClosestPoint(sCurve.PointAt(s), t1)
End If
End If
args.m_rail_params(1).Append(t1)
Next
'Set shapes
args.m_shape_curves = section_curves.ToArray
'Set the rest of parameters
args.m_simplify = 0
args.m_bSimpleSweep = False
args.m_bSameHeight = False
args.m_rebuild_count = -1 'Sample point count for rebuilding shapes
args.m_refit_tolerance = RMA.Rhino.RhUtil.RhinoApp.ActiveDoc.AbsoluteTolerance()
args.m_sweep_tolerance = RMA.Rhino.RhUtil.RhinoApp.ActiveDoc.AbsoluteTolerance()
args.m_angle_tolerance = RMA.Rhino.RhUtil.RhinoApp.ActiveDoc.AngleToleranceRadians()
Dim sBreps() As OnBrep = Nothing
If (RhUtil.RhinoSweep2(args, sBreps)) Then
For Each b As OnBrep In sBreps
Sweep2_Breps.Add(b)
Next
End If
Return
End Sub
…
r graphics get saved as 24x24 pixel images before they are put into the grasshopper application, which means the icons look like crap when you zoom in. This is the aforementioned problem that needs to be addressed in GH2. There have historically been two approaches to this issue:
Provide pixel images with several sizes.
Render vector graphics directly.
Option 1 is common for apps that do not have variable levels of zoom, such as Windows Explorer. When explorer shows file icons it either shows them in 16x16, 32x32, 48x48, 96x96, or these days, various HUGE sizes. As a result *.ico files allow you put in different images for all these target sizes. Since Grasshopper has variable zoom levels, this is not an ideal solution. Also, it requires a lot more work per icon.
Option 2 is becoming more and more popular as increased graphics speed now allows for the real-time rendering of vector graphics. Yet, you still need a renderer that knows how to draw vector geometry crisply at low sizes. All vector renderers I know just interpolate the geometry linearly and if a line happens to end up 'between pixels' it's just fuzzy.
I don't have hard and fast rules for the icons, but I try to adhere to at least these:
Keep a border of 2 pixels free around the icon content. So basically only use the inner 20x20 pixels rather than the 24x24 you're allowed. This is needed because the drop shadow needs to go there.
Only draw silhouette edges around shapes, not inner creases. Typically a 1-pixel line will do. I prefer to use a dark version of the fill colour rather than black for edges.
Loose curves can be drawn in 1 or 2 pixel thicknesses, depending on how important the curve is.
Try to avoid text in your icons (not always possible).
Stick to 1 colour family per icon, preferably per icon family. You can add highlights with another colour if you must, but too many hues make an icon hard to read (for the example the [Voronoi] icon, it has red, green and blue and it's a bit of a mess, on the other hand [Colour Wheel] has the full spectrum and seems to work quite well...).
Very roughly speaking, if there's both black and red geometry in an icon, it means the red is component input and the black is component output.
Drop shadows are pixel effects, applied to the 24x24 image. They have a blurring radius of 2 pixels, a horizontal offset of 1 pixel to the right, a vertical offset of 1 pixel to the bottom and they are 65% black.
When you use high contrast shapes (for example black edges on a light background) the anti-aliasing provided by vector renderers such as Xara or Illustrator won't be enough to make it look smooth. I'd recommend avoiding high contrast if at all possible, but if not possible then draw a 1-pixel line around the dark bits in 95% transparent black. This effectively extends the anti-aliasing range from 1.5 to 2.5 pixels and it helps make things looks smoother.
--
David Rutten
david@mcneel.com…
ARRAY with certain spatial order or mechanism under consideration of ecological design. The evaluation and definition of “ARRAY” are open to applicants’ imaginations. While the term “ecological” is subjected to many definitions: social, ecological, sustainable, its re-evaluations are open to students’ interpretations. Entrants are free to choose or make site, real or virtual.
ELIGIBILITY
Open to international students in the fields of architecture and design related disciplines from an accredited four-year or five-year architecture program. Graduates with certificate in 2011 are accepted. Teamed collaboration consisting of no more than 3 students in the above mentioned fields is permitted. Works submitted must be of applicants’ original works. Works done through school studios are accepted, but limited to 2011 term.
ENTRY FEE
Free
DEADLINES
Online Registration deadline: Oct 30th, 2011, 17:00 Taipei Time
(Upon completing registration, applicant will receive a registration number via email.)
Submission deadline: email sent by Nov 3rd, 2011, 17:00 Taipei Time
SUBMISSION REQUIREMENTS
This is a digital competition and no hardcopies are necessary. Entrants must submit their proposal via email no later than Nov 3rd, 2011 17:00 (Taipei Time) to the following email address:
hojenhwang@mail.ntut.edu.tw
The project submission must contain the following files:
1. Two A1 boards in portrait format (594mm x 841mm), with identification number at the upper right corner. Names and other identifying information are not allowed on front side of the boards. The resolution of the boards must be 300dpi, RGB mode and saved as JPG files.. The files must be named after the registration number followed by the board number. For example: 03956-board1.jpg and 03956-board2.jpg.
2. A DOC file containing the project discription (600 words max). This file must be named after the registration number followed by the word "discription". For example: 03956-discription.doc.
3. A scan of statement form. This file must be named after the registration number followed by the word "statement_scan". For example: 03956-statement_scan.jpg.
4. All the files must be placed in a ZIP folder named after your registration number. For example: 03956.zip. Size of the ZIP folder is suggested to be less than 15mb, while size more than 25mb will not be accepted
AWARDS
(1) Gold Prize winner will be awarded TWD 60,000 and a trophy.
(2) Silver Prize winner will be awarded TWD 30,000 and a trophy
(3) Bronze Prize winner will be awarded TWD 15,000 and a trophy
(4) Honorable Mention winners will be awarded TWD 5,000 and a merit certificate
Winners will be announced and notified by mid of Nov, 2011.
JURY
Two stages of open jury. Details to be announced
PUBLIC EXHIBITION
Nov 13, 2011~ Nov 18, 2011 at NTUT, Taipei
…
Added by Yu-Min Su at 2:03am on September 23, 2011