ity...? How to define this parameters and simulate them? How to simulate and evaluate form? How to work with Evolutionary Solver inside Grasshopper3d? How to evaluate end data and choose the fittest geometry? How to optimize geometry to increase overall energy efficiency of project!?
»»» Rhinoceros 5 + Grasshopper 3D & Sub-Plugins *required grasshopper plugins: Elk, LadyBug + Honeybee, Mesh edit (uto tools), Mesh+, Weaverbird, Human, TT Toolbox, Lunchbox, Horster tools, Exoskeleton & Cytoskeleton
>>>Please download and install Rhino + GH3D & Sub-Plugins before workshop start!<<<
with Igor Mitrić
DIGITAL FABRICATION BASICS - 3D SCANNING AND 3D PRINTING
Workshop would provide overview of current state of technologies for 3D scanning and 3D printing with those affordable and practical devices for research and development new design projects. Attendees would use 3D scanner to generate 3D model in virtual computer space, remodel, and prepare for 3D printer.
with Roberto Vdović
OPTIONAL FIELD TRIP - ON SITE ENERGY MEASUREMENTS (19.6.2015)
with Benedikt Borišič and Veronika Madritsch
Participants will receive CERTIFICATES of knowledge acquired at the workshop for each section. Participation is FREE! The number of places is LIMITED!
MORE INFORMATION AND APPLICATION WWW.LIVECONST.EU
WORKING SCRITPS
Day 1 City.gh
Day 2 Lady Bug.gh
Day 3 Galapagos
Record Galapagos.gh
Day 3_First Half.gh
Day 3 Second Half.gh
Tower from any Curve.gh
…
Illuminants like "A" or "D65" are spectral power distributions that are defined (as per CIE S 014-2/E:2006) for wavelengths ranging from 300nm to 830nm.
For example, CIE Illuminants A,B and C are defined as :
And D65 is defined as :
For illuminance and luminance calculations, the radiation from such illuminants are converted to Lux or Candela/sq.m by weighing them against the Photopic Luminous Efficiency function (also called as V-lambda):
The equation (1) used for this purpose is
Where y corresponds to the V-lambda function and J corresponds to an illuminant like "D65" or "A".
So, why is all this relevant? Honeybee/Radiance also use a similar method for calculation of luminous flux, illuminance and luminance. However, in the case of Honeybee/Radiance the lighting calculations are limited only 3 (R,G,B) channels (and not the 300nm to 830nm). So the equation (1) from above becomes something like:
F = 47.4*R+120*G+11.6*B
Where (R,G,B) refers to the spectral power of the radiation and the numbers (47.4,120,11.6) relate to the V-lambda function. So, the bottom line is that an accurate representation of CIE illuminants is not possible inside Radiance/Honeybee as the spectral information is severely restricted. Some studies have proposed using Radiance with more than 3 channels. For example: http://link.springer.com/article/10.3758%2FBRM.40.1.304 . However, such attempts have been limited. What is possible with Radiance/Honeybee is to create a fairly accurate representation of brightness of the sky. Although, I can explain that too, I would suggest that you try this link first: http://www.bozzograo.net/radiance/index.php?module=FAQ&func=dis...
By the way, which CIE document are you referring to for CIE sky definitions ?…
p others facing similar issues. 1) Letting Grasshopper perform the "implied" loop can be substantially slower than making the loop yourself inside the Python script. This is understandable, however the strangest thing is that it is MUCH slower if the definition has been saved than when it has not (by about a factor of 10)! 2) Setting type hints seems to be slower than inputting data with "No Type Hint". This depends a bit on which type is being input, but this seems to be fairly consistent. In the attached example by about a factor of 3. I suppose this is understandable, but not exactly ideal. 3) Outputtings lists with many items will often take longer than the actual computation performed by the script. I suppose this is more of a Grasshopper thing. My workaround has been to wrap the list in a Python list and pass this along as an item, which will be ALOT faster with large lists (this was crucial to both the Tower and ShapeOP where we pass around large amounts of constraints).
4) Calling certain RhinoCommon methods appear to be randomly much more expensive than using the C# scripting component. For instance, when iterating over a mesh's vertices and calling Mesh.Vertices.GetConnectedVertices() the elapsed time sum of these calls seem to be comprised of only a few vertices which randomly change every time the script is run. The amount of vertices differ on different machines, but the pattern remain consistent. I'm not sure if these bottlenecks are just examples of me being dumb, if so I hope you can enlighten me to the errors of my ways :) Attached some screenshots of an unsaved/saved definition which demonstrates the described issues. Also please find the gh definition attached. Best, Anders Edit: Logged this on Github here. Update: Added point 4), new screenshot and file demonstrating this behaviour.
System: Rhino Version 5 SR11 64-bit (5.11.50226.17195, 02/26/2015) Grasshopper 0.9.0073 GHPython 0.6.0.3 Laptop …
na cubierta o una estructura sigue en pie; presentar el router cnc en el evento depende del ejercicio práctico, para mayores informes no duden en escribir a luzyextura@gmail.com o a las oficinas de Bishon en Querétaro
_______________________________________________________
Workshop de arquitectura paramétrica mediante procesos digitales.
El temario incluye aspectos básicos y medios del modelado en Rhino, tanto de dibujo como de objetos en 3D, y las funciones de Grasshopper como una herramienta para el diseño paramétrico.
Al finalizar el curso, los asistentes serán capaces de manejar Rhinoceros y Grasshopper en un nivel medio, también comprenderán todas las herramientas básicas y el estilo de trabajo.
Además del contenido teórico se incluye un ejercicio práctico, que consiste en la producción de un modelo 3D, abarcando desde las ideas generadoras, el diseño, dibujo de piezas para su fabricación y construcción final.
El workshop tiene dos semanas de duración, con un horario de 8 am a 3 pm, el costo para estudiantes es de $4590, para la comunidad en general $4900. 35% descuento antes del 22 de julio
Informes bishion@mail.com, luzytextura@gmail.com.
Teléfono en Querétaro 4422 75 2863
Teléfono en la Ciudad de México 04455 4381 3302…
rawing speed here depends mainly on the speed of a single processor. Get a faster processor, increase the redraw speed.
2) Geometry operations. Such as Piping, Lofting, Curve CP etc. These are all performed by the Rhino core so there's little to be done here. We're continuously working on speeding things up, but they're already pretty fast (considering the complexity of the tasks). Rhino 5 has got a few bits and pieces of multi-threaded code and once we're convinced they're working well we'll probably apply those newly won skills to other parts of the core. These operations are also dependent mainly on processor speed.
3) Autosave operations. Since these involve writing data to the disk, it's very hard to predict whether or not it will be a fast or slow operation.
4) Viewport previews. This code is actually pretty horrible, it could be much faster than it currently is. However, a good Graphics card will make a lot of difference both now and in the future.
The ideal spec for Grasshopper is the same as it is for Rhino:
A) Get a good graphics card. We no longer shun ATI since their latest cards are actually pretty good, so either get a high-end NVidia or ATI card. Good gaming cards are not necessarily good CAD cards. Gaming cards are optimized for triangles and sprites, they don't do particularly well with curves.
B) Memory is dirt cheap, get as much as you can. 4GB being the absolute minimum. But, be sure to get fast-access memory, makes a lot of difference.
C) Get a fast processor. Since neither Rhino nor Grasshopper very much use multi-threading it is important that every single core is fast. I.e., don't get fooled by vendors who add the core speeds together and present that as the processor speed. One core running at 4 GHz is better than 8 cores running at a combined 16GHz.
As for OS, I'd recommend XP Pro or Windows 7. Stay away from Vista if you can. Also, almost all the software and hardware problems I come across at workshops are happening on MacOS machines running some flavour of Windows. Be it parallels, Bootcamp or VMWare.
--
David Rutten
david@mcneel.com
Poprad, Slovakia…
Added by David Rutten at 11:33am on December 15, 2009
essarily architectural. As you can guess from the tone of my previous response, I finished with school and had a hard time finding a job that focused on the technologies I delt with all through undergrad and grad. During grad school I was working with ASGvis (the makers of V-Ray) so I got exposed to the software side of things both on the support/management side and the development side. Now I'm off on my own doing development projects like RhinoHair, a few others, and some custom plugins for clients. Not necessarily what I thought I'd be doing after grad school, but I'm certainly enjoying it more than the "standard" practice of architecture.
I definitely understand "creating" a program. I did both my undergrad and grad at Catholic U here in DC, and although there was some ground work laid in regards to fabrication, I was one of only two or three students spearheading a lot of the scripting/GH/parametric stuff and some of the topics that go along with them (algorithmic design, adaptive systems, advanced geometry). One thing that was incredibly helpful for me was to pair up with the most advanced and forward thinking professor(s) that you can and take their studios, electives, and/or help out with their research. I was lucky enough to pair with a professor who had been at MIT and really encouraged me to explore my interests and sharpen my technicial skills.
It might also be a good idea to stick your head in some other departments, probably the math and engineering ones, or even biology and economics if there are some forward thinking professors. Talk to some people and get a different perspective on things. When I went to the ACADIA conference in 2008 it really opened my eyes to some of the potential influence from those different arenas.
Fabrication wise, I'd really try to focus more on milling (3 axis is fairly standard, 5 axis if you can get access) than 3d printing. Printing is a lot of fun, but ultimately we're not printing buildings (yet), so some of the milling processes will be much more valuble. If your school doesn't have those kind of facilities on campus (either in the Arch dept or engineering or something), then contact a local fabricator and see if you can work together somehow or someway. You'd be surprised and how many fabricators are interested in talking to architects.…
Added by Damien Alomar at 3:13pm on February 8, 2010
...hmm... points across the facade edges are not included (or may be some) and thus the whole thing is the art of pointless.
2. See the 1a unfinished part ... that defines internal boundaries for that purpose - then you need to create points across the edges, random reduce them and merging the list with the other points...blah blah.
3. That way each facade could yield structural members that touch the edges (where the biggest HEB/columns are expected to be). Obviously nodes are shared between facades with a common edge - the best logical approach for obvious real-life reasons.
4. The whole approach is stupid : here we need some Hoop snake "loop" control (that could take into account the critical connection angle constrain) in order to achieve a "progressive" deployment of the diagonal members in order to satisfy structural requirements and ... hmm...aesthetics. Free espresso for everyone is an added bonus.
5. Bottom to top design mentality is urgently required here: mastermind some 3d conceptual arrangement of nodes keeping in mind ... well...just 345,67 different real-life factors (but you could combine insulation and fireproofing if you use my favorite material: Foamglas - name with with one "s"). That way you can define the critical deployment planes : i.e. diagonal rigidity members, some facade aluminum system and floor main perimeter I-Beams MUST be in different planes.
I'll be back with a more stupid version of that thing.
may the Force ...blah blah
…
ncluded 3) using a freaky thing that "makes" Planes in order to do ramps (spot the Vodka option = Mobius + antigraviity OFF).
Don't touch the freaky things: for the moment just go and play with this palatable portion (GH components, nothing to fear he he):
depending on choice in gates: Paranoid (Mobius "shifted in Z")
sane (using corrected Planes):
not so sane:
What we have learned so far? Well ramps (and most of other things) ... it's about Planes (coordinate systems) you know.
Again: this is for fun/demo ONLY. I'll prepare a dedicated def for your case soon.
have fun, be brave
…
he past Architecture was the art of sketching: some "idea" with pencils/crayons + vellum paper (or with some computer) > then "others" trying to make this happen. This in general is known as top-to-bottom approach. Naive and dangerous (for the reputation/reception/acceptance of Architects/Architecture) to the max.
2. These days we work both ways: whilst some work on some "idea" (called it: "assembly") others (in sync mode) resolve the bits and nuts of that "idea" - up to 1:1 level of detail (called it "components"). This is the bottom-to-top approach. Make this your way: NEVER proceed in something whist's not EVERY bit of that something is well addressed (with at least 3-5 ways).
3. The emergence of parametric (GH, Generative Components, Dynamo) in AEC (an approach well known in MCAD word many years ago, mind) made things ... worst: the tremendous topology exploitation capabilities blinded people's mind and they are completely sucked up by the forest forgetting/by passing the critical fact that there's no forest without trees.
4. That's expected: is in the human nature to follow/admire the blink/glam and omit/skip the humble. It's the easy way you know, he he.
5. The tremendous growth of countries the likes of UAE/China/Russia made AEC things ... even worst: lot's of cash available > make us some encomium to Vanity, forget Modesty. You can replace "Vanity" with "New Frontiers" ... if you like fooling yourself.
Some Academics are not capable to understand all that: if they could they would potentially operate in the field (where the pink color is rarely used) and not in fishbowl(s). Some Academics believe that an "idea" is the 99% of the whole whilst actually is less than 1%. But on the other hand anyone can do Architecture (even Architects, he he).
That said (Vanity crisis) you want some other "component" options for this case of yours? (starting with "some" dollars more and ending with the mortgage the house/sell wife+kids option).
take care (and kill them all)…
something (C# or components) that does a planer periodic nurbs - any shape imaginable in fact (shown a humble "figure of 8").
2. Imagine a capability (C# only: sorry) to create a "guide" (indicative/intermediate) surface. Basically: patch the nurbs from step 1 against a variety of user controlled curves/points/cats/dogs/you name it.
3. Imagine doing this U/v quad mesh thingy (we can fill the "gaps" [C# only: sorry] with the base boundary easily - especially when triangulating the mesh - but better work as shown):
4. Imagine calling the cavalry (Kangaroo) and instructing to do ... things on that "normalized" mesh.
5. What things? Well ... like equalize edges, "inflate", planarize the quads (extra WOW stuff that one), pull it against the "guide" surface [from step 2] or some other weird ideas of mine.
this is what V2 does (WIP).
more soon
…