mething? I think it would be very useful to have a mapping of light intensity over the field of view of the used camera, and possibly and option to overlay it on the luminance mapping. It would in a very visual way provide information about contrast and glare.
Doesn't the falsecolor option already do that for luminance mappings? If not can you post an image/screenshot of such a mapping from Dialux/AGI32 or any other software.
4. It's just a shoebox type simulation. 11x11 luminaires pointing down to simple materials. The default elapsed time was 3m40s. I have found the _RadParameters component meanwhile, and got it down to 0m30s. I have noticed that the simulation doesn't tax multiple cpu threads completely, most of the time cpu is at 25% during execution.
The under-utlization of CPUs is a known issue with Radiance (the calculation engine) on Windows based systems. Unfortunately there isn't much that can be done about it at the moment.
5. Is it possible to map different degrees of translucency, diffuse color, absorptance, reflectance, etc..., by means of a bitmap image, expression, or other?
6. There is a feature that I consider absolutely necessary (and I haven't found it yet), which is the emitting surface feature, with the ability to stipulate homogeneous intensity with luminance values (in cd/m^2) or flux; and by mapped distribution of intensities or luminances (in cd or cd/m^2).
By emitting surface I don't mean just a flat rectangular plane, such as an area light. It would be absolutely amazing! to perform photometric analysis on irregular and convoluted shapes and the light falling on neighbouring surfaces. 3DS Max with MentalRay provides similar functionality, but without the power of GH + HB.
In the image below, the HB logo is assigned as a texture to a glass which then creates a pattern of that on the wall when daylight falls on it.
ln the image below the light from the Batman logo illumninates the scene.
The images above were Rendered with Radiance. While these things are possible with Radiance, and therefore HB, the reason why they aren't incorporated into the code is that these effects are not "physically based" and are not rooted in reality. Radiance is arguably the most intensively tested and validated lighting simulation software in the world. However, once we start applying such "magic" to it, the results from it are no longer reliable and therefore no different from other photorealistic engines such as V-ray, Mental-Ray etc. …
of them. If they were already suggested and deemed impossible, i apologize.First, it would be really cool to have a right-click menu item for any geometry retaining module, that does the following: bakes the geometry, then disconnects all inherited data from the module, and assigns the baked version as locally defined. This is a one-time only thing, of course - it would be cool because if you have a "step-definition", that is, you have clear bottlenecks in your dataflow, and at some point you become satisfied with what you have so far, and only need to manually tweak some stuff to move on, you can discard the "already solved part of your definition. It's just a sort of "casting in stone" of partial results, that helps especially with simple work-defs or helper-defs. You could also call it something kickass like "manual override" or "emergency/hand b(r)ake".Second, if you have a component that outputs to a lot of others, and you want to change it with something else, you usually have to painstakingly reconnect all those wires, and if it doesn't work out, you do it right back or undo until you fingers bleed. Just as there is an extract parameter upstream for locally defined values, a downstream "extend parameter" with one rightclick menu item would make switching between various components easier.
Third, maybe a hot-key that you press and then click on a wire, which creates a "data" component at that point, splitting the wire and effectively allowing you to hijack it.
Lastly, maybe this is a stupid question, but what happened to the "clusters"? I mean i know they ended abruptly because of technical difficulties, but collapsing a group to a single component like that was totally awesome.Oh, and a minor bug repor from the v7.053 - it's not important, but mildly annoying: when you have an embedded graft, flatten, reparam or expression into a plug, the component extends to the left with the nifty little icons, and that looks very nice, but the wires still go in the old place, so at first glance i always think the wires are plugged in wrong. Is it possible to move the plug along with the component icon edge, or at least make those little indicators smaller, so that the error is minimized?
Thanks for your time,Hope i was pertinent
Andrei I.ps: the lolcat component is adorable, but i do believe that overall worldwide grasshopper productivity has dropped by various increments of those 20 sec it takes for it to refresh. Sadly accustomed with the feeling of guilt associated to watching around 50 lolpics refresh, I suggest that every 5 refreshes or so, you get a "stop looking at this and get back to work" message. It is at least a good way to derogate responsibility for tempting people to watch kitty-pics all day. :D…
stand completely (i just don't get the math part...).The code can be found here: http://digitalsubstance.wordpress.com/subcode/
So i decided to make my own definition: a cube deformed by 5 attractors and i was wondering if someone can help me solve the meshing at the end of the definition because when i bake it, it gives me an open mesh and i don't understand why ? Waterfall meshes are not suitable for 3d printing... I don't think i've used the clean, weld, and unify faces in the good order ? Maybe there is a problem with the surfaces ?
Secondly i'm not very proud of the result of my cube because it's so deformed that it is a not a cube anymore... so i was wondering if a square grid of points can be deformed by an attractor but still keeping the straight boundary of the grid ?
I had an idea to make that: i make my points, create the vectors between the grid and the attractor points, calculate the distance between the grid points and the attractors: it gives me a list of distances that i remap to control the strengh of my attractors. On the other side i calculate the distance between the boundary of the grid and the grid points and it gives me a second list of numbers. So i wanna average the two list of numbers in such a way that the closest it is to the attractor it takes the distance from the first list and the further it is from the attractor (so the closest it is from the boundary) it takes the distance from the second list ?? I'm sorry for my bad english but even in french it's little bit hard for me to explain it ;). So what can i do to have a grid attracted by a point without moving the boundary points ??
And please don't tell me to cull the boundary points first, to deform the grid and to rebuild the grid after... it gives an ugly cube face at the end, even with a lot of polishing with weaverbird...
If someone has another idea to achieve that please tell me ;)
The first definition "CleanCubeMeshingHelp"is a little bit heavy so watch out if you have a small laptop (any ideas to make it work faster are welcomed !!)
The second one is the one with the two list of numbers.
Also a last questions: what is and when to use the "blur number", "interpolate data" and Weighted Average" under math utilities ??
Thank you in advance for you answers and i apologize for my lack of vocubulary.…
. From the Thermal Comfort Indices component, Comfort Index 11 (TCI-11):MRT = f(Ta, Tground, Rprim, e)
with:- Ta = DryBulbTemperature coming from ImportEPW component- Tground = f(Ta, N) where N comes from totalSkyCover input. Tground influences the long-wave radiation emitted by the ground in the MRT calculation.- Rprim defined as solar radiation absorbed by nude man = f(Kglob, hS1, ac)- ac is the clothingAlbedo in % (bodyCharacteristics input)- I can't find any definition in the code of Kglob and hS1. Could you tell me please what are those values referencered to? --> probably the globalHorizontalRadiation but how?- e = vapour pressure calculated from Ta and Relative Humidity input
Do you agree that in this case the MRT does not depend on these inputs: location, meanRadiantTemperature, dewPointTemperature and wind speed?It does not depend neither on the other bodyCharacteristics like bodyPosture, age, sex, met, activityDuration...?
MRT calculated by the TCI-11 method is the mean radiant temperature of a vector pointing vertically with a sky view factor of 100%?For ParisOrly epw,
2. From the SolarAdjustedTemperature component (that seems to be more used for the UTCI calculation examples on Hydra compared to TCI-11).
In contrast to the TCI-11, this component distinguishes diffuse and direct radiation and contextualizes the calculation thanks to _ContextShading input, right? It can also be applied to a mannequin thanks to the CumSkyMatrix and thus evaluate the dishomogeneity of radiation exposure.This component seems not to consider the influence of vapour pressure on the result --> is it then more precise to put the MRT output (from the TCI) as an input of meanRadTemperature for SolarAdjustedTemperature?The default groundReflectivity is set to 0.25 --> is GroundReflectivity taken into account in the Tground or MRT calculation in the TCI component? If yes, what is the hypothesised groundReflectivity?The default clothing albedo of 37% (TCI-11 bodyCharacteristics) corresponds to Clothing Absorptivity of 63%?
If the CumSkyMatrix input is not supplied, I get 9 results for the mannequin --> where are those points/results coming from?
If the CumSkyMatrix input is supplied,I suppose the calculation of the 482 results correspond to a calculation method similar to the radiation analysis component that is averaged over the analysis period. Right?But I don't understand why the mannequin is composed of 481 faces and meshFaceResult gives 482 results.
Finally, what is the link between the MESH results, the solarAdjustedMRT and the Effective Radiant field ? Is there a paper to have a detailed explanation of the method?
3. Here are some results for the ParisOrly energyplus weather data. You can find here attached the grasshopper definition.There is no shading in this simulation and the result coming from the ThermalComfort indices for MRT is very different compared to the solar adjusted MRT.Why such a big difference and which of the result should be plugged into the UTCI calculation component?
Results for ParisOrly.epwM,D,H:1,1,12
Ta : 6.5°Crh: 100%globalHorizontalRadiation: 54 Wh/m2totalSkyCover: 10MRT (TCI-11): 1.2°C
_CumSkyMtxOrDirNormRad = directNormalRadiation : 0 Wh/m2diffuseHorizontalRad: 54 Wh/m2_meanRadTemp = TasolarAdjustedMRT: 10.64°CMRTDelta: 4.14°C
_CumSkyMtxOrDirNormRad = CumulativeSkyMtxdiffuseHorizontalRad: 54 Wh/m2_meanRadTemp = TasolarAdjustedMRT: 10.47°CMRTDelta: 3.97°C
_CumSkyMtxOrDirNormRad = CumulativeSkyMtxdiffuseHorizontalRad: 54 Wh/m2_meanRadTemp = MRT (TCI-11)solarAdjustedMRT: 5.17°CMRTDelta: 3.97°C
Thanks a lot for your helpRegards,
Aymeric
…
, Engineer and Researcher from France with broad programming experience. He is the author of the City in 3D Rhinoceros plugin for creation of buildings according to geojson file and with real elevation. Guillaume already created a new component: "Address to Location". It enables getting latitude and longitude values for the given address:
2) Support of Bathymetry data: automatic creation of underwater (sea/river/lake floor) terrain. This feature is now available through new source_ input of the "Terrain generator" component. Here is an example of terrain of the Loihi underwater volcano, of the coast of Hawaii:
3) A new terrain source has been added: ALOS World 3D 30m. ALOS is a Japanese global terrain data. Gismo "Terrain Generator" component has been using SRTM 30m terrain data, which hasn't been global and was limited to -56 to +60 latitude range. With this addition, it is possible to switch between SRTM and ALOS World 3D 30m models with the use of source_ input.
4) 9 new components have been added:
"Address To Location" - finds latitude and longitude coordinates for the given address.
"XY To Location" - finds latitude and longitude coordinates for the given Rhino XY coordinates. "Location To XY" - vice versa from the previous component: finds Rhino XY coordinates for the given latitude longitude coordinates. "Z To Elevation" - finds elevation for particular Rhino point. "Rhino text to number" - convert numeric text from Rhino to grasshopper number. "Rhino unit to meters" - convert Rhino units to meters. "Deconstruct location" - deconstructs .epw location. "New Component Example" - this component explains how to make a new Gismo component, in case you are interested to make one. We welcome new developers, even if you contribute a single component to Gismo! "Support Gismo" - gives some suggestions on how to make Gismo better, how to improve it and support it.
5) Ladybug "Terrain Generator" component now supports all units, not only Meters. So any Gismo example file which uses this component, can now use Rhino units other than Meters as well. Thank you Antonello Di Nunzio for making this happen!!
Basically just forget about this yellow panel:
This panel is not valid anymore, so just use any unit you want.
6) A number of bugs have been fixed, reported in topics for the last couple of weeks. We would like to thank members in the community who invested their time in testing, finding these bugs and reporting them: Rafat Ahmed, Peter Zatko, Mathieu Venot, Abraham Yezioro, Rafael Alonso. Thank you guys!!! Apologies if we forgot to mention someone.
The version 0.0.2 can be downloaded from here:
https://github.com/stgeorges/gismo/zipball/master
And example files from here:
https://github.com/stgeorges/gismo/tree/master/examples
Any new suggestions, testing and bug reports are welcome!!…
Added by djordje to Gismo at 5:13pm on March 1, 2017
ion of both Ladybug and Honeybee. Notable among the new components are 51 new Honeybee components for setting up and running energy simulations and 15 new Ladybug components for running detailed comfort analyses. We are also happy to announce the start of comprehensive tutorial series on how to use the components and the first one on getting started with Ladybug can be found here:
https://www.youtube.com/playlist?list=PLruLh1AdY-Sj_XGz3kzHUoWmpWDXNep1O
A second one on how to use the new Ladybug comfort components can be found here:
https://www.youtube.com/playlist?list=PLruLh1AdY-Sho45_D4BV1HKcIz7oVmZ8v
Here is a short list highlighting some of the capabilities of this current Honeybee release:
1) Run EnergyPlus and OpenStudio Simulations - A couple of components to export your HBZones into IDF or OSM files and run energy simulations right from the grasshopper window! Also included are several components for adjusting the parameters of the simulations and requesting a wide range of possible outputs.
2) Assign EnergyPlus Constructions - A set of components that allow you to assign constructions from the OpenStudio library to your Honeybee objects. This also includes components for searching through the OpenStudio construction/material library and components to create your own constructions and materials.
3) Assign EnergyPlus Schedules and Loads - A set of components for assigning schedules and Loads from the Openstudio library to your Honeybee zones. This includes the ability to auto-assign these based on your program or to tweak individual values. You can even create your own schedules from a stream of 8760 values with the new “Create CSV Schedule” component. Lastly, there is a component for converting any E+ schedule to 8760 values, which you can then visualize with the standard Ladybug components
4) Assign HVAC Systems - A set of components for assigning some basic ASHRAE HVAC systems that can be run with the Export to OpenStudio component. You can even adjust the parameters of these systems right in Grasshopper.
Note: The ASHRAE systems are only available for OpenStudio and can’t be used with Honeybee’s EnergyPlus component. Also, only ideal air, VAV and PTHP systems are currently available but more will be on their way soon!
5) Import And Visualize EnergyPlus Results - A set of components to import numerical EnergyPlus simulation results back into grasshopper such that they can be visualized with any of the standard Ladybug components (ie. the 3D chart or Psychrometric chart). Importers are made for zone-level results as well as surface results and surfaces results can be easily separated based on surface type. This also means that E+ results can be analyzed with the new Ladybug comfort calculator components and used in shade or natural ventilation studies. Lastly, there are a set of components for coloring zone/surface geometry with EnergyPlus results and for coloring the shades around zones with shade desirability.
6) Increased Radiance and Daysim Capabilities - Several updates have also been made to the existing Radiance and Daysim components including parallel Radiance Image-based analysis.
7) Visualize HBObject Attributes - A few components have been added to assist with setting up honeybee objects and ensuing the the correct properties have been assigned. These include components to separate surfaces based on boundary condition and components to label surfaces and zones with virtually any of their EnergyPlus or Radiance attributes.
8) WIP Grizzly Bear gbxml Exporter - Lastly, the release includes an WIP version of the Grizzly Bear gbXML exporter, which will continue to be developed over the next few months.
And here’s a list of the new Ladybug capabilities:
1) Comfort Models - Three comfort models that have been translated to python for your use in GH: PMV, Adaptive, and Outdoor (UTCI). Each of these models has a “Comfort Calculator” component for which you can input parameters like temperature and wind speed to get out comfort metrics. These can be used in conjunction with EPW data or EnergyPlus results to calculate comfort for every hour of the year.
2) Ladybug Psychrometric Chart - A new interactive psychrometric chart that was made possible thanks to the releasing of the Berkely Center for the Built Environment Comfort Tool Code (https://github.com/CenterForTheBuiltEnvironment/comfort-tool). The new psychrometric chart allows you to move the comfort polygon around based on PMV comfort metrics, plot EPW or EnergyPlus results on the psych chart, and see how many hours are made comfortable in each case. The component also allows you to plot polygons representing passive building strategies (like internal heat gain or evaporative cooling), which will adjust dynamically with the comfort polygon and are based on the strategies included in Climate Consultant.
3) Solar Adjusted MRT and Outdoor Shade Evaluator - A component has been added to allow you to account for shortwave solar radiation in comfort studies by adjusting Mean Radiant Temperature. This adjusted MRT can then be factored into outdoor comfort studies and used with an new Ladybug Comfort Shade Benefit Evaluator to design outdoor shades and awnings.
4) Wind Speed - Two new components for visualizing wind profile curves and calculating wind speed at particular heights. These allow users to translate EPW wind speed from the meteorological station to the terrain type and height above ground for their site. They will also help inform the CFD simulations that will be coming in later releases.
5) Sky Color Visualizer - A component has been added that allows you to visualize a clear sky for any hour of the year in order to get a sense of the sky qualities and understand light conditions in periods before or after sunset.
Ready to Start?
Here is what you will need to do:
Download Honeybee and Ladybug from the same link here. Make sure that you remove any old version of Ladybug and Honeybee if you have one, as mentioned on the Ladybug group page.
You will also need to install RADIANCE, DAYSIM and ENERGYPLUS on your system. We already sent a video about how to get RADIANCE and Daysim installed (link). You can download EnergyPlus 8.1 for Windows from the DOE website (http://apps1.eere.energy.gov/buildings/energyplus/?utm_source=EnergyPlus&utm_medium=redirect&utm_campaign=EnergyPlus%2Bredirect%2B1).
“EnergyPlus is a whole building energy simulation program that engineers, architects, and researchers use to model energy and water use in buildings.”
“OpenStudio is a cross-platform (Windows, Mac, and Linux) collection of software tools to support whole building energy modeling using EnergyPlus and advanced daylight analysis using Radiance.”
Make sure that you install ENERGYPLUS in a folder with no spaces in the file path (e.g. “C:\Program Files” has a space between “Program” and “Files”). A good option for each is C:\EnergyPlusV8-1-0, which is usually the default locations when you run the downloaded installer.
New Example Files!
We have put together a large number of new updated example files and you should use these to get yourself started. You can download them from the link on the group page.
New Developers:
Since the last release, we have had several new members join the Ladybug + Honeybee developer team:
Chien Si Harriman - Chien Si has contributed a large amount of code and new components in the OpenStudio workflow including components to add ASHRAE HVAC systems into your energy models and adjust their parameters. He is also the author of the Grizzly Bear gbxml exporter and will be continuing work on this in the following months.
Trygve Wastvedt - Trygve has contributed a core set of functions that were used to make the new Ladybug Colored Sky Visualizer and have also helped sync the Ladybug Sunpath to give sun positions for the current year of 2014
Abraham Yezioro - Abraham has contributed an awesome new bioclimatic chart for comfort analyses, which, despite its presence in the WIP tab, is nearly complete!
Djordje Spasic - Djordje has contributed a number of core functions that were used to make the new Ladybug Wind Speed Calculator and Wind Profile Visualizer components and will be assisting with workflows to process CFD results in the future. He also has some more outdoor comfort metrics in the works.
Andrew Heumann - Andrew contributed an endlessly useful list item selector, which can adjust based on the input list, and has multiple applications throughout Ladybug and Honeybee. One of the best is for selecting zone-level programs after selecting an overall building program.
Alex Jacobson - Alex also assisted with the coding of the wind speed components.
And, as always, a special thanks goes to all of our awesome users who tested the new components through their several iterations. Special thanks goes to Daniel, Michal, Francisco, and Agus for their continuous support. Thanks again for all the support, great suggestions and comments. We really cannot thank you enough.
Enjoy!,
Ladybug + Honeybee Development Team
PS: If you want to be updated about the news about Ladybug and Honeybee like Ladybug’s Facebook page (https://www.facebook.com/LadyBugforGrasshopper) or follow ladybug’s twitter account (@ladybug_tool).
…
u can still find some wonky behaviour in GH related to datatrees. My experience is that new users quite quickly get the hang of it once they learn that a tree is in fact not a tree but in the first place set of lists, where the path shows how the pieces of data used to be grouped.
Branch Count checking A component has multiple tree inputs, but has different amount of branches, each having branch count > 2. (While I understand the logic of combining multiple trees, I've not once encounted once that combining a component with e.g. an input of 2 branches and an input of 4 branches to give any kind of sensible output.
Desired behaviour: If a component has branches (each being > 2 path count), the component should throw a warning. ("Strict branches behaviour?). For example: take an offset component, with 6 branches of curves and 5 branches of offsets. It is extremely likely that this is the result of an error earlier in the definition. This works however without a problem - the last branch is repeated again, and it's later on quite hard to discover something went wrong.
Checking branch Count The most important numeric is the amount of branches, and the amount of items in the tree. It's desired that the hovers show the amount of data and the amount of branches.
Desired behaviour
Trees with paths of different rank Trees that contain {0;0} and {0} and {0;0;1} is usually a sign of trouble of not well merged trees, faulty C# components, or just nasty coding habits.
Trim as undo graft instead of flatten Having the trim in the context menu would provide an easy way to undo a graft. Right now the easiest way for many people is to flatten it, and then start all over again - while just getting rid of the last index keeps the underlying history and makes it easier to write reuseable pieces of code when you prepend datatrees to it.
Component to get branch by index, not by path Would be great. Suppose you have a grid of points, grouped by row. It would help to show: "look, this is in the first path, it's called {0;0;1}, it's got 10 points, these points are the first row".
Analogue to using list item to show what is the first point, second point, and so on.
Semantic path names (maybe far fetched) But what if we can add a short name of each method that was executed to the path list, so it can show:
{Slider 0; Series 0; Point 0}{Slider 0; Series 0; Point 1}
{Slider 0; Series 0; Point 2}
{Slider 0; Series 0; Point 3}
{Slider 0; Series 1; Point 0}
{Slider 0; Series 1; Point 1}
{Slider 0; Series 1; Point 2}
{Slider 0; Series 1; Point 3}
Make the input/data matching inside components explicit Can we make it even more obvious that a component is not a black box that's executed once, but in fact an iteration machine that tries to make sense of the inputs that's fed to this box?
Show data combination. How data input A relates to data input B and data input C, is currently very implict and is just plain hard to learn., and required the ability to be able to relate the output back to the input. If we can textually or even graphically show what data matching occured inside a component, it would greatly help the understanding (and debugging) of "what's going on here in this component"
A verbose explanation of the data matching in component A
Iteration one: - Geometry: We take the data item from Branch 0, Position 0: (Point 0,0,0) - Motion: We take the data item from Branch 0, Position 0: (Vector 0,0,0)
Iteration two:
- Geometry: We take the data item from Branch 0, Position 0: (Point 0,0,0)
- Motion: We take the data item from Branch 0, Position 1: (Vector 10,0,0)
Iteration three:
- Geometry: We take the data item from Branch 0, Position 0: (Point 0,0,0)
- Motion: We take the data item from Branch 0, Position 1: (Vector 20,0,0)
etc.
A verbose explanation of the data matching in component B
Iteration one: - Geometry: We take the data item from Branch 0, Position 0: (Point 0,0,0) - Motion: We take the data item from Branch 0, Position 0: (Vector 0,0,0)
..
Iteration seven:
- Geometry: We take the data item from Branch 0, Position 0: (Point 0,0,0)
- Motion: We take the data item from Branch 7, Position 0: (Vector 0,70,0)
..
Iteration 27:
- Geometry: We take the data item from Branch 0, Position 7: (Point 80,0,0)
- Motion: We take the data item from Branch 2, Position 0: (Vector 0,20,0)
…