o está dirigido a estudiantes de arquitectura y diseño de interiores, recién titulados y profesionales interesados en el software o que necesiten conocer las herramientas básicas de las que dispone el programa en los diferentes ámbitos y cómo enfocarlas a arquitectura.
Descripción:El contenido del curso enseñará a utilizar el programa de diseño Rhinoceros 3D aplicando su metodología de trabajo en el campo de la arquitectura, básandose además de la creación de pequeños elementos paramétricos para controlar el diseño y acabar renderizando las geometrías 3d con V-Ray para Rhino.
El curso consta de 3 módulos de 12h de duración cada uno (que pueden realizarse juntos o por separado) en los cuales se profundizará en herramientas de Rhino, Grasshopper y V-Ray a medida que se realizan casos prácticos sobre proyectos arquitectónicos.Se pretende establecer un sistema de trabajo eficiente desde el inicio del modelado hasta la posterior creación de imágenes para documentación del proyecto.
Módulo Rhinoceros Arquitectura:• Conceptos básicos e interfaz de usuario Rhino• Introducción al sistema cartesiano en Rhino• Clases de complejidad de geometría• Importación/exportación de archivos compatibles• Topología NURBS• Trabajo con Sólidos• Estrategias básicas de Superficies• Introducción a Superficies Avanzadas
Módulo Grasshopper:• Conceptos básicos e interfaz de usuario Grasshopper• Introducción a parámetros base y componentes• Matemáticas y trigonometría como herramientas de diseño• Matemáticas aplicadas a creación de Geometría• Introducción a listas simples• Análisis de Superficies y Curvas• Dominios de Superficies y Curvas• Panelado de superficies• Manejo de listas y componentes relacionados• Modificación de panelados en función de atractores• Exportación/Importación de información a Grasshopper
Módulo V-Ray para Rhinoceros:• Conceptos básicos e interfaz de usuario V-Ray• Vistas guardadas• Materiales V-Ray• Materiales, creación y edición• Iluminación (Global Illumination, Sunlight, Lights)• Cámara Física vs Cámara default• Canales de Render• Postprocesado básico de canales
Detalles:Instructores: Alba Armengol Gasull y Oriol Carrasco (SMD Arquitectes)Idioma: CastellanoHorario: 22 JULIO al 26 JULIO 2013 // 10.00 – 14.00 / 16.00 – 20.00Organizadores: SMDLugar: SMD lab, c/Lepant 242 Local 11, 08013 Barcelona (map)
Software:Rhinoceros 5Grasshopper 0.9.00.56V-Ray 1.5 for RhinoAdobe Photoshop CS5Links de versiones de evaluación de los Softwares serán facilitadas a todos los asistentes. Se usará unica y exclusivamente la versión de Rhino para PC. Se ruega a los participantes traer su propio ordenador portátil.
Registro:Modalidad de precio reducido por tres módulos 275€Posibilidad de realizar módulos por separado 99€…
e and Galapagos. There are two identical floors with 6 zones at the bottom floor and top floor separated by an adiabatic component in the middle. I have sliders affecting the thermal properties of the envelope, the WWR, and the shading depths.
I left my Galapagos running overnight and it ran out of RAM (have a 16GB RAM on Comp, Rhino was maxing out at 14.x GB).
At first I thought it was Galapagos causing this problem, but then I tried to manually adjust the sliders myself and found that each adjustment of slider would increase RAM, and very rarely it may decrease RAM. This was with the EPlus simulation component turned off, so I was basically just changing the parameters.
With about 17 changes in parameter sliders I was able to increase my RAM usage from 1.3GB to 4.6GB. This was with all previews off.
I tried the following:
UndoClear in Rhino - No effect
Solution -> Clear + Recompute - Adds to RAM usage
Is this something to do with Rhino? GH? HB? It seems that it is continuously remembering all previous states? Or would it have something to do with how I built the flow of GH (I'm quite new to it, so maybe it is something I am doing).
Greatly appreciate any help, would really want to be able to do some nice optimization runs. Thanks!…
ies a step further towards informative models, how to extract data through a parametric process and design analysis which leads to performance based schema.The workshop will cover some advanced modeling techniques in grasshopper along with some useful grasshopper plugins "GECO,WEAVERBIRD,KANGAROO and more". An introductory to ecotect analysis will also be inculded.The workshop is dedicated to intermediate Grasshopper users " knowledge of GRASSHOPPER equivalent to which gained in Parametricisim WS or higher is preferred".Knowledge of ECOTECT is a plus but not necessary".
Schedule :Deadline for Registration : May 13,2013Workshop Starts : Thursday, May 16, 2013 - 5:30 pmThe workshop consists of 10 lectures, Each lecture lasts for 3 hours.3 lectures per week (Sun, Tues & Thur) ---------------------------------------------------Fees : 600 L.EYou have to fill the Registration Form below for place reservation.We only have few places available. ---------------------------------------------------Prerequisite :-Students should bring their own laptops---------------------------------------------------Registration Form:https://docs.google.com/forms/d/1qd7cTRi8fGJ3OiVPjiNzHA0ZRmXI2qCvk1CUQ-X_4H8/viewformYou can view previous Parametric workshops,Student work & presnetation here :Previous workshophttps://www.facebook.com/events/469048376477647/https://www.facebook.com/media/set/?set=a.548388031851299.1073741826.470747186282051&type=1https://www.facebook.com/events/178326265647678/…
at sky type you choose. See images below.
A Tregenza sky discretizes the skydome into 145 patches to simplify the calculation process. This skydome approximates the smoother Perez sky shown below. Both the Tregenza 145-patch sky and the Perez sky use climate data to create realistic skies that react to hourly solar and weather data. So there may be some differences between the two runs. Also, every unique run will have some error based on how the calc process works and what your presets are.
Tregenza 145-patch sky-…
ipants from 12 countries to attend lectures and technical seminars furthering their understanding of digital design and fabrication in architecture. This year LaN extends the workshop with parallel intro sessions in all LAN ports–Barcelona / Boulder / Brooklyn / Bozeman (Aug 10-12). In 2009, you choose your modules.
Register Online
*please note, participants who have previously attended a LaN workshop automatically get a discount of total price.
Key Dates:
June 1, 2009: Workshop Launch - Applications Open @ 10% off price
June 19, 2009: Workshop Applications Open at 5% off
July 10, 2009: Applications open
August 7, 2009: Applications Closed
August 10-12, 2009: PHASE I - Modules [North America and Barcelona]
August 16-22, 2009: PHASE II - Modules [Barcelona @ IaaC / Institute for advanced architecture of Catalonia ]
August 24-30, 2009: PHASE III - Urban Drifts Workshop [Barcelona @ IaaC / Institute for advanced architecture of Catalonia]
*please note: all Rhino courses will be taught by a Rhino Certified Trainer
PHASE I: Aug 10-12
Phase I will be conducted in parallel in BARCELONA / BOULDER / BROOKLYN / BOZEMAN and are meant to familiarize participants with software and techniques. Phase I registration is inclusive of both module 1 & 2.
1. Rhino Introduction - 12hrs
2. RhinoFab: Rhino + Fabrication - 12hrs
PHASE II: Aug 17 - 22
Phase II modules will take place at the Institute for Advanced Architecture of Catalonia [IaaC] in Barcelona, Spain and will deal with scripting, parametric design and fabrication provided by FabLab BCN.
3. RhinoScript - 20hrs
4. Parametric Modelling in Rhino: Grasshopper - 20hrs
5. Introduction to Digital Fabrication - 20hrs
6. Machining Processes- 20hrs
PHASE III: Aug 24-30 ‘Urban Drifts’ Workshop - 40hrs
Register Online
Contact: bcn2@livearchitecture.net
More Information: http://www.livearchitecture.net…
learning environment, we will cover introductions to Algorithmic Design, Computational Geometry, and Parametric Modeling. Additionally, participants will explore concepts such as Object Attributes/Parameters, Part to Whole Relationships, and Data Flow. Emphasis will be placed on consistent organization of data through Lists and Data Trees and best practices for Creative Project Workflow Integration, File Modularity, and Data Visualization.
Framework:Lab participants will learn the Fundamental Concepts surrounding Parametric Design with Grasshopper for Rhinoceros and explore strategies for applying it within their Creative Process. Using the newly released version of Grasshopper 0.9, the Lab curriculum will track through a series of instructional presentations, open work sessions, and guided case-study exercises, which will include techniques for writing functions, simulating natural growth systems, defining object transformations, and constraint-based modeling. Participants from all creative fields and backgrounds are encouraged to attend and lend their perspective to the Lab. As part of a larger online infrastructure, modeLab, this workshop provides participants with continued support and knowledge to draw upon for future learning. This Lab will also serve as a hands-on Parametric Design Primer for Participants wishing to participate in the subsequent PATTERNING LAB.
More information can be found here: http://modelab.nu/?p=6941
We look forward to your participation!…
load path and what is a realistic and buildable structure vs one designed ad-hoc that looks cool.
No GH isn't geared to parametric constraint based modelling like CATIA. Then again, neither is CATIA a graphical algorithm. You are comparing apples with oranges.
Having used the CATIA API a lot, I understand the differences.
I disagree as regards the deployment of CATIA. It is very much still a "ivory tower" tool and the knowledge of its use in the AEC is very small and not shared widely. It will continue to do so until it becomes accessible to a wider audience much like rhino and GH. It has also stifled now for over 10 years, and with the release of V6, I don't see it ever catching up. The business model of rhino is better in that it encourages hobbyists to push the tool instead of waiting for a gargantuan software developer to make changes.
With constraint based parametric modelling and parametric modelling per se, the naming convention and ordering of data is key. I agree this is where more work is needed mote in GH.
Interesting job ad you shared, shows how little the person advertising understands parametric modelling. Understanding means nothing unless you have applied it.
To add, by work flow, what I implied is that we have an interoperable work flow to go form Excel to SAP to rhino to Tekla. All of that can potentially be set up on the canvas, on the fly, with the use of plug-ins. You cant do that with GC/CATIA or anything else. They don't provide a medium to define work flows.…
ocessed once Grasshopper is done with whatever it's doing now.
3) Grasshopper tells the Slider object that the mouse moved and the slider works out the new value as implied by the new cursor position.
4) The slider then expires itself and its dependencies ([VB Step 1] in this case, but there can be any number of dependent objects).
5) When [VB Step 1] is expired by the slider, it will in turn expire its dependencies (VB Step 2), and so on, recursively until all indirect dependencies of the slider have been expired.
6) When the expiration shockwave has subsided, runtime control is returned to the slider object, which tells the parent document that stuff has changed and that a new solution is much sought after.
7) The Document class then iterates over all its objects (they are stored in View order, not from left to right), solving each one in turn. (Assuming the object needs solving, but since in your example ALL objects will be expired by a slider change, I shall assume that here).
8) It's hard to tell which object will get triggered first. You'd have to superimpose them in order to see which one is visually the bottom-most object, but let's assume for purposes of completeness that it's the [VB Step 1] object which is solved first.
9) [VB Step 1] is triggered by the document, which causes it to collect all the input data.
10) The input parameter [x] is asked to collect all its data, which in turn will trigger the Slider to solve itself (it got expired in step 4 remember?). This is not a tricky operation, it merely copies the slider value into the slider data structure and shouts "DONE!".
11) [x] then collects the number, stores it into its own data structure and returns priority to the [VB Step 1] object.
12) [VB Step 1] now has sufficient data to get started, so it will trigger the script inside of it. When the script completes, the component is all ready and it will tell the parent document it can move on to the next object (the iteration loop from step 7).
13) Let us assume that the slider object is next on the list, but since it has already been solved (it was solved because [VB Step 1] needed the value) it can be skipped right away, which leaves us with the last object in the document which is still unsolved.
14) [VB Step 2] will be triggered by the document in very much the same way as [VB Step 1] was triggered in step 9. It will also start by collecting all input data.
15) Since all the input data for [VB Step 2] is either defined locally or provided by an object which has already been solved, this process is now swift and simple.
16) Upon collecting all data and running the user script, the component will surrender priority and the document becomes active again.
17) The document triggers a redraw of the Grasshopper Canvas and the Rhino viewports and then surrenders priority again and so on and so forth all the way up the hierarchy until Grasshopper becomes idle again.
[end boring]
Pretty involved for a small 3-component setup, but there you have it.
To answer somewhat more directly your questions:
- The order in which objects are solved is the same as the order in which they are drawn. This is only the case at present, this behaviour may change in the future.
- Adding a delay will not solve anything, since the execution of all components is serial, not parallel. Adding a delay simply means putting everything on hold for N milliseconds.
- [VB Step 1] MUST be solved prior to [VB Step 2] because otherwise there'd be no data to travel from [GO] to [Activate]. The only tricky part here is that sometimes [VB Step 1] will be solved as part of the process of [VB Step 2], while at other times it may be solved purely on its own merits. This should not make a difference to you as it does not affect the order in which your scripts are called.
--
The Man from Scene 24…
Added by David Rutten at 4:43pm on December 10, 2009
ess more memory on 64 bits. So you can load larger files and generate more data.
Every time you store something in memory it has to be stored at a specific location. We call this location an address. The first thing you store can be stored at address 0*. If that thing requires a total of 18 bytes, then addresses 0 through 17 are used up. The next thing you store can then be stored at address 18. And so on and so forth. At some point you run out of addresses and when that happens there is no more room to store any new data and there is thus nothing more that your app can do and that's usually when Windows shoots the application in the head and buries the remains behind the chemical sheds.
The total number of unique addresses that can be represented by a 32-bit integer is 4,294,967,295 (4 GigaByte). However Windows only allows a 32-bit app to access 2GB, or potentially 3GB if a special switch is set. A 64-bit application is allowed to use 64-bit integers to identify memory addresses, which means the highest possible address is now 18,446,744,073,709,551,616 (or 18.45 ExaBytes). Basically, as long as you have RAM to back you up, a 64-bit application will not run out of memory. Of course it may still become prohibitively slow as a lot of data requires a lot of computation and 64-bitness does absolutely nothing to make things go faster.
--
David Rutten
david@mcneel.com
Vienna, Austria
* Not true in reality, Windows will already use up some of the available memory just to load the application.…
Added by David Rutten at 1:39pm on November 2, 2012