of stuff. Then it works either with ExoW (black mesh) or IntraLattice (blue mesh).
That said ExoW is tricky: occasionally reports engulfing issues and stops playing the game. For instance in this (diagonal) anchor mode and with some U/V random values:
Whilst IntraLattice appears rather less temperamental:
The other def is more complex and works using the Proximity approach that makes more sense with regard random 3d line graphs (as an exercise: Add a gate and use IntraLattice as Plan B).
best
…
peuvent se diviser une surface avec ne importe quel motif imaginable. 3. Ici, je fournir un moyen de le faire via Lunchbox ... cela fonctionne mais il est fixe et donc nous avons besoin de jouer avec des arbres de données afin de créer le motif approprié par cas. 4. L'autre composante est un joint C # qui fait beaucoup de choses autres que de diviser ne importe quelle collection de points avec de nombreux modèles (voir le modèle ANDRE que je ai fait pour vous). 5. Vous devez décomposer une polysurface en morceaux afin de travailler sur les subdivisions. 6. Je donne une autre définition ainsi que pourrait agir comme un tutoriel sur la façon de traiter des ensembles de points via des composants de GH standards et des méthodes classiques.
Avertissez si tous ceux-ci apparaissent floue pour vous: Si oui, je pourrais écrire une définition utilisant des composants de GH classiques - mais vous perdrez les variations de motifs de division.
mieux, Peter
…
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…
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:
…
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 ?…
ting.
Thanks
Rania
** Warning ** IP: Note -- Some missing fields have been filled with defaults. See the audit output file for details.
** Warning ** Version: in IDF="'8.2.7'" not the same as expected="8.2"
** Warning ** ManageSizing: For a zone sizing run, there must be at least 1 Sizing:Zone input object. SimulationControl Zone Sizing option ignored.
** Warning ** ManageSizing: For a plant sizing run, there must be at least 1 Sizing:Plant object input. SimulationControl Plant Sizing option ignored.
************* Testing Individual Branch Integrity
************* All Branches passed integrity testing
************* Testing Individual Supply Air Path Integrity
************* All Supply Air Paths passed integrity testing
************* Testing Individual Return Air Path Integrity
************* All Return Air Paths passed integrity testing
************* No node connection errors were found.
************* Beginning Simulation
************* Simulation Error Summary *************
** Warning ** The following Report Variables were requested but not generated
** ~~~ ** because IDF did not contain these elements or misspelled variable name -- check .rdd file
************* Key=*, VarName=ZONE IDEAL LOADS SUPPLY AIR TOTAL COOLING ENERGY, Frequency=Hourly
************* Key=*, VarName=ZONE IDEAL LOADS SUPPLY AIR TOTAL HEATING ENERGY, Frequency=Hourly
************* Key=*, VarName=ZONE PACKAGED TERMINAL HEAT PUMP TOTAL COOLING ENERGY, Frequency=Hourly
************* Key=*, VarName=ZONE PACKAGED TERMINAL HEAT PUMP TOTAL HEATING ENERGY, Frequency=Hourly
************* Key=*, VarName=CHILLER ELECTRIC ENERGY, Frequency=Hourly
************* Key=*, VarName=BOILER HEATING ENERGY, Frequency=Hourly
************* Key=*, VarName=FAN ELECTRIC ENERGY, Frequency=Hourly
************* Key=*, VarName=ZONE IDEAL LOADS SUPPLY AIR LATENT HEATING ENERGY, Frequency=Hourly
************* Key=*, VarName=ZONE IDEAL LOADS SUPPLY AIR LATENT COOLING ENERGY, Frequency=Hourly
************* Key=*, VarName=ZONE IDEAL LOADS SUPPLY AIR SENSIBLE HEATING ENERGY, Frequency=Hourly
************* Key=*, VarName=ZONE IDEAL LOADS SUPPLY AIR SENSIBLE COOLING ENERGY, Frequency=Hourly
************* Key=*, VarName=SYSTEM NODE MASS FLOW RATE, Frequency=Hourly
************* Key=*, VarName=SYSTEM NODE TEMPERATURE, Frequency=Hourly
************* Key=*, VarName=SYSTEM NODE RELATIVE HUMIDITY, Frequency=Hourly
************* There are 3 unused schedules in input.
************* There are 5 unused week schedules in input.
************* There are 13 unused day schedules in input.
************* Use Output:Diagnostics,DisplayUnusedSchedules; to see them.
*************
************* ===== Recurring Surface Error Summary =====
************* The following surface error messages occurred.
*************
************* Base Surface does not surround subsurface errors occuring...
************* Check that the GlobalGeometryRules object is expressing the proper starting corner and direction [CounterClockwise/Clockwise]
*************
** Warning ** Base surface does not surround subsurface (CHKSBS), Overlap Status=No-Overlap
** ~~~ ** The base surround errors occurred 1 times.
** ~~~ ** Surface "839A5ADACCE44BC0AF00_GLZP_31" misses SubSurface "839A5ADACCE44BC0AF00_GLZP_31_GLZ_31"
** Warning ** Base surface does not surround subsurface (CHKSBS), Overlap Status=Partial-Overlap
** ~~~ ** The base surround errors occurred 1 times.
** ~~~ ** Surface "839A5ADACCE44BC0AF00_GLZP_34" overlaps SubSurface "839A5ADACCE44BC0AF00_GLZP_34_GLZ_34"
*************
** ~~~ ** The base surround errors occurred 2 times (total).
*************
************* EnergyPlus Warmup Error Summary. During Warmup: 0 Warning; 0 Severe Errors.
************* EnergyPlus Sizing Error Summary. During Sizing: 2 Warning; 0 Severe Errors.
************* EnergyPlus Completed Successfully-- 7 Warning; 0 Severe Errors; Elapsed Time=00hr 07min 35.94sec…
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…
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
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
…