azione tramite interfaccia grafica 6 ore
Interfaccia Grasshopper
Parametri e Componenti
Operazione di Logica e Matematica
Vettori
Case study: concetto base di attrattore
Gestione data matching
Primi approcci alla modellazione parametrica – 4 ore
Trasformazioni di base (sposta ruota scala orienta)
Strumenti di Morphing
Utilizzo di Sweep e Loft e di altri strumenti di creazione superfici già noti da Rhinoceros
Esercitazione pratica: creazione del modello concettuale della Serpentine Gallery - B.I.G.
Focus sulla gestione dei dati - 4 ore
Creazione e gestione delle liste
Studio del data tree
Esercitazione pratica: creazione di un soffitto cassettonato
Creazione di geometrie tramite mesh – 6 ore
Utilizzo degli algoritmi di Delaunay
Utilizzo del Facet Dome
Utilizzo del Substrate
Utilizzo degli algoritmi di Voronoi
Esercitazione pratica: creazione di un gazebo attraverso l’uso di pattern
Creazione di ‘paneling’ di superfici curve – 6 ore
Discretizzazione di una superficie a doppia curvatura tramite pannelli piani
Strumenti analisi superfici
Visualizzazione superfici tramite falsi colori
Esercitazione pratica: creazione di una facciata interattiva
Digital Fabrication e messa in tavola – 6 ore
Interoperabilità tra Grasshopper e altri applicativi
Creazione di Truss parametrica
Gestione dell’abaco dei pezzi
Esercitazione pratica: la Facciata dello Stadio Friuli di Udine - Ipotesi di costruzione e gestione tramita fabbricazione digitale
Requisiti di accesso
Conoscenza delle tematiche CAD di base e dei comandi principali e interfaccia Rhinoceros 5.
Certificazioni
Alla fine del corso verranno rilasciate le certificazioni ufficiali da ART (Authorized Rhinoceros Trainer)
Numero partecipanti
Il corso parte al raggiungimento di un minimo di 4 persone ad un massimo di 8. Ogni partecipante dovrà essere munito di proprio computer con Rhinoceros.
Costo del corso
Il costo del corso è di 600 € + IVA
Sconto di 50,00 € per i giovani che hanno meno di 26 anni.
Ulteriore sconto di 50,00 € Early Bird per tutti coloro che si iscriveranno entro il 5 Settembre 2016
Nel prezzo è compresa l’iscrizione al FabLab Toscana – maggiori informazioni qui
FabLab Toscana
Il FabLab Toscana presenta un insieme di per i propri associati: sarà possibile l’accesso ai laboratori del FabLab (durante i normali orari di apertura), partecipare ai workshops gratuitamente o a prezzi calmierati, l’utilizzo della macchine (seguendo il regolamento interno), …
This blog post is a rough approximation of the lecture I gave at the AAG10 conference in Vienna on September 21st 2010. Naturally it will be quite a different experience as the medium is quite…
Added by David Rutten at 3:27pm on September 24, 2010
Introduction to Grasshopper Videos by David Rutten.
Wondering how to get started with Grasshopper? Look no further. Spend an some time with the creator of Grasshopper, David Rutten, to learn the
DP ($$$ aside), GC, and Grasshopper. Arthur’s original question is very important
and the exact question (and hopefully answer) I was hoping to find on a
forum.
“How to take intelligent 3D parametric generative design models (scripting, etc.) into 2D documents?" Or, deliver the 3D design for evaluation, bid, construction, etc.
I am intrigued by Jon’s comments in the same thread and would like to know how I can learn more about the process (and
pitfalls) of turning over a 3D digital generative models to a contractor/fabricator.
Are there any industry guidelines established I could use as a reference to guide our firm through this type of uncharted territory?
Arthur’s question is very reminiscent of 10 years ago when I was frustrated with the amount of time spent on the development of a 3D model design (physical and/or virtual) only to have to wipe the table clean and start the process all over again in 2D in order to document the project for delivery. From this I jumped head first into BIM and Revit, vowing never to go back to unintelligent 2D line work. I am now working on Bentley software (v8i: Microstation and Bentley Architecture) with the access and desire to venture into Generative Components. I am very intrigued by Rhino/Grasshopper primarily with the apparent ease of use and available resources assisting in the learning process – something not really available with Bentley.
In hindsight, as I am doing my software research I think the current use of Revit and BA (Bentley Architecture) are more of a “bridge”
between the past (decades of digital 2D work, i.e. AutoCAD) and where hopefully
we all will be someday in the near future (100% 3D modeling, i.e. Digital
Project??). Without having the experience
it would appear that DP/CATIA (PLM software) are closer to this than any other
type of software. As complicated as the
industry standards are for the automobile and airline industry, I feel we
(architectural industry and others) are heading in a similar direction with
total understanding (PLM/ Evidence Based Design) of a design (a whole other topic). If anything I think the market will begin to
demand it sooner or later.
Gehry (DP) article NY Times:
http://www.nytimes.com/2009/02/11/business/11gehry.html
I know these type of broad discussions (software vs. software) can be blown out of proportion on forums, but I am would like to read
the pulse of those who are already in the trenches (using Grasshopper, CATIA, Digital Project, Generative Components, others??) and hear your thoughts. Just as valuable would be other threads,
industry articles/reviews of 3D parametric generative design software.
Thanks,
Boyd…
greatly appreciate it!!
You can write the number of the question and write your answer next to it, example:
1) a
2) c
3) a) Washington University in St. Louis
4) 2 weeks (1week+1week shipping)
5) 130
6) b
7) b
The survey questions are as follows:
1)
Did you 3D print before?
5)
How much did it cost (in dollars)?
a.
Yes, for a school project
a.
Between 20 & 50
b.
Yes, for a personal project
b.
Between 50 & 80
c.
Between 80 & 120
2)
Print size
d.
Please specify if otherwise: _____ dollars
a.
Between 2 & 6 cubic inches
b.
Between 6 & 12 cubic inches
6)
Do you think the price was expensive?
c.
Between 12 & 20 cubic inches
a.
Not at all
d.
Please specify if otherwise: ____cubic inches
b.
A little bit expensive
c.
Very expensive
3)
Where did you print your object?
a.
School
7)
Were you satisfied with the printed object?
b.
Outside school: _________________
a.
Yes, it was a great print without problems
b.
Not bad, some issues
4)
How long did it take to print?
c.
I was not satisfied, very bad quality
a.
___ days
b.
___ weeks
Thank you very much to all!!
PS: If you did many 3D prints, you can post multiple answers.
Wassef…
whole design intent, but this is what Inventor is good at. The way it packages bits of 'scripted' components into 'little models' that can be stored and re-assembled is central to MCAD working.
The Inventor model shown is almost 5 years old. We don't model like that any more, however it does offer a good idea of general MCAD modeling approaches.
iParts is useful in certain situations, it could've been useful in the above model, its usefulness is often in function of the quantity of variants/configurations.
So much is scripted in GH, maybe it should also be possible to script/define/constrain/assist the placement/gluing of the results?
...
Starting point: I think we are talking across purposes. AFAIK, the solving sequence of GH's scripted components is fixed. It won't do circular dependencies... without a fight. The inter-component dependencies not 'managed' like constraints solvers do for MCAD apps.
Components and assemblies are individual files in MCAD.
Placement of these within assemblies in MCAD is a product of matrix transforms and persistent constraints. There is no bi-directional link, the link is unidirectional (downflow only), because of the use of proxies.
Consequently, scripting the placement of components is irrelevant in GH, unless you decide that each component needs to be contained in its own separate file.
This also brings up the point that generating components and assemblies in MCAD is not as straightforward. In iParts and iAssemblies, each configuration needs to be generated as a "child" (the individual file needs to be created for each child) before those children can be used elsewhere.
You notice the dilemma, if you generate 100 parts, and then you realize you only need 20, you've created 80 extra parts which you have no need for, thus generating wasteful data that may cause file management issues later on.
GH remains in a transient world, and when you decide to bake geometry (if you need to at all), you can do that in one Rhino file, and save it as the state of the design at that given moment. Very convenient for design, though unacceptable for most non-digital manufacturing methods, which greatly limits Rhino's use for manufacturing unless you combine it with an MCAD app.
One of the reasons why the distributed file approach makes perfect sense in MCAD, is that in industry you deal with a finite set of objects. Generative tools are usually not a requirement. Most mechanical engineers, product engineers and machinists would never have any use for that.
The other thing that MCAD apps like Inventor have, is the 'structured' interface that offers up all that setting out information like the coordinate systems, work planes, parameters etc in a concise fashion in the 'history tree'. This will translate into user speed. GH's canvas is a bit more freeform. I suppose the info is all there and linked, so a bit of re-jigging is easy. Also, see how T-Flex can even embed sliders and other parameter input boxes into the model itself. Pretty handy/fast to understand, which also means more speed.
True. As long as you keep the browser pane/specification tree organized and easy to query.
:)
Would love to understand what you did by sketching.
I'll start by showing what was done years ago in the Inventor model, and then share with you what I did in GH, but in another post.
Let's use one of the beams as an example:
We can isolate this component for clarity.
Notice that I've highlighted the sectional sketch with dimensions, and the point of reference, which is in relation to the CL of the column which the beam bears on. The orientation and location of the beam is already set by underlying geometry.
Here's a perspective view of the same:
The extent of the beam was also driven by reference geometry, 2 planes offset from the beam's XY plane, driven by parameters from another underlying file which serves as a parameter container:
Reference axes and points are present for all other components, here are some of them:
It starts getting cluttered if you see the reference planes as well:
Is I mentioned earlier, over time we've found better ways to define and associate geometry, parameters, manage design change, improving the efficiency of parametric models. But this model is a fair representation of a basic modeling approach, and since an Inventor-GH comparison is like comparing apples and oranges anyways, this model can be used to understand the differences and similarities, for those interested.
I haven't even gotten to your latest post yet, I will eventually.…
Added by Santiago Diaz at 10:36am on February 26, 2011