horas.
Los datos al contextualizar la fachada serán:
Vehículos (ISD: input social data)
Personas (ISD: input social data)
Edificaciones contiguas: (UI: urban input)
Sol (Radiación e iluminación): (EFI: energetic flow input)
Creación de energía solar y térmica: (ECI: energetic contribution input)
Objetivos específicos:
Cada asistente generará una fachada contextual a esos 5 inputs.
Entenderá la plataforma de Grasshopper
Comprenderá los conceptos de diseño generativo
Usará los conceptos de programación orientada a objetos (POO)
Generará renders y modelos físicos de la fachada (Fabricación digital)
Costos: $3,250 alumnos $4,180 alumnos de posgrado y profesores $4,830 profesionales
Aulas VI salón 6205, ITESM CEM
Informes: (55)-34449396 mexdf@krfr.org bioarchitecturestudio@gmail.com
Para más información visitanos en:
Fachadas ContextualesWorkshop >Fachadas Contextuales< KRFR|SEEDKRFR|SEED Red Internacional de Investigación OR/gan
http://www.bioarchitecturestudio.wordpress.com
…
tal fabrication tools. DLAB will investigate natural growth processes in relation to innovative concepts of architectural tectonics and fabrication. We will carefully interweave these concepts with interaction and participatory design to create full-scale working prototypes. The programme will be formulated as a two-phase process. During the initial phase participants will benefit from the unique atmosphere and facilities of AA’s London home. The second phase will shift to AA Hooke Park campus and revolve around the fabrication and assembly of a full-scale architectural intervention.
Some of the most prominent features which the participants will be exposed to during DLAB include:
Teaching team: Participants engage in an active learning environment where the large tutor to student ratio (5:1) allows for personalized tutorials and debates.
Facilities: The Digital Prototyping Lab (DPL) in AA London houses cutting-edge facilities for the fabrication of physical outputs through digital fabrication techniques. The facilities at AA Hooke Park allow for the fabrication of one-to-one scale prototypes with a 3-axis CNC router.
Computational skills: The toolset of DLAB includes but is not limited to Rhinoceros, Processing, Arduino, and Grasshopper.
Theoretical understanding: The dissemination of fundamental design techniques and relevant critical thinking methodologies to the participants through theoretical sessions and seminars forms one of the major goals of DLAB.
Professional awareness: Participants ranging from 2nd year students to PhD candidates and full-time professionals experience a highly-focused collaborative educational model which promotes research-based design and making.
Fabrication: According to the specific agenda of each year, a one-to-one scale prototype is fabricated and assembled by design teams.
Lecture series: Taking advantage of its unique location, London, DLAB creates a vibrant atmosphere with its intense lecture programme conveying the diverse expertise of professionals in the areas of digital design and fabrication techniques.
Applications
The deadline for applications is 8 July 2013.
An application can be made by completing the online application form or completing the PDF application form and emailing it to visitingschool@aaschool.ac.uk.
Fees
The AA Visiting School requires a total fee of £1,660 per participant, which includes a £700 deposit and a £60 Visiting Membership.
Fees are non-refundable. Fees do not include flights. Train tickets between London-Hooke Park, accommodation, food in Hooke Park, and materials are included in the fees.
Students need to bring their own laptops, digital equipment and model making tools.…
he last nights, let me try to describe it:-disclaimer: I'm an industrial designer, my coding experience can be compared to your, when you were 4 year old :)-disclaimer 2: I did a picture at the end of the post that maybe explains more than my words
the component has 2 inputs (Start Value, End Value) and one output (Picked Value)
this phantomatic component (which I would refere to as "dynamic value picker") supports any amount of domains on every input -> it works as if they come grafted, from a "longest list" component
The component "at rest" shows only one slider -with question marks on both edges-
For every couple on inputs you connect (1 Start Value connection + 1 End Value connection) it would visually generate a new slider (exactly like a "number slider" component)main difference from the "number slider" component, this one would show the Start Value and End Value numbers at the edges of each thus generated slider
Right click -> edit on it would recall a window similar to the "number slider", with the main difference that only the first part of those options would be present (see attached image for clarity)Whatever slide accuracy you set, it will affect the whole "dinamic value picker" phantom component (if you set "integer numbers" and for any reason one or more inputs are "floating points numbers", the component automatically rounds the inputs to the best "Integer", and allows you only to pick integer numbers in-between)
If you suddenly change a "Start Value" or an "End Value" input, the affected slider/sliders in the component will try to stay as close as possible to the same % value they were before (example if the domain was from 5 to 11, integers only, and you first picked the value 8, the slider was exactly in position 50%: when you change the End Value domain to 21 the slider will set itself to 13 - yes, I picked an easy one lol )
When you first plug a couple of Start Value + End Value, the slider sets itself to Picked Value = Start Value
It could also be possible to supply negative values as Value End and positive values as Value Start: the slider let you pick a number on that domain regardless of the numerical order you use
Last thing, but it's just fancy imagination, if you zoom-in the output (Picked Value) connection dot, a little - and + appears (like in other common components), letting you add a new cursor to every existing slider (it could be possible to customize the color of the new cursor to avoid confusion)
This is the exact description of what I would ask to the lamp genie :)
I attach a pic I just did, in the hope to better explain myself: picture link
and of course thank you again for reading this long poem!
…
ed to do:
FOA_Bundle_Tower.pdf
The tower height is a variable
The degrees of symmetry in plan is variable from 2 to 10 (2 bundles up to 10 bundles; the actual project has 4 bundles made from 8 individual towers or tubes).
The overall radius or diameter of the circle on which each tower is located is a variable
The tower should match the overall topology of the Bundle Tower: each tube should alternate between touching its neighboring tube on the left and right twice.
The number of floors is a variable
Overall tower height: 500m- Floor to floor height: 4.5m (I recommend that you increase this to 10m while testing)- Each tube's plan roughly has an area of 1000m2
this is what i have got so far:
foa tower.ghx
I just need guidance because i am soo lost. thank you
…
e2) Dim plane3 As New Plane(ap, dp, ep)
planeList.Add(plane3) Dim plane4 As New Plane(ap, ep, bp)
planeList.Add(plane4) Dim plane5 As New Plane(fp, cp, bp)
planeList.Add(plane5) Dim plane6 As New Plane(fp, dp, cp)
planeList.Add(plane6) Dim plane7 As New Plane(fp, ep, dp)
planeList.Add(plane7) Dim plane8 As New Plane(fp, bp, ep)
planeList.Add(plane8)
For i As Integer = 0 To planeList.Count - 1 Step 1
Dim transf As New transform()
transf = transform.ChangeBasis(planeList.item(0), planeList.item(i))
Dim newmesh As New mesh
newmesh = oldMesh
newmesh.Transform(transf)
meshList.Add(newmesh)
Next
================================
So why it doesnt want to work ?
I obtain 8 meshes all in the same place as mesh based on plane1
rhino4, grasshopper 0.8.0050
…
Grasshopper contains a VB.net and C# component. These components
allow you to run your own custom code within Grasshopper.
Understanding how to make even simple code components can be very
useful in G
odellazione digitale, approfondendo le metodologie della modellazione algoritmica e parametrica nel campo dell’architettura e del design del prodotto. Il corso è rivolto a studenti e professionisti dei settori della progettazione architettonica, design, moda e gioielleria. L'evento sarà trasmesso live e sperimenterà innovative forme di interazione tra docente e partecipanti. Le lezioni saranno registrate e sempre disponibili per gli iscritti. Sarà rilasciato un attestato di partecipazione.
_
TIPO DI EVENTO: LIVE WEBINAR (le lezioni saranno registrate e sempre disponibili per gli iscritti) QUANDO: 05 Dicembre (14.00 - 19.00), 06 Dicembre (14.00 - 19.00) DOVE: Piattaforma Clickmeeting (gli utenti iscritti riceveranno un link univoco) DURATA: Evento live di 2 giorni - 8 ore effettive di lezione LIVELLO: base (il corso è pensato per studenti senza alcuna esperienza specifica in Rhino/Grasshopper) SOFTWARE: Rhinoceros, Grasshopper, Ladybug (i link al download dei software in formato trial verranno forniti agli iscritti nei giorni precedenti l'evento). PREREQUISITI: esperienza base di modellazione tridimensionale (sviluppata su qualsiasi piattaforma) LINGUA: Italiano INTERAZIONE: Live chat e sessioni di domande/risposte ATTESTATI: sarà rilasciato attestato di partecipazione (no crediti formativi) MATERIALE: materiale didattico verrà fornito agli iscritti nei giorni precedenti l'evento. TUTOR: Arturo Tedeschi, Maurizio Degni
_
INFO ED ISCRIZIONE
…
to a rationalized integer format for use in the grasshopper definition . I don't want to convert the information permanently, but have been looking for an elegant method for converting the datetime string as needed so that it can interface within a grasshopper definition.
What I am trying to do is create a process for working with the timestamp included alongside sensor data I pull from Cosm. The data feed is formatted like this; <current_value at="2012-07-25T05:24:44.601988Z">77.68</current_value> and the Time paramater seems to easily understand the datetime string to read 2012-07-25T05:24:44.601988 as Wednesday, 25 July 2012 (05:24:44) so I plan on keeping the string as is when stored in a local mySQL database I have setup, but want to make sure I am not setting myself up for major headaches down the road.
I asked about converting the date time string to an integer to allow me to find time spans and generate a series of time stamps in an efficient way for creating a batch/ iterative process for requesting additional sets of data based on a query comparison of what gaps are left to fill in along a timeline of data points.
At the moment, I think a conversion to an integer is my best bet. (ref; Excel Date Time Code Id love to be able to feed in a date into a math component, add 08:00:00 and for it to result with a time 8 hours later than the first. I also have a string manipulation method working also, but have yet to really test it beyond what I have shown in the screenshot below.
I currently have these batches stream from Cosm.com into Grasshopper via a xml parser component (either the one found in Andy Payne's Firefly set, or the one included in gHowl.) From there I sort/ extract the data points and their respective time stamps and feed these data points into a mySQL database I've setup with Nathan Miller's Slingshot components. With the points in a local SQL database, I can then begin to integrate the use of database queries into definitions and retrieve data points based on sensor value Booleans rather than being restricted to time spans, (which is the only way to request historical data from Cosm's site)
I've been debating on if I should convert all the time information to an integer before writing it to the SQL database so GH can work with the data, or if I should keep the time code as a string and create a couple of conversation component clusters to translate the information each time it needs to be processed or manipulated in GH. I'd prefer to keep things in the date time string because the database can handle it without a problem, GH sort of handles it in one translation direction and allows me to avoid conversion that Id have to explain to others if they were to access the database in their own grasshopper definition or from another application.…
an run. GH2 still uses the Rhino SDK for the geometry functionality, so curve offsets, meshing, brep intersections etc. will run exactly as fast as they do now.
However even in the absence of a working version of GH2 which can be profiled, we can still discuss some of the major aspects of performance:
Preview display. Each GH solution involves a redraw of all the Rhino viewports at the end (unless is preview is switched off, which I imagine is exceedingly rare). For simple GH files, the viewport redraw takes far more time than the solution. Rhino6 has a completely rewritten display pipeline using more modern APIs so we should see a speed-up here in the future, be it GH1 or GH2 or GHx.
Canvas display. Each GH solution involves a redraw of the Grasshopper canvas. If the canvas shows a lot of bitmaps or intricate geometry (lots or text, dense graphs, etc.) this can take a significant amount of time. GH2 will use Eto instead of GDI+ as a UI platform. Eto can be both faster and slower than GDI, depending on what's being drawn. It is particularly fast when drawing images, not so much when drawing lots of lines. There is a little room for improvement here and I intend to take full advantage of that.
Preview meshing. Grasshopper uses standard Rhino mesher to generate preview meshes. If a GH file generates lots of breps, a large amount of time will be required to create the preview meshes. The new display improvements in Rhino6 will allow us to get away with previewing some types of geometry without the need to mesh them first, and I imagine some effort will be spend in the near future to improve the Rhino mesher as well.
Data casting. Most component code operates on standard framework and RhinoCommon types (bool, int, string, Point3d, Curve, Brep, ...), however Grasshopper stores and transfers data wrapped up in IGH_Goo derived types. This means that every time a component 'does it's thing', data needs to be converted from one type into another, and then back again. This involves type-checking and often type instantiation. This stuff is fast, but it's overhead nonetheless and can take significant amount of processor cycles when there's lots of data. GH2 no longer does this, it stores and transfers the types directly as they are. There will still be some overhead left, but hopefully a lot less.
Computation. GH1 is a single-threaded application. When a component operates on a large collection of data, each iteration waits for the next. GH2 will be parallel, meaning components will be invoked on multiple threads, each thread focusing only on part of the data. Then all the results need to be merged back into a single data tree. On my 8-core machine (4 physical cores, each with 2 logical cores) I've been getting performance speed-ups of 4~6 times when using my multi-threading code. I wish it was 8, but clearly there is some overhead involved here as well.This will not help to speed up a single very complicated solid boolean operation, but if you're offsetting 800 curves, then each thread can be assigned 100 curves and the time it takes will set by whatever thread takes the longest.
Algorithms. If a specific component is slow, there may be things we can do to speed it up. Either improve the Rhino SDK, or improve the GH code. Depends on the component in question.
When all's said and done, I'd love to see a 10x speed increase for GH2 over GH1 for simplish stuff, and I shall get very cross if it's anything less than 5x.…