ers can be applied from the right click Context Menu of either a component's input or output parameters. With the exception of <Principal> and <Degrees> they work exactly like their corresponding Grasshopper Component. When a I/O Modifier is applied to a parameter a visual Tag (icon) is displayed. If you hover over a Tag a tool tip will be displayed showing what it is and what it does.
The full list of these Tags:
1) Principal
An input with the Principal Icon is designated the principal input of a component for the purposes of path assignment.
For example:
2) Reverse
The Reverse I/O Modifier will reverse the order of a list (or lists in a multiple path structure)
3) Flatten
The Flatten I/O Modifier will reduce a multi-path tree down to a single list on the {0} path
4) Graft
The Graft I/O Modifier will create a new branch for each individual item in a list (or lists)
5) Simplify
The Simplify I/O Modifier will remove the overlap shared amongst all branches. [Note that a single branch does not share any overlap with anything else.]
6) Degrees
The Degrees Input Modifier indicates that the numbers received are actually measured in Degrees rather than Radians. Think of it more like a preference setting for each angle input on a Grasshopper Component that state you prefer to work in Degrees. There is no Output option as this is only available on Angle Inputs.
7) Expression
The Expression I/O Modifier allows you change the input value by evaluating an expression such as -x/2 which will have the input and make it negative. If you hover over the Tag a tool tip will be displayed with the expression. Since the release of GH version 0.9.0068 all I/O Expression Modifiers use "x" instead of the nickname of the parameter.
8) Reparameterize
The Reparameterize I/O Modifier will only work on lines, curves and surfaces forcing the domains of all geometry to the [0.0 to 1.0] range.
9) Invert
The Invert Input Modifier works in a similar way to a Not Gate in Boolean Logic negating the input. A good example of when to use this is on [Cull Pattern] where you wish to invert the logic to get the opposite results. There is no Output option as this is only available on Boolean Inputs.
…
ing the maps to the broader community.
At the moment, there are just a few known issues left that I have to fix for complex geometric cases but they should run smoothly for most energy models that you generate with Honeybee. Within the next month, I will be clearing up these last issues and, by the end of the month, there will be an updated youtube tutorial playlist on the comfort tools and how to use them.
In the meantime, there's an updated example file (http://hydrashare.github.io/hydra/viewer?owner=chriswmackey&fork=hydra_2&id=Indoor_Microclimate_Map) and I wanted to get you all excited with some images and animations coming out of the design part of my thesis. I also wanted to post some documentation of all of the previous research that has made these climate maps possible and give out some much deserved thanks. To begin, this image gives you a sense of how the thermal maps are made by integrating several streams of data for EnergyPlus:
(https://drive.google.com/file/d/0Bz2PwDvkjovJaTMtWDRHMExvLUk/view?usp=sharing)
To get you excited, this youtube playlist has a whole bunch of time-lapse thermal animations that a lot of you should enjoy:
https://www.youtube.com/playlist?list=PLruLh1AdY-Sj3ehUTSfKa1IHPSiuJU52A
To give a brief summary of what you are looking at in the playlist, there are two proposed designs for completely passive co-habitation spaces in New York and Los Angeles.
These diagrams explain the Los Angeles design:
(https://drive.google.com/file/d/0Bz2PwDvkjovJM0JkM0tLZ1kxUmc/view?usp=sharing)
And this video gives you and idea of how it thermally performs:
These diagrams explain the New York design:
(https://drive.google.com/file/d/0Bz2PwDvkjovJS1BZVVZiTWF4MXM/view?usp=sharing)
And this video shows you the thermal performance:
Now to credit all of the awesome people that have made the creation of these thermal maps possible:
1) As any HB user knows, the open source engines and libraries under the hood of HB are EnergyPlus and OpenStudio and the incredible thermal richness of these maps would not have been possible without these DoE teams creating such a robust modeler so a big credit is definitely due to them.
2) Many of the initial ideas for these thermal maps come from an MIT Masters thesis that was completed a few years ago by Amanda Webb called "cMap". Even though these cMaps were only taking into account surface temperature from E+, it was the viewing of her radiant temperature maps that initially touched-off the series of events that led to my thesis so a great credit is due to her. You can find her thesis here (http://dspace.mit.edu/handle/1721.1/72870).
3) Since the thesis of A. Webb, there were two key developments that made the high resolution of the current maps believable as a good approximation of the actual thermal environment of a building. The first is a PhD thesis by Alejandra Menchaca (also conducted here at MIT) that developed a computationally fast way of estimating sub-zone air temperature stratification. The method, which works simply by weighing the heat gain in a room against the incoming airflow was validated by many CFD simulations over the course of Alejandra's thesis. You can find here final thesis document here (http://dspace.mit.edu/handle/1721.1/74907).
4) The other main development since the A. Webb thesis that made the radiant map much more accurate is a fast means of estimating the radiant temperature increase felt by an occupant sitting in the sun. This method was developed by some awesome scientists at the UC Berkeley Center for the Built Environment (CBE) Including Tyler Hoyt, who has been particularly helpful to me by supporting the CBE's Github page. The original paper on this fast means of estimating the solar temperature delta can be found here (http://escholarship.org/uc/item/89m1h2dg) although they should have an official publication in a journal soon.
5) The ASHRAE comfort models under the hood of LB+HB all are derived from the javascript of the CBE comfort tool (http://smap.cbe.berkeley.edu/comforttool). A huge chunk of credit definitely goes to this group and I encourage any other researchers who are getting deep into comfort to check the code resources on their github page (https://github.com/CenterForTheBuiltEnvironment/comfort_tool).
6) And, last but not least, a huge share of credit is due to Mostapha and all members of the LB+HB community. It is because of resources and help that Mostapha initially gave me that I learned how to code in the first place and the knowledge of a community that would use the things that I developed was, by fa,r the biggest motivation throughout this thesis and all of my LB efforts.
Thank you all and stay awesome,
-Chris…
t defined from the discussion of radiation exchange between urban surfaces and the sky in urban heat island research (See Oke's literature list below). It will be affected by the proportion of sky visible from a given calculation point on a surface (vertical or horizontal) as a result of the obstruction of urban geometry, but it is not entirely associated with the solid angle subtended by the visible sky patch/patches.
So, I think using "geometry way" to approximate Sky View Factor is not correct. Sky View Factor calculation shall be based on the first principle defining the concept: radiation exchange between urban surface and sky hemisphere:
(image extracted from Johnson, G. T., & Watson, 1984)
Therefore, I always refer to the following "theoretical" Sky View Factors calculated at the centre of an infinitely long street canyon with different Height-to-width ratios in Oke's original paper (1981) as the ultimate benchmark to validate different methods to calculate SVF:
So, I agree with Compagnon (2004) on the method he used to calculate SVF: a simple radiation (or illuminance) simulation using a uniform sky.
The following images are the results of the workflow I built in the procedural modeling software Houdini (using its python library) according to this principle by calling Radiance to do the simulation and calculation, and the SVF values calculated for different canyon H/W ratios (shown at the bottom of each image) are very close to the values shown in Oke's paper.
H/W=0.25, SVF=0.895
H/W=1, SVF=0.447
H/W=2, SVF=0.246
It seems that the Sky View Factor calculated from the viewAnalysis component in Ladybug is not aligned with Oke's result for a given H/W ration: (GH file attached)
According to the definition shown in this component, I assume the value calculated is the percentage of visible sky which is a geometric calculation (shooting evenly distributed rays from sensor point to the sky and calculate the ratio of rays not blocked by urban geometry?), i.e solid angle subtended by visible sky patches, and it is not aligned with the original radiation exchange definition of Sky View Factor.
I'd suggest to call this geometrically calculated ratio of visible sky "Sky Exposure Factor" which is "true" to its definition and way of calculation (see the paper on Sky Exposure Factor below) so as to avoid confusion with "The Sky View Factor based on radiation exchange" as discussed in urban climate literature.
Appreciate your comments and advice!
References:
SVF: definition based on first principle
Oke, T. R. (1981). Canyon geometry and the nocturnal urban heat island: comparison of scale model and field observations. Journal of Climatology, 1(3), 237-254.
Oke, T. R. (1987). Boundary layer climates (2nd ed.). London ; New York: Methuen.
Johnson, G. T., & Watson, I. D. (1984). The Determination of View-Factors in Urban Canyons. Journal of American Meteorological Society, 23, 329-335.
Watson, I. D., & Johnson, G. T. (1987). Graphical estimation of sky view-factors in urban environments. INTERNATIONAL JOURNAL OF CLIMATOLOGY, 7(2), 193-197. doi: 10.1002/joc.3370070210
Papers on SVF calculation:
Brown, M. J., Grimmond, S., & Ratti, C. (2001). Comparison of Methodologies for Computing Sky View Factor in Urban Environments. Los Alamos, New Mexico, USA: Los Alamos National Laboratory.
SVF calculation based on first principle:
Compagnon, R. (2004). Solar and daylight availability in the urban fabric. Energy and Buildings, 36(4), 321-328.
paper on Sky Exposure Factor:
Zhang, J., Heng, C. K., Malone-Lee, L. C., Hii, D. J. C., Janssen, P., Leung, K. S., & Tan, B. K. (2012). Evaluating environmental implications of density: A comparative case study on the relationship between density, urban block typology and sky exposure. Automation in Construction, 22, 90-101. doi: 10.1016/j.autcon.2011.06.011
…
ni-corso introduttivo di Rhino e Grasshoper
Il corso non spiega una stampante 3D in particolare (quelle presenti sono state realizzate dai docenti) ma si rivolge a chiunque abbia la necessità di progettare un oggetto in 3D tra cui artigiani, studenti, ingegneri, progettisti spiegando pregi e difetti di tutte le stampanti.
Dalle 14.00 alle 16.00 Andrea Bruni e Valerio Monticelli di Studio MP affronteranno i temi:
1) Introduzione al mondo della stampa 3D
2) Il primo passo è creare un modello 3D - Introduzione pratica alla modellazione 3D con gli strumenti offerti dal software Rhinoceros
3) Preparazione e slicing attraverso Cura dei modelli per ottenere i risultati desiderati - ogni singola geometria è un mondo a sé. Non faremo qualcosa per te ma ti spiegheremo come farlo da solo.
Dalle 16.00 alle 18.00 Antonino Marsala di Mandarino Blu terrà un mini-workshop di introduzione aGrasshopper e la scomposizione di un pattern matematici secondo il processo di reverse engineering.
- Introduzione alla modellazione parametrica/generativa attraverso l'uso di Grasshopper- Il fiore della vita: significato simbolico e matematico- Scomposizione geometrica e analitica- Creazione del pattern attraverso la geometria generativa- Applicazioni pratiche
Biglietto 10,00 €
Biglietti disponibili al seguente link…
ally to describe a process of repeating objects in a self-similar way. Simply stated, the definition of a recursive function includes the function itself. Fractals are among the canonical examples of recursion in mathematics and programming. A loop can simply be a way to apply the same operation to a list of elements, but it is an iterative loop if the results from one step are used in the calculation of the next step. In design research controlling recursion becomes a new strategy to define new forms and spaces.
BRIEF
In this workshop we will be exploring iterative strategies through parametric design. Main tool for the course will be grasshopper3d and its add-on Anemone. Anemone is a simple but effective plug-in for Grasshopper that enables for loops in a simple and linear way. We will explore several strategies such iterative growth, L systems, fractals, recursive subdivisions and more. Our course will focus on how those methods can affect three-dimensional geometries, generating unexpected conformations.
TOPICS
intro to rhinointro to grasshopperadvanced grasshopperdata managementintro to loopscellular automatal-systemsagent based modelling
SCHEDULE
Day 1 / friday 16:00Tour Green Fab LabBasics of 3D modeling in RhinocerosBasics of GrasshopperOpen Lecture by Jan Pernecky, founder of rese arch
Day 2 / saturday 10 am- 18 pmRecursive iterative methodsAdvanced Topics of looping
Day 3 / sunday 10 am – 18 pmRecursive iterative methodsFinal presentation session
REQUIREMENTS
The workshop is open to all participants, no previous knowledge of Rhinoceros and Grasshopper is required (although an introductory knowledge is welcome). Participants should bring their own laptop with a pre-installed software. The software package needed has no additional cost for the participant (Rhino can be downloaded as evaluation version, Grasshopper and plugins are free). These softwares are subject to frequent updates, so a download link to the version used in the workshop will be sent to the participants a few days before the workshop.…
Added by Aldo Sollazzo at 11:10am on October 6, 2015
that, I have a few more comments on what you are trying to do:
1. It is not possible to divide the surface of a sphere with regular hexagons [the most efficient way includes pentagons as well (classic soccer ball)].
So I believe that in the image you posted there is some serious twisting taking place at the back side (you can actually see this starting on the right side of the picture).
Lunchbox's [hexagon cells] component divides the surface in U and V (orange slices for a sphere) and draws hexagons on it. The result is some serious deformation on the 2 poles and many non-planar cells. If you are ok with this, then my only tip would be to use an even number for the U divisions in order to have a clean seam:
instead of:
2. The hexagons you have defined in 2d are wrong as they are overlapping and also leaving gaps between them:
You should define your hexagons so that they form a honeycomb pattern. It could be something like this:
3. There is no direct way for hexagonal mapping, so your best bet would be to draw your pattern inside each cell (good GH data structure understanding is crucial for this). Also, the non-planar cells will probably give you a hard time there...
Hope I cleared some things and didn't cause more confusion!
Nikos
…
he process. The last one is there because fixing it would cause another problem, which we feel is more serious. Solutions may well be forthcoming in the future though.
1. Grasshopper curves and points are drawn more towards the camera than they really are. This is a conscious decision. Often Rhino geometry and Grasshopper geometry exist in the same place. If we would draw the Grasshopper preview in place, then there's no telling whether you'd see the Rhino curve or the Grasshopper curve. We feel it's important that you always see the Grasshopper curve on top. This is why we draw all curves and points slightly towards the camera. However we don't do this for meshes. This results in something akin to the image below. The eye represents the location of the viewport camera, the shaded box represents the actual location of the geometry and all the thick black lines represent the edges of the geometry moved towards the camera. As you can see, the red lines will be visible, even though they should be behind the shaded box. This effect can get very strong when the camera is close to some geometry relative to the size of the boundingbox of all geometry.
2. Wires behind the camera are sometimes visible. This is a bug I don't know how to solve. We'll get around to it eventually. When an object is behind the camera the display transform sometimes makes it visible in front of the camera in some weird inverted perspective mode.
3. Meshes are not z-sorted prior to display. This means that the order in which they are drawn is not back-to-front, but fairly arbitrary. This means that a transparent mesh may appear to punch a hole in the mesh behind it. If this is annoying you to no end, you can use Ctrl+F on the Grasshopper components that contain the meshes that are punching holes and then press F5 to recompute. The draw order should now be different. Of course sometimes it will only 'fix' it for a specific camera angle.
--
David Rutten
david@mcneel.com
Poprad, Slovakia…
that aren't relevant anymore or if there are any I missed please let me know. Maybe we can get a list like this in a better place as well.
Thank you.
Right Mouse - When wiring, plugs wire into multiple inputs.Shift+Click - Pick component aggregate.Shift+Clicking - Place component aggregate.Alt+Left - Click Split canvas tool.Ctrl+Q - Preview toggle.Ctrl+E - Enable toggle.Ctrl+Left - Navigate upstream.Ctrl+Right - Navigate downstream.Ctrl+M - Mesh Edge display toggle.Ctrl+1 - No previewCtrl+2 - Wireframe preview.Ctrl+3 - ShadedCtrl+Alt+Shift+Click - Save image of canvas.Ctrl+Alt and Shift+Ctrl+Alt - Highlights components on the canvas and component palette.Ctrl+Shift - Rewire component input/output.Double Click - Find/SearchAlt+Drag - Copy component on canvas.Ctrl+Tab - Document cycling.Ctrl+Shift+P - PreferencesCtrl+N - New fileCtrl+O - Open fileCtrl+S - Save file.Ctrl+Shift+S - Save as.Ctrl+Alt+S - Save backup.Ctrl+W - Close open document.Ctrl+Z - Undo copy.Ctrl+Y - RedoCtrl+X - CutCtrl+C - CopyCtrl+P - PasteCtrl+Alt+V - Paste in placeCtrl+Shift+V - Paste in centerCtrl+A - Select allCtrl+D - DeselectCtrl+Shift+I - Invert SelectionCtrl+Shift+A - Grow SelectionCtrl+Shift+Left Arrow - Grow UpstreamCtrl+Shift+Right Arrow - Grow DownstreamCtrl+Left Arrow - Shift upstreamCtrl+Right Arrow - Shift downstreamCtrl+G - Group selectionF3 - FindF4 - CreateF5 - RecomputeCtrl+B - Send to backCtrl+F - Bring to frontCtrl+Shift+B - Move backwardsCtrl+Shift+F - Move forwardsInsert - Bake selectedCtrl+Q - Toggle previewCtrl+E - Toggle enabled selected
…
thing about how to use Grasshopper to break up the unit modules as parameterization. Is there any Grasshopper Master could help me? The result i want is looks cool and easy to build.
Reference:
https://vimeo.com/98518748 Video link
http://www.designboom.com/architecture/robotically-fabricated-landesgartenschau-exhibition-hall-06-25-2014/
The question:
1,In the video,How to process parametric form?(kangaroo?)
2,After make all the things on the round surface, how to change the Tangency circle into flat polygon?
3, at last ,how to link every unit module?
…
faces (maked in RED, GREEB and BLUE) are shared by two zones. The small zones (in GRAY) attached to the big hall are not taken into consideration in the research.
In this case, inclined surfaces are included, as the simplification of the grandstand for spectators.
As the image shows, I have some questions:
1 - What should be the correct “surface type” of the inclined surfaces? floor?wall? or else?
(Actually, I have tried both floors and walls, but warnings shown below were received. The weird thing is that they had been assigned as floors and walls respectively having checked by the "decomposeByType" component.
2 - Can I ignore these warnings? if not, why and how can I deal with it - how to assign inclined surfaces as proper "type"?
3 - How can I get "interiorWalls"?
Although the small zones attached to the large hall are not considered in the research, I still need to assigned the shared walls as interior Walls (and set EPBC as "Adiabatic"), right? But, having checked by the "decomposeByType" component regrading walls, all I got were "walls" instead of "interiorWalls". Then, how can I get "interiorWalls" as I want?
Btw, due to the complexity of the geometry (e.g. containing inclined surfaces), I formed the thermal zone of the sports hall surface by surface using the "createHBSrfs" component as shown in above images. Do you think if it is a proper way in my case?
Any help will be much appreciated!
Ding
…