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€…
h, and using the BScale and BDistance are creating havoc somehow too. I've simplified first, and used the Kangaroo Frames component along with setting internal iterations, to make MeshMachine act like a normal component, along with releasing the FixC and FixV. The FixV didn't make any sense anyway. I've also set Pull to 0 to speed it up during testing, since much less calculation is involved to just let the meshes collapse, prevented from disappearing altogether by using a mere 15 iterations.
Also, your breps are open so that allows much more chaos and then collapse, though they did manage to close themselves too at times. Here is closed breps with a full 45 iterations:
So now that it's working, lets re-Fix the curves, and the problem arises that there is an extra seam line that is getting fixed too, running along the cylinder, stopping the mesh from pulling tight under tension wherever a vertex happens to be near that line:
So lets grab only the naked edge curves instead:
And what happens if we lose the end caps, now that we don't have an extra line skewing the result?:
There is no real curvature differences since it's not a curvy brep so the Adapt at full 1 setting has little to do. Now what does the BScale and BDist do? Nothing! Why? Your scale is out of whack, 99 mm high cylinders but only a falloff maximum of about 5, so let's make the falloff be 25 instead, but I must restore the end caps or the meshes collapse away for some reason and freezes Rhino for a minute or so the first time I try it:
It's a start.
If I intersect the cylinders, nothing changes, since they are being treated as separate runs. MeshMachine outputs a sequence of two outputs though, due to Frames being set to a bare minimum of 2 needed to get it to work, so I filter out the original run, which is just the unmodified initial mesh it creates.
The lesson so far is that closed meshes are much less prone to collapse and glitches leading to screw ups.
A Boolean union of the cylinders is when it gets funner, here show with and without the fixed curves that seem to define boundaries too where really there are just polysurface edges:
…
ts in extreme aliasing effects that carry into the 3D realm as regular steps along what should be smooth surfaces.
On sleeping on it, I realized I hadn't yet tried fast Unary Force on fine quad meshes from the standard Grasshopper meshing system that includes the meshing options component.
Bingo! It's fast now. Workable. I don't need super fine meshing since I'm not running from aliasing. I can still use rather fine local meshes since Unary Force lets Kangaroo do a simple thing just in the Z direction rather than a full 3D force.
After only a minute or so of Kangaroo initialization that slows the interface, each of a dozen needed cycles takes half a second, FOR THE ENTIRE GRAPHIC.
I just set the timer to 1 second so I can move around the interface, and I double click the Windows taskbar timer shut-off to enjoy the result.
WHILE RUNNING VIA TIMER, IF I CHANGE A SPRING/FORCE SETTING IT SUFFERS NO DELAY AT ALL AND JUST ALTERS THE OUTPUT OVER TIME. I can change Unary Force from 20 to 100 and immediately see the bigger areas balloon like crazy:
It's fast enough overall to play with, yet the individual steps are slow enough that it's fun to watch the hysteresis as it overshoots back from 100 to 20 Unary Force, going concave in the middle of bulges then back to more shallow hills.
A force of 1000 is a bit disturbing, I wonder if I can tamp it down with greater spring strength or will that just give me the same result as before?
Looks like it's the same, just the ratio matters. Makes sense I guess. At one point it blew up though. Hitting the reset button...a minute later it blows up again...and just doesn't like huge numbers, so I don't see an advantage playing with bombs. The high mesh strength is pulling the mesh apart.
With low Unary Force and moderate mesh tension, you get flat tops, as if the overall force on the mesh fighting its anchored edge vertices, is enough to displace it, but the surface itself is too stiff to care about local gravity.
Then you have less flat areas as you increase Unary Force:
Weird, there *is* some sort of absolute effects, rather than just relative, between Unary Force and spring stiffness, since now I'm getting flat tops even in the extreme:
Oh, wait, strike that, I may be seeing but a single step with the timer off, subject to hysteresis. With the timer back on...it can sit there a minute...not locked up but just idling...until you see the Display > Widgets > Profiler time start cycling to near half minute numbers...makes you want to hit the reset button...and indeed that locks the interface for another initialization...and yes, it was merely hysteresis, not an equilibrium result. My former flat tops may have been due to that too, due to my use of the Windows taskbar timer disabler. The lesson is that you can obtain different results by using a long timer setting and just stopping it before it equilibrates.
This script is a keeper, fast and fun after the relatively mild Kangaroo initialization period is over.
The uniform mostly quad meshing is all done in Grasshopper too, from any flat surface with holes, especially from images of shapes that are traced with potrace to give surfaces with holes.
Could I switch to hex meshes from triangular meshes to do the same thing with fewer vertices?
Are there other forces I can add to smooth the bulging? Letting things bulge is not so bad if you then just scale down the result in Z afterwards (though perhaps the same result could be had with lesser force):
Also, can this same thing be done with possibly faster Kangaroo 2?…
Added by Nik Willmore at 10:02pm on February 21, 2016
mplex the models are. If we are running multi-room E+ studies, that will take far longer to calculate.
Rhino/Grasshopper = <1%
Generating Radiance .ill files = 88%
Processing .ill files into DA, etc. = ~2%
E+ = 10%
Parallelizing Grasshopper:
My first instinct is to avoid this problem by running GH on one computer only. Creating the batch files is very fast. The trick will be sending the radiance and E+ batch files to multiple computers. Perhaps a “round-robin” approach could send each iteration to another node on the network until all iterations are assigned. I have no idea how to do that but hope that it is something that can be executed within grasshopper, perhaps a custom code module. I think GH can set a directory for Radiance and E+ to save all final files to. We can set this to a local server location so all runs output to the same location. It will likely run slower than it would on the C:drive, but those losses are acceptable if we can get parallelization to work.
I’m concerned about post-processing of the Radiance/E+ runs. For starters, Honeybee calculates DA after it runs the .ill files. This doesn’t take very long, but it is a separate process that is not included in the original Radiance batch file. Any other data manipulation we intend to automatically run in GH will be left out of the batch file as well. Consolidating the results into a format that Design Explorer or Pollination can read also takes a bit of post-processing. So, it seems to me that we may want to split up the GH automation as follows:
Initiate
Parametrically generate geometry
Assign input values, material, etc.
Generate radiance/ E+ batch files for all iterations
Calculate
Calc separate runs of Radiance/E+ in parallel via network clusters. Each run will be a unique iteration.
Save all temp files to single server location on server
Post Processing
Run a GH script from a single computer. Translate .ill files or .idf files into custom metrics or graphics (DA, ASE, %shade down, net solar gain, etc.)
Collect final data in single location (excel document) to be read by Design Explorer or Pollination.
The above workflow avoids having to parallelize GH. The consequence is that we can’t parallelize any post-processing routines. This may be easier to implement in the short term, but long term we should try to parallelize everything.
Parallelizing EnergyPlus/Radiance:
I agree that the best way to enable large numbers of iterations is to set up multiple unique runs of radiance and E+ on separate computers. I don’t see the incentive to split individual runs between multiple processors because the modular nature of the iterative parametric models does this for us. Multiple unique runs will simplify the post-processing as well.
It seems that the advantages of optimizing matrix based calculations (3-5 phase methods) are most beneficial when iterations are run in series. Is it possible for multiple iterations running on different CPUs to reference the same matrices stored in a common location? Will that enable parallel computation to also benefit from reusing pre-calculated information?
Clustering computers and GPU based calculations:
Clustering unused computers seems like a natural next step for us. Our IT guru told me that we need come kind of software to make this happen, but that he didn’t know what that would be. Do you know what Penn State uses? You mentioned it is a text-only Linux based system. Can you please elaborate so I can explain to our IT department?
Accelerad is a very exciting development, especially for rpict and annual glare analysis. I’m concerned that the high quality GPU’s required might limit our ability to implement it on a large scale within our office. Does it still work well on standard GPU’s? The computer cluster method can tap into resources we already have, which is a big advantage. Our current workflow uses image-based calcs sparingly, because grid-based simulations gather the critical information much faster. The major exception is glare. Accelerad would enable luminance-based glare metrics, especially annual glare metrics, to be more feasible within fast-paced projects. All of that is a good thing.
So, both clusters and GPU-based calcs are great steps forward. Combining both methods would be amazing, especially if it is further optimized by the computational methods you are working on.
Moving forward, I think I need to explore if/how GH can send iterations across a cluster network of some kind and see what it will take to implement Accelerad. I assume some custom scripting will be necessary.…
16-20 / PUEBLA JULY 23-27
This workshop is intended primarily for architects and designers interested in learning parametric and generative design applied to the generation and rationalization of complex geometries for their implementation in different design processes. The course will cover basic concepts and methodology to address many design issues through the development of algorithmic tools via a visual programming language and the development of digital fabrication schemes. Rhinoceros 3D and Grasshopper are going to be used as our modeling tools and V-Ray as our rendering engine. Monday to Friday from 10am to 2pm and from 4pm to 8pm 40hrs.
No previous knowledge of Rhinoceros 3D or programming required, CAD background desirable.
Students: 4,000 MXN Professionals: 5,000 MXN Info: workshop@3dmetrica.com 044 55 28790084 www.3dmetrica.com
www.facebook.com/3dmetrica
TALLER DE VERANO ARQUITECTURA PARAMETRICA DISEÑO GENERATIVO RHINO + GRASSHOPPER + V-RAY
TOUR MÉXICO 2012
MEXICALI 25 AL 29 DE JUNIO / CIUDAD DE MÉXICO 2 AL 6 DE JULIO / MORELIA 9 AL 13 DE JULIO / GUADALAJARA 16 AL 20 DE JULIO / PUEBLA 23 AL 27 DE JULIO
Este taller está dirigido principalmente a arquitectos y diseñadores interesados en el aprendizaje del diseño paramétrico y generativo aplicados a la generación y racionalización de geometrías complejas para su implementación en diferentes procesos de diseño. En el curso se abordarán los conceptos básicos y metodología para hacer frente a diversas problemáticas del diseño mediante el desarrollo de herramientas algorítmicas a través de un lenguaje de programación visual y el desarrollo de esquemas de fabricación digital. Se utilizarán Rhinoceros 3D y Grasshopper como herramientas de modelado y V-Ray como motor de renderizado. Lunes a Viernes de 10am a 2pm y de 4pm a 8pm 40 hrs.
No se requieren conocimientos previos de Rhinoceros 3D ni de programación, conocimientos previos de CAD deseables.
Estudiantes: 4,000 MXN Profesionales: 5,000 MXN Info: workshop@3dmetrica.com 044 55 28790084 www.3dmetrica.com
www.facebook.com/3dmetrica
…
and 3d rapid prototyping using state of the art material simulation and optimisation. Participants will be guided through methods of advanced structural analysis and evolutionary algorithms implemented in Grasshopper, Karamba and Octopus in a 5 day workshop taught by Robert Vierlinger and Matthew Tam within the premises of the Academy of Fine Arts & Design in Bratislava, Slovakia. The workshop will cover the basics of setting up a karamba definition and more advanced form finding techniques with beams and shells through to preparing files for 3d printing and 2d documentation. For the Grasshopper newcomers there is a preparatory crash course on 20 July 2015 taught by Ján Pernecký. The workshop will be held entirely in English. VENUE Academy of Fine Arts and Design in Bratislava: VŠVU / AFAD, Hviezdoslavovo námestie 18, Bratislava, Slovakia ROOM 135 PRICING Early bird Student (until Jun 30, 2015) €320 Early bird Professional (until Jun 30, 2015) €380 Regular Student (from Jun 30, 2015) €400 Regular Professional (from Jun 30, 2015) €475 The fee covers only the tuition. Travel expenses, accommodation and food is to be covered by the participants. SCHEDULE Day 1 Lecture - Karamba in Projects from Competition to Construction Introduction to karamba - Setting up a basic karamba model Shells & Beams - Understanding the impact of load on geometries. Beams - Cross Section Optimization, Load Path Emergence Day 2 Extraction and Visualization of data from Karamba Complex Geometry - Processing of Free Forms for Karamba Force Flow - Understanding and Visualizing results on shells 3d Printing - Preparing geometries for rapid prototyping Day 3 Lecture - Form Finding in Karamba Isler Shells - Hanging Forms with karamba Shells - Shape Optimisation with Galapagos Trusses - Topology Optimization with Galapagos Columns - Positioning with Galapagos Multiobjective optimisation strategies with Octopus Day 4 Frequency Analysis & Non-Linear Analysis with Karamba Extraction and Visualization Part 2 BIS - Building Information Systems with karamba Day 5 Participant’s Examples and Topics Reviewing 3d Print Studies Large Complex Models Reviewing learn techniques and strategies Concluding lecture - public PARTNERS rese arch Academy of fine arts and design…
a nodi, permette di sfruttara le potenza della programmazione, senza necessariamente avere competenze avanzate.
Con Grasshopper potrete avere accesso ai segreti della modellazione generativa, un nuovo linguaggio progettuale che sta cambiando il mondo del design, a partire dalla gioielleria, fino ad arrivare all'architettura.
Durante il corso sarà possibile comprendere le caratteristiche di funzionamento del programma e applicarlo alla creazione di oggetti complessi che potranno essere stampati in 3D, oppure renderizzati. La durata è di 30 ore e alla fine del percorso verrà rilasciato il certificato McNeel.
Il Programma
Il corso spiega i concetti base di modellazione parametrica e generativa. Nello specifico:
Interfaccia e comandi
Parametri e componenti
Interopazione con Rhinoceros
Strumenti di parametrizzazione
Combinazione dati
Data tree
Creazioni di superfici attraverso algoritmi di paneling
Teoria degli attrattori
Gestione strumenti mesh
Creazione di Cluster
Durante il corso saranno proposte esercitazioni pratiche sul campo di utilizzo preferito dallo studente
Il docente
Antonino Marsala, è un formatore certificato McNeel con alle spalle oltre 11 anni di esperienza nel settore della modellazione 3D. Oltre ad occuparsi di formazione, collabora con aziende orafe e di architettura per la messa in pratica dei principi di modellazione generativa, applicandoli a casi reali.
FAQ
Quanto costa il corso?
Il prezzo del corso è di 500,00 € + IVA che potranno essere saldati in una soluzione unica. Nel caso di iscrizione di gruppo, potrà essere applicato uno sconto.
Cosa posso portare e cosa non devo portare all'evento?
Gli organizzatori forniranno computer con il software già installato. Nel caso vogliate portare il vostro computer, vi forniremo una versione trial da 90giorni di Rihnoceros e Grasshopper
Dove posso contattare l'organizzatore per qualsiasi domanda?
antonio@mandarinoblu.com
334 24 20 203
La mia registrazione o il mio biglietto è trasferibile?
Si, purchè venga comunicato il cambiamento entro 48 ore dalla partena del corso
…
ght on why this is, and some ideas I have for how to improve things going forward.
MeshMachine grew out of some scripts I started developing over 3 years ago (described here), originally just with the aim of achieving approximately equal edge lengths on a smooth closed triangulated mesh.
As time went on, I kept adding things, such as ways of keeping boundaries and sharp edges fixed, different ways of controlling edge lengths that vary across the surface, and different ways of pulling to surfaces.
I was also still experimenting with different rules for the core remeshing operations, such as valence driven vs angle driven edge flips.
All of these things meant many variables in the script. I wanted to share the work so others could play with it, but not really knowing exactly what people might use it for made it difficult to simplify the interface, so I just exposed most of these variables I was using (actually there were originally even more, but I felt a component with 20+ inputs was excessive, and combined some of them and fixed others to default values).
I've never been happy with that component, but some people want a component that you can just feed a surface and get a mesh with 'nice' triangles, without too much fuss or needing to know anything about how it works, while other people want to be able to vary the density based on proximity to the border, and curvature, and attractor points and see the intermediate results, and model minimal surfaces without pulling to any underlying surface, and...
Since then I did the rewrite from Kangaroo to Kangaroo2, and through that process, and associated conversations with Steve Baer, David Rutten and Will Pearson, my ideas about how to structure libraries and make cleaner more flexible Grasshopper components changed. Much of this centres around using interfaces (in the specific programming sense, not to be confused with UI), because they allow separating code into multiple components, while still allowing to edit parts of it within Grasshopper, and other parts in a proper IDE (because I find the GH code editor is not conducive to writing large amounts of well structured object oriented code).
Towards the end of last year, Dave Stasiuk and Anders Deleuran invited me and Will Pearson over to CITA for a few days of mesh and physics coding and beer drinking. During this time I made the first steps to restructuring MeshMachine to be more modular and interface based like Kangaroo2, instead of one giant script. One of the main motivations for doing this was to make it easier to combine the K2 physics library with the remeshing. However, at the time I hadn't yet released K2, so it didn't make sense to post examples that used those libraries. After the launch of K2, this restructured MeshMachine development has been a bit on the back-burner, but this discussion and Dave Stasiuk's work with Cocoon is inspiring me to pick it up again.
Seeing how you are combining the Cocoon and MeshMachine, and how Dave is also using interfaces in his recent work suggests to me it might be possible to integrate them more smoothly...
…
of the point cloud. It is super quick, compared to what you have seen so far in Rhino, to load and display point clouds, as it works on multiple threads. Amongst others you can section the point cloud for referencing your footbridge, decimate it as needed for creating the enviroment, denoise it, clip and save parts of point clouds etc. You can right click the cloud components, giving you access to dynamic preview of the cloud, so that it does not drag in viewport while panning and zooming and at the same time controlling the "thickness" of the points in viewport, in case your camera gets close to the point cloud. It is a matter of visual preference.
I think that even 200mil points can be loaded with volvox.
Some references
12million points
13million points
13million points (right click dynamic settings low thickness)
13million points (right click dynamic settings high thickness)
15 million points (around 20sec!! to l0ad)
My pc (i7 3820, 32gb ram, gtx670 4gb) felt comfortable working with up to 15 mil point clouds. But that has to do with hardware along with your patience while working.
All clouds have been loaded as .txt files where the mask describing the info was x,y,z,r,g,b,u,v,w. Depends on how your data is in-text formatted.
You can check fly through animations all done with gh and Volvox here
(starting @~2:20)
best
alex
…