e tecniche di modellazione algoritmica per la generazione di forme complesse. Il corso è rivolto a studenti e professionisti con esperienza minima nella modellazione 3D e si articolerà in lezioni teoriche ed esercitazioni. Verrà rilasciato un attestato finale.
tutor: Arturo Tedeschi - autore di "Progettazione Parametrica", il primo manuale italiano su Grasshopper
special guest: STUDIO KAMI CUSTO E MANTRICI ARCHITETTI
luogo: Galleria di Architettura "come se" (Authorized Rhino Training Center)
info e programma:
http://www.comese.me.it/Arturo/PlugIt_Reloaded.pdf
…
comerciales. Rhino permite comunicar ideas en el desarrollo, investigación, manufactura, marketing y proceso de construcción de un producto o espacio, antes de ser construido y genera documentos constructivos para la elaboración de los mismos. Permite exportar los archivos a las extensiones comerciales más utilizadas en la industria como DXF, DWG, Illustrator y 3ds entre muchos otros. La gran cantidad de extensiones suplen las necesidades especificas para arquitectura, diseño de producto, calzado, joyería, ingeniería, manufactura y visualización fotorealista.
Grasshopper es una extensión de Rhino que permite el modelado paramétrico sin tener conocimientos de programación o matemáticas avanzadas, facilitando el desarrollo de modelos de alta complejidad a partir de formas simples o complejas.
Dimension
Del 12 Septiembre al 14 de Octubre de 2011
Sesiones: 15 de 3 hrs
Duración: 45 horas
Días: lunes, miércoles y viernes
Horario: de 19:00 hrs a 22:00 hrs
Costo:
Pago único: $4,000 (antes del inicio del taller)
Pago fraccionado: $4,500
Primer pago: $2,000 para reservar tu lugar.
Segundo pago: $1,250 - 26 de septiembre
Tercer pago: $1,250 - 3 de octubre
Es necesario traer Laptop Propia
En caso de requerir factura se cobrará el i.v.a.
…
rth. Current components include:
Format_GPS: Takes NMEA Formatted GPS Latitude and Longitude values and converts them to Decimal Degrees. Will add further converters.
GPS->XYZ: Maps Longitude, Latitude, and Altitude to XYZ.
XYZ->GPS: Maps XYZ to Longitude, Latitude, and Altitude.
KML_Export: Exports imported geometry to KML format. Currently implemented for points, curves, and meshes. Any Breps should be meshed before. Will be adding conditions for other geometry as well as render styles.
Look forward to a WIP release next week.
…
duino code generator works fine, but when exporting, it doesn't seem to work? Could some one please tell me what is FFcasts.h, and if that could be effecting my code? Or if there is anything wrong in general with the export.
{0}
0. /* Firefly Code Generator by Andy Payne Copyright 2011 All Rights Reserved Code Generated on 03/04/2013 20:46:37 Special thanks to Panagiotis Michalatos. For more information visit: www.fireflyexperiments.com */
#include "FFCasts.h" #include <Servo.h>
//******************* Begin Function Definitions *******************
//Remap Number Function: Remap a value into a new numeric domain. double Remap_Numbers(double x, Interval _in, Interval _out) { return (x - _in.t0) * (_out.t1 - _out.t0) / (_in.t1 - _in.t0) + _out.t0; }
//Constrain Function: Constrains a number to a specific numeric range. double Constrain(double _v1, Interval _in){ double _min, _max, result; if (_in.t0 < _in.t1){ _min = _in.t0; _max = _in.t1; }else{ _min = _in.t1; _max = _in.t0; } if (_v1 < _min){ result = _min; }else if (_v1 > _max){ result = _max; }else{ result = _v1; }return result; }
double Smoothing_pval_0 = 0;
//Smoothing Function: Returns a smoothed value that is the sum of the weighted average of the previous observations and the current value. double Smoothing_Temporal(double _v1, double _sf, double *_pval){ *_pval *= _sf; return *_pval += _v1 *(double)(1.0 - _sf); }
//******************** End Function Definitions ********************
Servo servo9;
void setup() { servo9.attach(9); }
void loop() { int APin0 = analogRead(0); servo9.write(Smoothing_Temporal(Remap_Numbers(Constrain(APin0,Interval(10,130)),Interval(10,130),Interval(0,180)),5.0, &Smoothing_pval_0)); }
…
see it, and I could be wrong, to some extend these types of analyses are already included in E+ (and HB) in the sense that we can assign schedules of certain building components and systems (e.g. shading, windows aka n.v., thermostats, etc.) according to other independent variables (mainly outdoor temperature and irradiance) that we attribute to imaginary agents.
However, this mostly represents analyses using external (to the model itself) data, and not internally calculated outputs, which are essential for assessing occupant behaviour (e.g. open window when outdoor temperature is lower than..). Thankfully, HB already includes an array of advanced components able to calculate these parameters, especially comfort parameters and daylighting.
Does that mean that we could potentially use that information as input to agents that would populate the space of our model? I am thinking here in the same terms as a wind driven rain simulation workflow would work, where first a CFD study would analyse the wind velocity for every point of the mesh and the droplets would then be dropped in that mesh and their probabilities of their routes would be calculated. In the same way I would imagine we can calculate probabilities of occupant actions in 'points in time', where occupants would change their environments given the results of the simulation. This isn't really real-time but it is still a start and it is a quite good approximation of the nowadays-popular, low-control, mechanically ventilated buildings.
Now, I believe that I could model these type of agents, and their parameters, rules, probabilities, etc. If so, how interesting and especially how difficult would it be to create the component that would take the results of the simulation for a space as inputs for these agents?
I know the above is not totally clear but bare with me as this is shaped along your comments and ideas.
(an example for inspiration from 2011, agent based model architecture: https://vimeo.com/18967658)
Kind regards,
Theodore.
…
copied at bottom). The Gaussian Elimination script (included below the pict) works fine in Rhino-Python.
Any thoughts?
"""Provides a scripting component. Inputs: x: The x script variable y: The y script variable Output: a: The a output variable"""
import rhinoscriptsyntax as rs
# Copyright (c) Isaac Evans 2011 # All rights reserved.
def myGauss(m): # eliminate columns for col in range(len(m[0])): for row in range(col+1, len(m)): r = [(rowValue * (-(m[row][col] / m[col][col]))) for rowValue in m[col]] m[row] = [sum(pair) for pair in zip(m[row], r)] # now backsolve by substitution ans = [] m.reverse() # makes it easier to backsolve for sol in range(len(m)): if sol == 0: ans.append(m[sol][-1] / m[sol][-2]) else: inner = 0 # substitute in all known coefficients for x in range(sol): inner += (ans[x]*m[sol][-2-x]) # the equation is now reduced to ax + b = c form # solve with (c - b) / a ans.append((m[sol][-1]-inner)/m[sol][-sol-2]) ans.reverse() return ans
########################################################################## # Check to see if this file is being executed as the "main" python # script instead of being used as a module by some other python script # This allows us to use the module which ever way we want.
if( __name__ == "__main__" ): #Call the function a = myGauss(x)
ERROR MESSAGE:
{0;0} 0. Runtime error (ArgumentTypeException): __getitem__() takes exactly 2 arguments (1 given)
Traceback: line 15, in myGauss, "<string>" line 43, in script…
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
he picture (4).
Previously, I had a problem with generating intersections between the two directions of the beams, but a colleague helped me by extending beams, so there was no problem with lines of intersection. But this solution has generated curl (5) at the highest vertex geometry, which I ignored in order to repair it before printing, perhaps this mean my problem with my beam spread properly. Only when the beams is 19, does not jump no problem, but I still can not distribute them properly.
(1)
(2)
(3)
(4)
(5)
I tried to show as simply as possible by removing or signing my code in GHX file.
Thank you in advance for your help
…