ere I'm using a GH_ObjectWrapper type. This may not be the best way about doing this, but it does work.
localSettings of type EM_Settings is the data that gets wrapped and then added to the Parameter.
Whilst everything works fine first time around, when I re-open the GH file the persistent data is lost. I need to serialize the data in some way in order to write it to a GH file and I'm not entirely sure how to do this.... I've tried for quite a while now, looking through the forum & SDK which offer clues but no joy... so I'm admitting defeat and running here!!!
Here are some of the CS bits:
public class MyComponent : GH_Component { ......... private EM_SettingsParam myParam;
private EM_Settings localSettings;
private EM_Settings mySettings;
protected override void RegisterInputParams(GH_Component.GH_InputParamManager pm) {
... myParam = new EM_SettingsParam(); EM_Settings localSettings = new EM_Settings(); myParam.PersistentData.Append(new GH_ObjectWrapper(localSettings)); pm.AddParameter(myParam, "Settings", "Se", "MySettings", GH_ParamAccess.item); }
protected override void SolveInstance(IGH_DataAccess DA) { GH_ObjectWrapper temp = new GH_ObjectWrapper(); if (!DA.GetData(5, ref temp)){ return; } mySettings = (EM_Settings)temp.Value;
...
} } public class EM_SettingsParam : GH_PersistentParam<GH_ObjectWrapper> { public EM_SettingsParam(): base(new GH_InstanceDescription("Settings", "Settings", "Represents a collection of Settings", "Params", "Primitive")) { } ...blah singular blah plural blah exposure.hidden blah... } public class EM_Settings { public bool Preview {get; set;} // (more parameters here) public EM_Settings() { Preview = true; }
}
Any help much appreciated $:)
John.…
URBS cup surface, and boy oh boy did it ever work more uniformly than using 3D orb cutters on a 3D cup. Different sized spheres return the *same* hex grid only less and less raised up as the spheres get very large.
My first question is whether these are different in character or just in Z scaling, so if I rescale them all to the same Z thickness, after extracting only the relief structure via Boolean union and splitting...and they are only *slightly* different in character, which means mere Z re-scaling of a single moderate ball size relief is an appropriate cheat to avoid slow Boolean union re-making each relief Z scale with different sized balls.
The one on the right is a very shallow relief scaled up to the same Z thickness as the pure sphere one on the left. And really, we will be mostly scaling *down* from a thicker master surface so that will attenuate any weirdness in the curvature. Indeed, I see no difference, so it makes sense to only archive the thickest one so we can control the full range of thicknesses, all the way to nearly flat bulbs. Here is the thickest one, just before the balls lose holes between them, scaled down compared to a shallow one made with huge balls to start with:
Now we just use Rhino Flow Along Surface or the Grasshopper Jackalope plug-in Sporf to morph this flat system onto our lathe form.
With Rhino history for the Flow Along Surface step I can rescale the original in Z and wait twenty seconds to see the update:
There are sad edge artifacts that will require some strategy to retain or later delete a whole row:
Maybe add more geometry to later delete or make a solid to hold stuff together?
So vastly decreasing the cell count and changing grid direction to match your cup:
The edges came out fine on this one, happily. The isocurve count has been increased by the Flow Along Surface command:
It can't be filleted yet since the joint where the cup NURBS surface has a joint now leaves feathery edges, so I went back and duplicated the border of the flat array, offset and lofted to make a protecting surface:
But that gave crazy artifacts:
I'm just going to use symmetry to fill in the joint with good faces that are not having to be joined as two halves. I had to turn my Rhino units tolerance down from a silly 0.0001 to 0.01 units to get a good re-join, but it still won't fillet without leaving holes.
SO LET'S FILLET THE FLAT THING. Same problem but a bit faster, and actually repairable manually. Rhino 5 is buggy as hell with core commands, damn it. This is not world class behavior.
Let's try it in Rhino 6 WIP, our great hope of the future: nope, the same. I had to simply manually copy the missing pieces from where it did work, which at least is easy to do in flatland. Now I get a cup:
This can *all* be done quickly in Rhino without Grasshopper, and Rhino affords you fast cage editing of the original flat array that Grasshopper cannot yet do. You just need to use Analyze Direction to be able to swap UV directions of the source or target and flip the source surface to achieve concave vs. convex patterns.
Grasshopper doesn't even have a fillet (multiple) edges component so there's not a lot of advantage to having some super slow parametric system via Grasshopper. It's not like you'll be able to see the changes fast enough to tweak a design.…
/www.grasshopper3d.com/forum/topics/vb-vs-c-vs-python
http://www.grasshopper3d.com/forum/topics/which-programming-language-should-i-focus-on-vb-or-python
VB.Net and C#
VB.Net and C# both belong to the ".Net" family of languages, and the things you can do with them in Rhino/Grasshopper are nearly 100% equivalent. Grasshopper itself was written in a combination of VB.Net and C#. Some advantages/comments, in no particular order:
Performance - VB.Net and C# scripts tend to execute faster because they are "Just-in-time" compiled as opposed to interpreted.
Autocomplete - both VB.Net and C# have rich autocomplete functionality in their respective script editor components - significantly more so than the python editor. This can be helpful for beginners since you can "hunt" for methods and properties by just typing a "." after an object name and looking at the list of available methods/properties.
Native Component development - If you eventually want to develop GHA assemblies/plug-ins for grasshopper, as of Rhino 5 you will have to use one of these two languages. However, there are plans to introduce python-based plugins in Rhino 6. Even so, the resources around plug-in development are very rich in the C# and VB.Net environments (with c# seeming to be the more popular of the two).
"Strong Typing" - VB.net to some degree, and C# especially, are less "forgiving" languages than python - they require you to know about the data type of the objects you're operating on. This can sometimes result in more verbose code - as you explicitly convert from type to type - but it also promotes good programming practice and helps make errors more understandable.
.Net ecosystem - using a .Net language means you have access to the thousands of libraries publicly available, and the process of referencing these libraries and making use of them is comparatively straightforward relative to python. More on this in the following section.
Resources/Support - At least as of 2012, VB and C# turned up more results on this forum than python, and I think you'll find slightly more expert-level coders in those languages able to help you here.
Which one between the two? C# or VB.Net? - Personally, I greatly prefer C# - I find it to be cleaner and clearer to use. I also have some programming background in C++/Java/Processing so I found the "C family" approach to be more familiar. As David and Damian point out in some of the posts linked above, C# is more popular than either python or VB.net in the rest of the coding world. However, if you are learning without any prior programming experience you may find VB.net to be a bit easier to learn.
Python
Python is, without a doubt, a beautiful and elegant language, which is probably more than can be said for VB.Net/C#. It is very popular with beginner coders, and its syntax is more readily understandable.
Syntax - Python is beautiful to read and write. Its syntax is very clear and free of extraneous punctuation (for example the ";" line endings in c#). It has many very nice language features that make common tasks more concise, like its loop syntax, list comprehensions, list "map" and "filter."
Multiple ways to talk to Rhino/Grasshopper - Python enables two general approaches to interacting with the Rhino/Grasshopper environment: RhinoCommon and RhinoScriptSyntax. If you have prior experience with Rhinoscript, you may find RhinoScriptSyntax to be preferable - it adapts many of the methods you're familiar with to the python language, and simplifies some tasks. A word of caution though - working with Rhinoscriptsyntax can introduce a performance hit relative to RhinoCommon operations. C# and VB.net by contrast can only work with RhinoCommon.
"Goodies" - The Python environment in Grasshopper has some "special features" that the other languages lack. In particular, the "GHPythonLib" library enables the ability to call most Grasshopper components from within your code, and the ability to easily enable parallel processing to improve performance. (A word of caution though - these two features do not seem to "play well" with each other, there may be bugs causing memory leaks that result in increasingly worse performance with each execution).
Cross-Platform - Unlike C#/VB.net, Python can be used natively in Rhino for Windows and Rhino for Mac.
Direct scripting in Rhino - You can also use Python directly in the Rhino environment without the need for Grasshopper if you desire, using the Rhino Python editor.
IronPython / Ecosystem issues - one frustration / potential downside to working with Python for Rhino/GH is that though there is a vast, amazing ecosystem of external libraries for Python, getting these to install/work properly in the Rhino/GH environment can be a real pain - largely because the language is actually "IronPython," a version of python designed to work closely with the .Net ecosystem. Many popular libraries like numpy and scipy are very challenging to get working in Rhino/GH.
Scripting in other programs - Especially in the AEC industry, Python is a popular scripting language for other applications. Tools like Revit, Dynamo, Blender, and ArcGIS all offer their own Python scripting interface - so learning Python in Rhino/GH can give you a leg up in eventually scripting in these other programs.
Python's Stock is Rising - there are currently a number of efforts to improve the "status" of python within the Rhino/GH ecosystem. The python editor in Rhino 6 has a number of improvements, not least of which is the ability to "compile" add-ons for Grasshopper written in python. I'm sure Giulio can speak to other upcoming improvements.
I hope this summary helps you find the right option for you. Ultimately you can't go wrong; concepts from any of the available scripting languages will make it much easier to learn the next one. In my day to day work I use a combination of both C# and python, where appropriate, and I love them both.
I hope others will feel welcome to chime in on this FAQ and add their own thoughts about advantages/disadvantages of these various options! If you have time, read through some of the other posts linked to at the beginning - there's lots of additional great information there. …
ou will see a list of potential matches, sorted from most relevant to least relevant:
Some components and objects support initialisation codes, which means you can assign certain values directly from the popup box. You can do this by adding an equals symbol after the name and then the value you wish to assign. For example, the [Curve Offset] component allows you to specify the offset distance via the popup box by typing =5 after the offset command:
However the popup box also supports a set of special formats that allow you to create specific objects without even typing their names. As of 0.9.0077 (which hasn't been released yet at the time of writing) you can use the following shortcuts to create special objects. In the notation below optional parts of a format will be surrounded by square brackets and hashes (#) will be used to indicate numeric values. So #,#[,#] means;
at least two numeric values separated by a comma, with an optional second comma and third number.
A complete list of special formats (not all of these are supported yet in 0.9.0076):
"∙∙∙ If the format starts with a double quote, then the entire contents (minus any other double quotes) will be placed into a Text Panel.
//∙∙∙ If the format starts with two forward slashes, then the entire contents will be placed in a Text Panel.
~∙∙∙ If the format starts with a tilde, then the entire contents will be placed in a Scribble object.
#,#[,#] If the format contains two or three numerics separated by commas, a Point parameter will be created with the specified coordinates.
+[#] If the format starts with a plus symbol followed by a numeric, then an Addition component will be created.
-[#] If the format starts with a minus symbol followed by a numeric, then a Subtraction component will be created.
*[#] If the format starts with an asterisk symbol followed by a numeric, then a Multiplication component will be created.
/[#] If the format starts with a forward slash symbol followed by a numeric, then a Division component will be created.
\[#] If the format starts with a backward slash symbol followed by a numeric, then an Integer Division component will be created.
%[#] If the format starts with a percent symbol followed by a numeric, then a Modulus component will be created.
&[∙∙∙] If the format starts with an ampersand symbol, then a Concatenation component will be created.
=[∙∙∙] If the format starts with an equals symbol, then an Equality component will be created.
<[*] If the format starts with a smaller than symbol, then a Smaller Than component will be created.
>[*] If the format starts with a larger than symbol, then a Larger Than component will be created.
[# *] Pi If the format contains the text "Pi" with an optional multiplication factor, then a Pi component will be created.
# If the format can be evaluated as a single numeric value, then a Slider will be created with the specified initial value and sensible™ lower and upper limits.
#<# If the format contains two numerics separated by a smaller than symbol, a Slider with the specified limits will be created. The initial slider value will be equal to the lower limit.
#<#<# If the format contains three numerics separated by a smaller than symbol, a Slider with the specified limits will be created. The initial slider value will be the value in the middle.
#..# If the format contains two numerics separated by two or more consecutive dots, a Slider with the specified limits will be created. The initial slider value will be equal to the lower limit.
#..#..# If the format contains three numerics separated by two or more consecutive dots, a Slider with the specified limits will be created. The initial slider value will be the value in the middle.
#/#/[#] If the format contains two or three numerics separated by forward slashes, a Calendar object will be created. The order of value is day/month/year. If year is omitted then the current year is used. Note that a second slash is required because #/# is interpreted as a number and thus results in a Slider.
#:#[:#] [am/pm] If the format contains at least two numerics separated by a colon, a Clock object is created. Seconds are optional, as are am/pm suffixes.
f([...[,...[,...]]]) [= *]If the format starts with a lower case f followed by an opening bracket, an Expression component is created. A list of comma separated arguments can be provided as inputs, and anything after the optional equals symbol becomes the expression string.
Note that decimal places will be harvested from formats that indicate sliders. I.e. the format 0..2..10 is not the same as 0..2..10.00, as the former will create an integer slider from zero to ten whereas the latter will create a floating point slider with two decimal places from zero to ten.…
Added by David Rutten at 3:24pm on February 18, 2013
ager As Grasshopper.Kernel.GH_Component.GH_InputParamManager)
pManager.AddTextParameter(
"Name", "N", "String", GH_ParamAccess.item)
pManager.AddPointParameter(
"Point", "P", "Point3d", GH_ParamAccess.item)
pManager.AddGenericParameter(
"Local Axis", "LA", "Null/Surface/Plane", GH_ParamAccess.item)
pManager.AddGenericParameter(
"Support", "S", "I_Model_Support", GH_ParamAccess.item)
pManager.AddGenericParameter(
"PointLoad", "PL", "List (of I_Model_PointLoad)", GH_ParamAccess.list)
pManager.AddGenericParameter(
"Group", "G", "List (of (I_Model_Group)", GH_ParamAccess.list)
End Sub
Protected Overrides Sub RegisterOutputParams(ByVal pManager As Grasshopper.Kernel.GH_Component.GH_OutputParamManager)
pManager.AddGenericParameter(
"Node", "N", "I_Model_Node",GH_ParamAccess.item)
End Sub
Protected Overrides Sub SolveInstance(ByVal DA As Grasshopper.Kernel.IGH_DataAccess)
Dim inName As String = Nothing
Dim inP As Point3d = Nothing
Dim inLA As Plane = Nothing
Dim inS As I_Model.I_Model_NodeSupport = Nothing
Dim inPL As New List(Of I_Model.I_Model_PointLoad)
Dim inG As New List(Of I_Model.I_Model_Group)
Dim outNode As I_Model.I_Model_Node
If Not DA.GetData(0, inName) Then Return
If Not DA.GetData(1, inP) Then Return
If Not DA.GetData(2, inLA) Then Return
If Not DA.GetData(3, inS) Then Return
If Not DA.GetData(4, inPL) Then Return
If Not DA.GetData(5, inG) Then Return
Dim IM_P As I_Model_Node
IM_P =
New I_Model_Node(inP, Nothing, inName)
If Not DA.GetData(2, inLA) Then IM_P.SetLocalAxis(inLA)
If Not DA.GetData(3, inS) Then IM_P.SetSupport(inS)
If Not DA.GetData(4, inPL) Then
Dim PL As I_Model_PointLoad
For Each PL In inPL
IM_P.AddPointLoad(PL)
Next
End If
If Not DA.GetData(5, inG) Then
Dim G As I_Model_Group
For Each G In inG
IM_P.AddToGroup(G)
Next
End If
outNode = IM_P
DA.SetData(0, outNode)
End Sub
…
Added by Daniel Bosia at 9:22am on January 11, 2013
n-
{"An error occurred creating the form. See Exception.InnerException for details. The error is: Could not load file or assembly 'RhinoCommon, Version=5.0.15005.0, Culture=neutral, PublicKeyToken=552281e97c755530' or one of its dependencies. The system cannot find the file specified."}
-Warning 1 Possible problem detected while building assembly 'Random_Points': Referenced assembly 'Rhino_DotNet.dll' targets a different processor Random_Points
Code:
Option Strict Off
Option Explicit On
Imports Rhino
Imports Rhino.Geometry
Imports Rhino.Collections
Imports System
Imports System.IO
Imports System.Xml
Imports System.Data
Imports System.Drawing
Imports System.Reflection
Imports System.Collections
Imports System.Windows.Forms
Imports Microsoft.VisualBasic
Imports System.Collections.Generic
Imports System.Runtime.InteropServices
Public Class Form1
#Region "members"
Private doc As RhinoDoc = RhinoDoc.ActiveDoc
#End Region
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
Dim aPt As New List(Of Point3d)
Dim oPt As New Point3d(Rnd, Rnd, Rnd)
aPt.Add(oPt)
End Sub
End Class
I'm a bit confused. Perhaps I'm missing something to enable rhino as the active document. I'm gunna keep digging around on github and mcneal and feedback greatly appreciated.
-shamefull madu
…
This blog post is a rough approximation of the lecture I gave at the AAG10 conference in Vienna on September 21st 2010. Naturally it will be quite a different experience as the medium is quite…
Added by David Rutten at 3:27pm on September 24, 2010
tal at food4Rhino:
http://www.food4rhino.com/project/ladybug-Honeybee?ufh
Before addressing the changes in the software itself, we would like to announce the start of two new resources that have been added to help everyone learn and share knowledge across our community.
NEW RESOURCES
GH Example File Sharing - After recognizing how important example files are for sharing knowledge and capabilities in our community, we have initiated a github-based platform for sharing Grasshopper definitions called Hydra:https://hydrashare.github.io/hydra/index.htmlWhile the database of files is a little over 50 files at the moment, it is hoped that this will become THE forum where much of collective knowledge is exchanged and shared into the future. As you can see by clicking on any of the examples, you now are able to get a high-res visual of both the Rhino scene and the GH canvas without having to download files to your machine. Furthermore the search functionality through the database enables you to quickly and easily see all that our community has contributed on certain subjects (just by searching “shade” or “wind” for example).In addition to other files that have been contributed, you can find all of the original Ladybug examples here:https://hydrashare.github.io/hydra/index.html?keywords=LBExampleFilesAnd all of the original Honeybee examples here:https://hydrashare.github.io/hydra/index.html?keywords=HBExampleFiles
LB+HB Documentation - While our historical practice of including all documentation within component descriptions may have sufficed up until this point, we have since recognized that an online database of all this documentation would be helpful. Now, you can search for key terms throughout the entire documentation of the project in our beautiful online documentation database created by Mostapha:https://www.gitbook.com/book/mostapharoudsari/ladybug-primer/detailshttps://www.gitbook.com/book/mostapharoudsari/honeybee-primer/details
And now, onto the major changes and enhancements in the software:
LADYBUG
Photovoltaics Components - Based on original code from NREL’s PVWatts (http://pvwatts.nrel.gov), Djordje Spasic and Jason Sensibaugh have built a set of 5 components that perform detailed estimate of the electricity generated by Rhino/Grasshopper surfaces when populated with Photovoltaics (PV) modules.Components allow definition of losses and shading, finding optimal tilt and orientation angles, analysing performance, energy value, consumption and emissions of the PV system.
Enhanced Solar Envelope - Boris Plotnikov has contributed a solar envelope component that is not only much faster and more stable than the previous component but also allows you to input the geometries of buildings for which you would like to ensure solar access. This enables customization of the solar envelope to specific urban contexts in a manner that the previous envelope did not. The component also features a “solar access” option that draws the envelope above which a given site receives sun from a set of sun vectors. An example file can be found here:http://hydrashare.github.io/hydra/viewer?owner=boris-p&fork=hydra&id=SolarEnvelope
Adaptive Comfort Chart - To assist with understanding the variations of the adaptive comfort model, an Adaptive Comfort Chart component has been added that functions in a similar manner to the psychrometric chart for the PMV model. In addition to granting a visualization of the adaptive standard itself, the chart is also particularly helpful for displaying the results of energy simulations in relation to the comfort polygon. The chart is based off of the UC Berkeley Center for the Built Environment’s Comfort Tool (http://comfort.cbe.berkeley.edu/) (https://github.com/CenterForTheBuiltEnvironment/comfort_tool). An example file can be found here:http://hydrashare.github.io/hydra/viewer?owner=chriswmackey&fork=hydra_2&id=Adaptive_Comfort_Chart
Full Support for US + European Thermal Comfort Standards - Ladybug now supports the ability to model any of the variations of the Adaptive/PMV models for both the US (ASHRAE) and European (ISO) standards. This includes varying thresholds of percentage of people dissatisfied (PPD), varying thresholds for humidity ratios, the ability to use either a monthly average or daily running mean temperatures in the adaptive model, and even some functions that are not yet a part of these standards but are referenced widely in thermal comfort research. Such widely referenced functions include the ability to apply the adaptive model’s method to conditioned or mixed-mode buildings as well as the application of the adaptive model to times of the year when it is considered too cold by ASHRAE and the ISO for an adaptive standard. All of these variations on the standards can be accessed through the new “PMV Comfort Parameters” and “Adaptive Comfort Parameters” components. As a final nod to dual support for US/European standards, it is now possible to view the psychrometric chart as a Molier i,x diagram.
EPWMap - After years of struggling with the text-based indexing of the DOE’s epw file database, it is now possible to search for weather files using a map interface and search bar thanks to Mostapha’s recent web interface built with D3 and GoogleMaps (http://mostapharoudsari.github.io/epwmap/). From here on out, the Ladybug “Download EPW” component will direct you to this interface.
“RunItAll” Released as “Fly” - In preparation for future features that will assist with exploring of large multidimensional design spaces, this release of Ladybug includes a component by the name of “Fly” that is meant to run through all of the combinations of a given set of sliders. Those who follow this forum closely might recognize it as a reincarnated version of a component called “RunItAll” that appeared in some older example files. You can find an example file here: http://hydrashare.github.io/hydra/viewer?owner=mostaphaRoudsari&fork=hydra_1&id=Parametric_Daylight_Analysis
Shade Benefit Evaluator Validated + Published - After a long process of testing, the key functions within the comfort and energy shade benefit evaluator components have been validated against several similar software and energy modeling tools. A paper published to the SimAUD conference regarding this validation can be found here: https://www.dropbox.com/s/tvdj6d2giswurew/SIMAUD_Paper12.pdf?dl=0. Special recognition goes to Panagiotis Samaras, who ran many of these intensive tests for his thesis. Along with this validation, there are a few more variables that have been exposed to allow more freedom of running the shade benefit functions including the use of higher sky resolutions and multiple shade benefit test regions for a given shade.
Color Gradient Library - After realizing that several of us wanted quick access to common color gradients that we frequently plug into the Legend Parameters component, we have now added a component called “Color Gradient Library” to do just this. An image displaying all of these gradients can be found here:https://github.com/mostaphaRoudsari/ladybug/blob/master/resources/gradients.jpgAnd an example file showing how to use the library can be found here:http://hydrashare.github.io/hydra/viewer?owner=chriswmackey&fork=hydra_2&id=Color_LibraryIf you feel that there is a common gradient that is currently missing, feel free to start a discussion on our GH group about it and we should include it soon.
Solar Time Available - The Ladybug Sunpath now includes an option to display solar time, which many have found to be more intuitive and easy to work with when designing with solar geometry. Solar time is also useful for minimizing an east vs west bias that can develop in sunlight hour studies without having to generate sun vectors at very small timesteps.
Monthly/Daily Totals for Hourly Data - The Ladybug “Average Data” component now includes the ability to total the values for months and days (as opposed to timply averaging them). This is useful particularly when you want to get monthly or daily values of total energy or visualize these totals on the monthly bar chart.
Increased IP Functionality - This release of Ladybug includes several more features that assist with converting data for an IP audience including the ability to view an IP Psychrometric or Adaptive Chart by plugging in temperature values in Farenheit as well as a number of and new converter components for the following: Wh to BTU, R-Value SI to R-Value IP, m/s to mph, Liters to Gallons. Note that Honeybee is still largely SI (requiring your Rhino model to be in meters to run energy simulations).
Mesh-to-Hatch and Future BakeIt Plans - Given that the current BakeIt_ option has only been implemented on a few components with relatively minimal use, it has been decided that future implementations of BakeIt_ will provide not just a means of recording parametric results in the Rhino scene but will also support a full pathway to vector-based programs (like Illustrator and Inkscape). As such, BakeIt_ will place text in the Rhino scene as actual editable text (not meshes) and colored meshes will be output as groups of colored hatches (so that they appear as color-filled polygons in vector-based programs). In order to give those interested in this future capability a chance to experiment at the present, a “Mesh-To-Hatch” component has been added to the Extra tab.
HONEYBEE
Fully Functional Microclimate Maps - Finally, after a long and arduous thesis followed by a couple of months of bug-fixing, Chris Mackey is pleased to announce that the ability to produce high resolution temperature maps from EnergyPlus results is complete. Together, these maps account for four key variables that produce microclimatic diversity in and around buildings - MRT variation from different surface temperatures, solar radiation shining directly on occupants, average air temperature diversity, and air temperature stratification. In addition to using these 4 variables to produce high-resolution visuals of temperature, it is also possible to produce maps of thermal comfort by using any of the three primary thermal comfort models in Ladybug (PMV, Adaptive, and Outdoor (UTCI)). Support currently exists to produce maps for both indoor and outdoor conditions and, while the temperature values and indoor comfort values currently produced are highly accurate, the outdoor wind speeds are calculated using the simplified assumptions of EnergyPlus and will be revised to enable more accurate accounting for the effects of wind on outdoor comfort in the next stable release. The whole workflow is broken down into eight components that can all be found under the 9 | Energy Energy tab. For some videos showing some time-lapse thermal renderings made from these tools see this video playlist:https://www.youtube.com/playlist?list=PLruLh1AdY-Sj3ehUTSfKa1IHPSiuJU52AFor the full 150-page documentation of the tools produced for Chris’s thesis, see this link:https://www.dropbox.com/s/k4r4rd279y4td9n/Mackey_Thesis.pdf?dl=0Finally, if you want to dive in and produce some comfort maps for yourself, you can find an example file here for indoor maps:http://hydrashare.github.io/hydra/viewer?owner=chriswmackey&fork=hydra_2&id=Indoor_Microclimate_MapAnd an example file here for outdoor maps:http://hydrashare.github.io/hydra/viewer?owner=chriswmackey&fork=hydra_2&id=Outdoor_Microclimate_Map
Thermal Autonomy / Thermal Comfort Percent - In addition to the new thermal mapping capabilities, this release includes the ability to use these maps to calculate a series of spatial thermal comfort metrics that are meant to mirror the metrics currently used to evaluate daylight (daylight autonomy, UDI, etc.). Specifically, these metrics are the following:Thermal Comfort Percent - The percentage of occupied time that a given point in space is thermally comfortable.Thermal Autonomy - The percentage of occupied time that a given point in space is thermally comfortable without the addition of any heating or cooling energy.Overheated Hours - The percentage of occupied time when a given point is space is too hot to be thermally comfortable.Underheated Hours - The percentage of occupied time when a given point is space is too cold to be thermally comfortable.All of these metrics can be accessed through the “Thermal Autonomy Analysis” component and you can find an example file here:http://hydrashare.github.io/hydra/viewer?owner=chriswmackey&fork=hydra_2&id=Comfort_Autonomy
Energy Balance Visualizations - In order to help understand the flow of energy through Honeybee energy models, it is now possible to completely reconstruct the energy balance calculation of EnergyPlus from the energy simulation results. This is facilitated by the new EnergyPlus “Construct Energy Balance” component and some new features added to the monthly bar chart. See here for an example:http://hydrashare.github.io/hydra/viewer?owner=chriswmackey&fork=hydra_2&id=Energy_Balance
More Geometry Control for Glazing - In order to make it faster to assign several different types of glazing geometries to your energy models, the “AddHBGlz” can now be used to add glazing surfaces to HBzones (not just HBsurfaces). Furthermore, the “Glazing Based on Ratio” component now contains several more inputs that enable you to customize window geometry on orthogonal surfaces, including the ability to set the horizontal distance between windows and the ability to split windows vertically into a lower view window and higher daylight window.
Earth Tube Capability - Thanks to the efforts of Anton Szilasi, it is now possible to assign earth tubes to your energy models in order to test the potential of this powerful passive strategy. See here for an example file:http://hydrashare.github.io/hydra/viewer?owner=antonszilasi&fork=hydra&id=HB_EarthTube
North Input For Annual Daylight - After the toil of having to rotate your model any time you wanted to run an annual daylight analysis, we are happy to announce that the annual daylight recipe now contains a working “North” input.
Honeybee Object Transforms - After realizing that many of us wanted to construct energy models of multi-story buildings by duplicating and moving zones, this capability is now easily facilitated with a set of three components to duplicate and transform your HBObjects. Specifically, this includes a component to move (translate) your HBObject, mirror (reflect) your HBObject, and rotate your HBObject. Using these components ensures that any properties that you have assigned to your original HBObject will be present in the transformed HBOjbect, allowing you to build large energy models very quickly. The three components can currently be found under the WIP tab.
And finally, it is with great pleasure that we welcome Boris Plotnikov to the team. As mentioned in the above release notes, Boris has added a highly advanced solar envelope component to the project.
As always let us know your comments and suggestions.
Enjoy!
Ladybug+Honeybee development team
…