onents (radiation, sunlight-hours and view analysis) which let you study the effect of the orientation of your building and the analysis result. When you come to a question similar to "what is the orientation that the building receives the most/least amount of radiation?" is probably the right time to use this component.
HOW?
I'll try to explain the steps using a simple example. Here is my design geometries. The building in the center is the building to be designed and the rest of the buildings are context. I want to see the effect of orientation on the amount of the radiation on the test building surfaces from the start of Oct. to the end of Feb. for Chicago.
First I need to set up the normal radiation analysis and run it for the building as it is right now. [I'm not going to explain how you can set up this since you can find it in the sample file (Download the sample file from here)]
Now I need to set up the parameters for orientation study using orientationStudyPar component. You can find it under the Extra tab:
At minimum I need to input the divisionAngle, and the totalAngle and set runTheStudy to True. In this case I put 45 for divisionAngle and 180 for the totalAngle which means I want the study to be run for angles 0, 45, 90, 135 and 180.
[Note1: The divisionAngle should be divisible by totalAngle.]
[Note 2: If you don't provide any point for the basePoint, the component will use the center of the geometry as the center of the rotation.]
[Note 3: You can also rotate the context with the geometry! Normally you don't have the chance to change the context to make your design work but if you got lucky the rotateContext input is for you! Set it to True. The default is set to False.]
You're all set for the orientation study, just connect the orientationStudyPar output to OrientationStudyP input in the component and wait for the result!
The component will run the study for all the orientations and preview the latest geometry. To see the result just grab a quick graph and connect it to totalRadiation. As you can see in the graph 135 is the orientation that I receive the maximum radiation. Dang!
If you want to see all the result geometries set bakeIt to True, and the result will be baked under LadyBug> RadaitionStudy>[projectname]> . The layer name starts with a number which is the totalRadiation.
Mostapha…
ly this is a Rhino.Python problem and not a Grasshopper issue, but it could apply to both!
I was trying to take a simple example of moving a ball around and see how it could be animated through Rhino.Python. The code works great in wire frame with now memory issues at all. However, when I switch the view to Shaded or Rendered, things go south pretty quickly. The RAM usage of Rhino which was steady around 350mb (ish) now grows every frame after a minute or so, it is in the GB's and never drops even after the script has stopped.What gives? Clearly this must be possible because Bongo does something similar when it does animations. Check out my code below and I would love to hear your thoughts.
import time
import rhinoscriptsyntax as rs
import Rhino
height = 100
width = 100
x = 0
y = 0
xspeed = .1
yspeed = .3
start_time = time.time()
end_time = 60
run_time = 0
sphere = rs.AddSphere((x,y,0), 5)
while run_time < end_time:
x = x + xspeed
y = y + yspeed
if x > width/2 or x < -width/2:
xspeed = xspeed * -1
if y > height/2 or y < -height/2:
yspeed = yspeed * -1
rs.MoveObject(sphere, (xspeed, yspeed, 0))
Rhino.RhinoApp.Wait()
run_time = time.time() - start_time…
uick answers. Below you will find some suggestions, but don't think of them as rules and especially don't think of them as guarantees.
1. Choose a descriptive title for your post
Don't call your question "Help!" or "I have a problem" or "Deadline tonight!", but actually describe the problem you are having.
2. Be succinct but clear in your wording
People need to know some details about your problem in order to understand what sort of answers would satisfy you, but nobody cares about how angry your boss or how bad your teacher or how tight your deadline is. Talk about the problem and only the problem. If you don't speak English well, you should probably post in your native language as well as providing a Google Translation of your question.
3. Attach minimal versions of all the relevant files
If you have a GH/GHX file you have a question about, attach it to the post. Don't expect that people will recreate a file based on a screen-shot because that's a lot of pointless work. It's also a good idea to remove everything non-essential from a GH file. You can use the 'Internalise Data' menu option to cut everything to the left of a parameter:
If you're importing curves or Breps or meshes from Rhino, you can also internalise them so you won't have to post a 3DM file as well as a GH file. If you do attach large files, consider zipping them first. Do not use RAR, Ning doesn't handle it.
It is especially a good idea to post files that don't require any non-standard components if at all possible. Not everyone has Kangaroo or Hoopsnake or Geco installed so if your file relies on those components, it might not open correctly elsewhere.
4. Include a detailed image of the GH file if it makes sense
If your question is about a specific (group of) components, consider adding a screenshot of the file in the text of the post. You can use the Ctrl+Shift+Q feature in Grasshopper to quickly create nice screenshots with focus rectangles such as this:
5. Include links to online resources if possible
If you have a question about Schwarz Minimal surfaces, please link to a website which talks about these.
6. Create new topics rather than continuing old ones
It's usually better to start a fresh question, even if there's already a discussion that kinda sorta tangentially touches upon the same issue. Please link to that discussion, but start anew.
7. This is not a 'do my work for me' group
Many of us like to help, but it's good to see effort on our part being matched by effort on your part. Questions in the form of 'I need to do X but cannot be bothered to try and learn the software' will (and should) go unanswered.
7b. Similarly, questions in the form of 'How do I quickly recreate this facade that took a team of skilled professionals four months to figure out?' have a very low success rate.
--
David Rutten
Lead Grasshopper Development
Robert McNeel & Associates…
Added by David Rutten at 12:58pm on October 1, 2013
2: https://vimeo.com/107502226
------------------------------------------------------------------------------------------------
Hi all,
1. Chris, Chien Si and I will present Ladybug and Honeybee at IBSA-USA NYC this Thursday (August 21st). The presentation will include some of the latest developments that we are working on. If you are interested to know more about some of the new developments and see some of the workflows and you are around New York then just stop by. If can't attend in person you can still watch the presentation online. Check the links below. (Make sure to register by Wednesday if you are attending in person.)
2. We would like to show some of the works that you have done with Honeybee and Ladybug during the presentation so if there is anything that you think is interesting and can be presented publicly send it to us at thisisladybug@gmail.com or just post it here. Make sure to let us know who do you want us to credit the image.
3. That's it for now. I copy the information about the presentation below and hope to see some of you there. Thanks for your help and support.
Cheers,
Mostapha
IBPSA-USA New York Regional Chapter presents:
Parametric Modeling Tools | Ladybug and Honeybee
Location: Thornton Tomasetti, 44 East 27th street (between Madison and Park)
Date & Time: Thursday, August 21, 2014 - 6:00-7:30 PM.
6:00-6:30 PM Networking
6:30-7:30 PM Ladybug and Honeybee
Mostapha Sadeghipour Roudsari, Thornton Tomasetti
Chris Mackey, MIT
Chien Si Harriman, Terabuild
7:30-7:45 PM Q & A
Click here to register**: https://attendee.gotowebinar.com/register/6507378565592582402
**Please register at least a day in advance if you wish to attend in person
Descriptions
Ladybug + Honeybee
Ladybug and Honeybee are open source environmental plugins for Grasshopper that help architects and engineers create an environmentally-conscious architectural design.
Ladybug imports standard EnergyPlus Weather files (.EPW) into Grasshopper and provides a variety of 3D interactive graphics to support the decision-making process during the initial stages of design. The plugin also provides further support for designers as they test their initial design options with radiation, sunlight-hour, and shading analyses. Integration with Grasshopper allows for an almost instantaneous feedback and, since the plugin runs within the design environment, the information and analyses are interactive.
Honeybee connects Grasshopper3D to EnergyPlus, Radiance, Daysim and OpenStudio for building energy and daylighting simulation. The Honeybee project intends to make many of the features of these simulation tools available in a parametric way. Just as users have made changes to geometry for years in Grasshopper, now users can parameterize system types, zoning schemes, schedules of operation, daylight sensor placement and controls - all of the “hardcore” simulation parameters that have never been exposed to parametric modeling tools.
https://www.facebook.com/LadyBugforGrasshopper http://www.grasshopper3d.com/group/ladybug
…
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…
: ----------------------------------------------------------------------------------------------
1)
Hi Clemens I've analysed a plate structure using Karamba and wanted to do a convergence analysis on results computed as a function of the number of elements.
Now, when strictly looking at the result magnitudes of internal energy (IE) and maximum displacement (w_max), it's acceptable, that their relative deviations are very small. But I cannot explain the tendencies of their graphs. From what I know, FEM should always compute underestimated results when compared to analytical solutions. So I don't understand why both the IE and w_max seem to be decreasing for an increasing number of elements.
But my main concern is the behaviour of the peak moment, it seems to be simply hill climbing untill suddenly a singularity kicks in. I initially wanted to use the peak moment as a fitness value for optimisation, but with this behaviour, I don't think that would make sense. I've attached my GH file as well.
It would be much appreciated if you could enlighten me on these subjects. Cheers Daniel Andersen
2)
Hi Daniel,
I could not run your definition because I have not all the plug-ins installed that you use.
You are basically right that the displacement should increase with a finer mesh. However the result of the shell analysis also depends on the shape of the triangles (well formed vs. very distorted). In order to test this, I think it would be interesting to use a very simple example (e.g. rectangular plate with one column) where you can easily control mesh generation. Would you like to start a discussion on this in the karamba group at http://www.grasshopper3d.com/group/karamba?
It is not a good idea to use the bending moment at a singularity for optimization because the result will be heavily mesh dependent. Also real columns do have a certain diameter and modeling them as point supports introduces an error.
Best,
Clemens
3)
oh, and by the way!
Here's some relevant literature on handling peak moments: https://books.google.dk/books?id=-5TvNxnVMmgC&pg=PA219&lpg=PA219&dq=blaauwendraad+plates+and+fem&source=bl&ots=SdDcwnrSA1&sig=6HulPmKNIhqKx4_rGxitteMC4CU&hl=da&sa=X&ved=0CDEQ6AEwA2oVChMIg66k0LPaxgIVgY1yCh1KPAeY#v=onepage&q=chapter%2014&f=false (Blaauwendraad, J., 2010. Plates and FEM : Surprises and Pitfalls, see Chapter 14) It would be great if a feature dealing with peak moments could be incorporated in Karamba. In my work, I ended up exporting my models to Robot in order to verify the moment values. Best, Daniel
4)
Hi Daniel,
thank you for your reply and the link to Blaauwendraads excellent book!
At some point I hope to include material nonlinearity in Karamba which will help in dealing with stress singularities.
If you want you could open a discussion with a title like 'moment peaks in shells at point-supports'. Then we could copy and paste the text of our conversation into it.
Best,
Clemens
----------------------------------------------------------------------------------------------…
nside a script.
However, it should be noted that to do so introduces a significant amount of overhead, which may impact performance. This is because (to the best of my understanding) all the methods described below actually instantiate and execute a virtual Grasshopper document, with components and everything else. Whenever possible, it is advisable to simply call RhinoCommon functions - these are designed to be called in code and are more streamlined.
Python
Grasshopper's Python is unique among the scripting languages in that it has a "node-in-code" mechanism for this purpose in the form of the ghpythonlib library and its "components" class. Here is some example code:
from ghpythonlib import components as ghcomp import Rhino a = ghcomp.Circle(Rhino.Geometry.Plane.WorldXY,25.0) result = ghcomp.DeconstructBrep(b) faces = result[0] edges = result[1] vertices = result[2]
This code will call the "Circle" component with the world XY base plane and a radius of 25, and then call the "Deconstruct Brep" component on a brep (input to the script as "b").
The arguments passed to the function will correspond to the inputs of the component, and the function will return the output (the data itself in the case of a component with only one output, and a tuple of data in the case of multiple outputs, as in the second example above).
For more info on this technique, see this post by Steve Baer.
C#/VB.Net
James Ramsden has described a method for doing this in these two posts on his blog:
Run a Grasshopper Component from C# Code
Read and edit persistent data in Grasshopper components with C#
His examples are in C#, but everything he describes can also be done in VB.net with some syntax tweaks.
The core of his method is to programmatically instantiate a component, populate its inputs, and then create a virtual grasshopper document in which to execute the code. He then harvests the outputs and converts them back to simple data. Here is his example code for calling the "Circle by Normal and Radius" component:
var cs = new CurveComponents.Component_CircleCNR(); //add the circle centre (input 0) var pp = cs.Params.Input[0] as Grasshopper.Kernel.GH_PersistentGeometryParam<Grasshopper.Kernel.Types.GH_Point>; pp.PersistentData.ClearData(); pp.PersistentData.Append(new GH_Point(new Point3d(0, 0, 3))); //add the circle radius (input 2) var pn = cs.Params.Input[2] as Grasshopper.Kernel.GH_PersistentParam<Grasshopper.Kernel.Types.GH_Number>; pn.PersistentData.ClearData(); pn.PersistentData.Append(new GH_Number(y)); //y is another variable //run calculations cs.ExpireSolution(true); //add to a dummy document so we can read outputs var doc = new Grasshopper.Kernel.GH_Document(); doc.AddObject(cs, false); //read output circle cs.Params.Output[0].CollectData(); A = cs.Params.Output[0].VolatileData.get_Branch(0)[0]; //remove that component doc.RemoveObject(cs.Attributes, false);
Final notes
For a great many of the simple components, there are in fact methods in RhinoCommon that accomplish exactly the same thing. Note the complexity of the above code, and then look at the equivalent code using RhinoCommon methods:
Circle circle = new Circle(new Plane(origin, normal), radius);
In my experience it is preferable to just call or construct the methods you need using RhinoCommon rather than relying on trying to call components from inside your code.
Lastly, It is my understanding that this concept is central to David's thinking around GH2 - so that it in the next version it will be significantly more streamlined to switch between components and code representations. (I have no special knowledge of GH2 development - this is just what I have seen David say on the forums, and as usual any statements about future features are subject to change.)
Hope this is helpful!
…
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).
…
e a fundamental failure on my part. On the other hand, Grasshopper isn't supposed to be on a par with most other 3D programs. It is emphatically not meant for manual/direct modelling. If you would normally tackle a problem by drawing geometry by hand, Grasshopper is not (and should never be advertised as) a good alternative.
I get that. That’s why that 3D shape I’m trying to apply the voronoi to was done in NX. I do wonder where the GUI metaphor GH uses comes from. It reminds me of LabVIEW.
"What in other programs is a dialog box, is 8 or 10 components strung together in grasshopper. The wisdom for this I often hear among the grasshopper community is that this allows for parametric design."
Grasshopper ships with about 1000 components (rounded to the nearest power of ten). I'm adding more all the time, either because new functionality has been exposed in the Rhino SDK or because a certain component makes a lot of sense to a lot of people. Adding pre-canned components that do the same as '8 or 10 components strung together' for the heck of it will balloon the total number of components everyone has to deal with. If you find yourself using the same 8 to 10 components together all the time, then please mention it on this forum. A lot of the currently existing components have been added because someone asked for it.
It’s not the primary components that catalyzed this thought but rather the secondary components. I was toying with a component today (twist from jackalope) that made use of three toggle components. The things they controlled are checkboxes in other apps.
Take a look at this jpg. Ignore differences; I did 'em quickly. GH required 19 components to do what SW did with 4 commands. Note the difference in screen real estate.
As an aside, I really hate SolidWorks (SW). But going forward, I’ll use it as an example because it’s what most people are familiar with.
"[...] has a far cleaner and more intuitive interface. So does SolidWorks, Inventor, CATIA, NX, and a bunch of others."
Again, GH was not designed to be an alternative to these sort of modellers. I don't like referring to GH as 'parameteric' as that term has been co-opted by relational modellers. I prefer to use 'algorithmic' instead. The idea behind parameteric seems to be that one models by hand, but every click exists within a context, and when the context changes the software figures out where to move the click to. The idea behind algorithmic is that you don't model by hand.
I agree, and disagree. I believe parametric applies equally to GH AND SW, NX, and so forth, while algorithmic is unique to GH (and GC and Dynamo I think). Thus I understand why you prefer the term. I too tend to not like referring to GH as a parametric modeler for the same reason.
But I think it oversimplifies it to say parametric modelers move the clicks. SW tracks clicks the same way GH does; GH holds that information in geometry components while SW holds it in a feature in the feature tree. In both GH and SW edits to the base geometry will drive a recalculation, but more commonly, it’s an edit to input data, beit equations or just plain numbers, that drive a recalculation.
I understand the difference in these programs. What brought me to GH is that it can create a visual dialog that standard modelers can’t. But as I've grown more comfortable with it I’ve come to realize that the GUI of GH and the GUI of other parametric modelers, while looking completely different, are surprisingly interchangeable. Do not misconstrue that I’m suggesting that GH should replace it’s GUI with SW’s. I’m not. I refrain from suggesting anything specific. I only suggest that you allow yourself to think radically.
This is not to say there is no value in the parametric approach. Obviously it is a winning strategy and many people love to use it. We have considered adding some features to GH that would make manual modelling less of a chore and we would still very much like to do so. However this is such a large chunk of work that we have to be very careful about investing the time. Before I start down this road I want to make sure that the choice I'm making is not 'lame-ass algorithmic modeller with some lame-ass parametrics tacked on' vs. 'kick-ass algorithmic modeller with no parametrics tacked on'.
Given a choice, I'd pick kick-ass algorithmic modeller with no parametrics tacked on.
2. Visual Programming.
I'm not exactly sure I understand your grievance here, but I suspect I agree. The visual part is front and centre at the moment and it should remain there. However we need to improve upon it and at the same time give programmers more tools to achieve what they want.
I'll admit, this is a bit tough to explain. As I've re-read my own comment, I think it was partly a precursor to the context sensitivity point and touched upon other stated points.
This now touches upon my own ignorance about GH’s target market. Are you moving toward a highly specialized tool for programmers and/or mathematicians, or is the intent to create a tool that most designers can master? If it’s the former, rock on. You’re doing great. If it’s the latter, I’m one of the more technically sophisticated designers I know and I’m lost most of the time when using GH.
GH allows the same freedom as a command line editor. You can do whatever you like, and it’ll work or not. And you won’t know why it works or doesn't until you start becoming a bit of an expert and can actually decipher the gibberish in a panel component. I often feel GH has the ease of use of DOS with a badass video card in front.
Please indulge my bit of storytelling. Early 3D modelers, CATIA, Unigraphics, and Pro-Engineer, were unbelievably difficult to use. Yet no one ever complained. The pain of entry was immense. But once you made it past the pain threshold, the salary you could command was very well worth it. And the fewer the people who knew how to use it, the more money you could demand. So in a sense, their lack of usability was a desirable feature among those who’d figured it out.
Then SolidWorks came along. It could only do a fraction of what the others did, but it was a fraction of the cost, it did most of what you needed, and anyone could figure it out. There was even a manual on how to use it. (Craziness!) Within a few short years, the big three all had to change their names (V5, NX, and Wildfire (now Creo)) and change the way they do things. All are now significantly easier to use.
I can tell that the amount of development time that’s gone into GH is immense and I believe the functionality is genius. I also believe it’s ease of use could be greatly improved.
Having re-read my original comments, I think it sounded a bit snotty. For that I apologize.
3. Context sensitivity.
"There is no reason a program in 2014 should allow me to make decisions that will not work. For example, if a component input is in all cases incompatible with another component's output, I shouldn't be able to connect them."
Unfortunately it's not as simple as that. Whether or not a conversion between two data types makes sense is often dependent on the actual values. If you plug a list of curves into a Line component, none of them may be convertible. Should I therefore not allow this connection to be made? What if there is a single curve that could be converted to a line? What if you want to make the connection now, but only later plan to add some convertible curves to the data? What you made the connection back when it was valid, but now it's no longer valid, wouldn't it be weird if there was a connection you couldn't make again?
I've started work on GH2 and one of the first things I'm writing now is the new data-conversion logic. The goal [...] is to not just try and convert type A into type B, but include information about what sort of conversion was needed (straightforward, exotic, far-fetched. etc.) and information regarding why that type was assigned.
You are right that under some conditions, we can be sure that a conversion will always fail. For example connecting a Boolean output with a Curve input. But even there my preferred solution is to tell people why that doesn't make sense rather than not allowing it in the first place.
You bring up both interesting points and limits to my understanding of coding. I’ve reached the point in my learning of GH where I’m just getting into figuring out the sets tab (and so far I’m not doing too well). I often find myself wondering “Is all of this manual conditioning of the data really necessary? Doesn’t most software perform this kind of stuff invisibly?” I’d love to be right and see it go away, but I could easily be wrong. I’ve been wrong before.
5. Components.
"Give components a little “+” or a drawer on the bottom or something that by clicking, opens the component into something akin to a dialog box. This should give access to all of the variables in the component. I shouldn't have to r-click on each thing on a component to do all of the settings."
I was thinking of just zooming in on a component would eventually provide easier ways to access settings and data.
I kinda like this. It’s a continuation of what you’re currently doing with things like the panel component.
"Could some of these items disappear if they are contextually inappropriate or gray out if they're unlikely?"
It's almost impossible for me to know whether these things are 'unlikely' in any given situation. There are probably some cases where a suggestion along the lines of "Hey, this component is about to run 40,524 times. It seems like it would make sense to Graft the 'P' input." would be useful.
6. Integration.
"Why isn't it just live geometry?"
This is an unfortunate side-effect of the way the Rhino SDK was designed. Pumping all my geometry through the Rhino document would severely impact performance and memory usage. It also complicates the matter to an almost impossible degree as any command and plugin running in Rhino now has access to 'my' geometry.
"Maybe add more Rhino functionality to GH. GH has no 3D offset."
That's the plan moving forward. A lot of algorithms in Rhino (Make2D, FilletEdge, Shelling, BlendSrf, the list goes on) are not available as part of the public SDK. The Rhino development team is going to try and rectify this for Rhino6 and beyond. As soon as these functions become available I'll start adding them to GH (provided they make sense of course).
On the whole I agree that integration needs a lot of work, and it's work that has to happen on both sides of the isle.
You work for McNeel yet you seem to speak of them as a separate entity. Is this to say that there are technical reasons GH can only access things through the Rhino SDK? I’d think you would have complete access to all Rhino API’s. I hope it’s not a fiefdom issue, but it happens.
7. Documentation.
Absolutely. Development for GH1 has slowed because I'm now working on GH2. We decided that GH1 is 'feature complete', basically to avoid feature creep. GH2 is a ground-up rewrite so it will take a long time until something is ready for testing. During this time, minor additions and of course bug fixes will be available for GH1, but on a much lower frequency.
Documentation is woefully inadequate at present. The primer is being updated (and the new version looks great), but for GH2 we're planning a completely new help system. People have been hired to provide the content. With a bit of luck and a lot of work this will be one of the main selling points of GH2.
It begs the question that I have to ask. When is GH1.0 scheduled to launch? And if you need another person to proofread the current draft of new primer.
patrick@girgen.com
I can’t believe wikipedia has an entry for feature creep. And I can’t believe you included it. It made me giggle. Thanks.
8. 2D-ness.
"I know you'll disagree completely, but I'm sticking to this. How else could an omission like offsetsurf happen?"
I don't fully disagree. A lot of geometry is either flat or happens inside surfaces. The reason there's no shelling (I'm assuming that's what you meant, there are two Offset Surface components in GH) is because (a) it's a very new feature in Rhino and doesn't work too well yet and (b) as a result of that isn't available to plugins.
I believe it’s been helpful for me to have figured this out. I recently completed a GH course at a local Community College and have done a bunch of online tutorials. The first real project I decided to tackle has turned out to be one of the more difficult things to try. It’s the source of the questions I posted. (Thanks for pointing out that they were posted in the wrong spot. I re-posted to the discussions board.)
I just can't seem to figure out how to turn the voronoi into legitimate geometry. I've seen this exact question posted a few times, but it’s never been successfully answered. What I'm showing here is far more angular than I’m hoping for. The mesh is too fine for weaverbird to have much of an effect. And I haven't cracked re-meshing. Btw, in product design, meshes are to be avoided like the plague. Embracing them remains difficult.
As for offsetsurf, in Rhino, if you do an offsetsurf to a solid body, it executes it on all sides creating another neatly trimmed body thats either larger or smaller than the original. This is how every other app I know of works. GH’s offsetsurf creates a bunch of unjoined faces spaced away from the original brep. A common technique for 3D voronois (Yes, I hit the voronoi overuse easter egg) is to find the center of each cell and scale them by this center. If you think about it, this creates a different distance from the face of the scaled cell to the face of the original cell for every face. As I've mentioned, this project is giving me serious headaches.
Don't get me wrong, I appreciate the feedback, I really do, but I want to be honest and open about my own plans and where they might conflict with your wishes. Grasshopper is being used far beyond the boundaries of what we expected and it's clear that there are major shortcomings that must be addressed before too long. We didn't get it right with the first version, I don't expect we'll get it completely right with the second version but if we can improve upon the -say- five biggest drawbacks (performance, documentation, organisation, plugin management and no mac version) I'll be a happy puppy.
--
David Rutten
Thank you for taking the time to reply David. Often we feel that posting such things is send it into the empty ether. I’m very glad that this was not the case.
And thank you for all of the work you've put into GH. If you found any of my input overly harsh or ill-mannered, I apologise. It was not my intent. I'm generally not the ranting sort. If I hadn't intended to provide possibly useful input, I wouldn't have written.
Cheers
Patrick Girgen
Ps. Any pointers on how to get a bit further on the above project would be greatly appreciated.
…
curve or locus] of a segment AB, in English. The set of all the points from which a segment, AB, is seen under a fixed given angle.
When you construct l'arc capable —by using compass— you obviously need to find the centre of this arc. This can be easily done in GH in many ways by using some trigonometry (e.g. see previous —great— solutions). Whole circles instead of arcs provide supplementary isoptics —β-isoptic and (180º-β)-isoptic—. Coherent normals let you work in any plane.
Or you could just construct β-isoptics of AB by using tangent at A (or B). I mean [Arc SED] component.
If you want the true β-isoptic —the set of all the points— you should use {+β, -β} degrees (2 sides; 2 solutions; 2 arcs), but slider in [-180, +180] degrees provides full range of signed solutions. Orthoptic is provided by ±90º. Notice that ±180º isoptic is just AB segment itself, and 0º isoptic should be the segment outside AB —(-∞, A] U [B, +∞)—. [Radians] component is avoidable.
More compact versions can be achieved by using [F3] component. You can choose among different expressions the one you like the most as long as performs counter clockwise rotation of vector AB, by 180-β degrees, around A; or equivalent. [Panel] is totally avoidable.
Solutions in XY plane —projection; z = 0—, no matter A or B, are easy too. Just be sure about the curve you want to find the intersection with —Curve; your wall— being contained in XY plane.
A few self-explanatory examples showing features.
1 & 5 1st ver. (Supplementary isoptics) (ArcCapableTrigNormals_def_Bel.png)
2 & 6 2nd ver. (SED) (ArcCapableSED_def_Bel.png)
3 & 7 3rd ver. (SED + F3) (ArcCapableSEDF3_def_Bel.png)
4 & 8 4th ver. (SED + F3, Projection) (ArcCapableSEDProjInt_def_Bel.png)
If you want to be compact, 7 could be your best choice. If you prefer orientation robustness, 5. Etcetera.
I hope these versions will help you to compact/visualize; let me know any feedback.
Calculate where 2 points [A & B] meet at a specific angle is just find the geometrical locus called arco capaz in Spanish, arc capable in French (l'isoptique d'un segment de droite) or isoptic [curve or locus]
of a segment AB, in English. The set of all the points from which a segment,
AB, is seen under a fixed given angle.…