Grasshopper

algorithmic modeling for Rhino

This post is about 10 days overdue, but as they say, better late than never! Also this is two posts in one post. If you're not interested in the news about the new releases scroll down to the end of the post.

10 days ago was the 4th anniversary of the release of the first version of Ladybug and as the title says, I wanted to share with you what 2017 entails for Ladybug Analysis Tools (previously known as Ladybug + Honeybee).

In December 20016 at the AEC Tech Hackathon, I gave a presentation which pretty much covers all I need to write here. I’m copying the links to the videos so you can watch them and I will just highlight the most important topics. Here are the slides that I used for this presentation.

The first major release of 2017 is a new version of the original Ladybug + Honeybee plugins, which will hereafter be referred to as the legacy version of Ladybug Analysis Tools. Now that the plugins have been fully connected to the major open source engines and databases, the majority of changes represent “icing on the cake.” There are a number of new components related to maximizing the visual capabilities of Rhino, including contour map visualizations, components to make rendered animations, texture mapping components for transparent meshes (and connections to VR programs), and stereographic sky projections. Furthermore, the last of the thermal comfort models for local discomfort (drafts and radiant asymmetry) have been incorporated along with components that help calculate discomfort from given geometric and thermal criteria (a simplified downdraft model and a view factor component). There have been a few extensions of OpenStudio/E+ capabilities to get out HVAC system sizing results and to request/search through the hundreds of outputs that E+ offers. Finally, there are a few workflow improvements, including changes to use less memory when building large energy models and a workflow to import HBZones from gbXML. Chris has been leading the development for the legacy version during the last year or so and he deserves all the credits. There is no way to thank him enough for what he does on a daily basis. I can only say that we are all so lucky to have him around!

After the release of the legacy plugin, the next major release of 2017 will be the public release of Butterfly, which is already long overdue. If you are watching the project on GitHub, you should already know that we are very close and are trying to make the final improvements before the release. The release will have its own separate release notes. For now, I want to thank Theodore Galanos and everyone who helped us with their suggestions during the development process. There would be no Butterfly if it wasn’t for Theodore.

Butterfly’s release will be followed by the release of Honeybee[+]. The first release of Honeybee[+] supports most of the functionalities in the current version of Honeybee for daylight simulation plus it addresses many of the current limitations for annual daylight modeling by using Radiance 3-phase method. It should also support Grasshopper both on Windows and Mac as well as Dynamo. There is much more about Honeybee[+] which again will be included in a separate post. I want to thank Sarith Subramaniam and everyone who helped us with testing the code during the development. Honeybee[+] won’t have most of its features if it wasn’t for Sarith.

I also want to thank everyone on the forum who helps other users with questions and solutions. That’s how I and the rest of the developers get the time to focus on the new developments. Yet I didn’t get a chance to update the graph for this year but you know who you are. Thank you!

Finally, I am posting a modified draft from last year February. Chris and I drafted this post last year but never posted it as I was waiting for the “right time” to post it. The “right time” would be when we have free time to answer all the questions but that time seems not to come! We will do our best to reply to your comments as much as we can. Here is that post:

----

Even though we receive comments and ideas from many of you on a daily basis Tim's recent comment [it was recent at the time!] made me think that we should, once more, explicitly ask for your comments while developing the new version of Ladybug (and at some point Honeybee), and also collect the ongoing ones in a single place.

So post your comments, suggestions and wishes here and let us know what can we do to make Ladybug and Honeybee better. Any type of comments are welcome as far as you tell us why you think it is important. Here are a couple of questions to get you started:

- What is currently missing? Why do you think that missing feature is important?

- If you could only change one thing, what would it be and why?

- What do you like the most about Ladybug + Honeybee that you don't want to change in the new release?

- What kind of bottlenecks do you run into? - What have you done with Ladybug + Honeybee that you think it should/could have been done much simpler if we could have made a couple of changes?

- What do you think will be essential/missing from Ladybug for Dynamo?

- ...

Your turn! Let us know your thoughts!

Views: 3818

Replies are closed for this discussion.

Replies to This Discussion

Thank you Ji for the nice comment and your great work. Always inspiring!

Hi Mostapha,

Great work done by developing such wonderful tools.

I have a suggestion for WindRose Component.

As per attached image,

Outer two lines indicate Wind Speed and Frequency respectively.

Being an analyst, we are aware about what they indicate, but for a reviewer it is harder to understand.

Providing a legend for that would make that data easily understandable.

Some solution I have come up with is as per image below:

Keep up the great work.

Thanks,

Bijit.

Hi Bijit, Thanks! I leave making the decision on this one to Devang. He has implemented all the latest improvements for WindRose. What if we just color the text? The colored geometries might be confusing as we have a colorful legend.

That would be great Mostapha, Thanks a lot.

And yes, I support your argument about providing color to text.

Looking forward for the update, Devang Chauhan.

Best,

Bijit.

Hi Bijit & Mostapha,
I agree that coloring the text will be better.

Bijit,
I propose that we color the text outside of this component. To do that, added two more outputs to the windRose component.

Ladybug is coloring the meshes as black, and rightly so. Otherwise, the meshes will have default Grasshopper mesh color which most people don't like and I believe that it is a deliberate decision by the developers of Grasshopper so that the users change the color.


So since Ladybug is coloring the meshes, the native Custom Preview component can not help you color already colored meshes. Therefore, I wrote a
small component that lets you do that.

Please find a sample attached.

Thanks,
-Devang

Attachments:

Use this file instead. Made a minor change.

Attachments:

Hi Devang! Thanks. Since it's already a mesh you can easily color them inside the component. If we're going to color the text then let's do it inside the component.

Hi Mostapha,

Thank you for your review.

Yes. It's easy to color the meshes inside the component. The thing is, we want to leave the choice of colors in the hands of the users. And to do that, the way I see it, we will have to add two more inputs to the component for colors. Will you be ok with that?

Thanks,

-Devang

This is good to know.  The Ladybug[+] function that generates Rhino text should definitely include an option for color.  It's actually pretty easy to implement now on the Legacy plugin, Devang, if you wanted to give it a shot.  You just have to add an extra output to the text2Srf function for color and set the default to black (if no input is provided).

-Chris

Hi Chris,

Yes. I could easily implement that inside the component. But I am concerned about adding good two inputs for colors. One for frequencies and the other for average velocities. The advantage of doing this outside the component is that one can also color the Title Text (The text Below WindRose) if one wants to. If you and Mostapha are good with adding two more inputs then I will implement it.

The advantage of doing this outside the component is that one can also color the Title Text (The text Below WindRose) if one wants to

or any other already colored mesh for that matter.

Devang,

I am definitely in favor of the new outputs that you have added to the wind rose and the ability to assign colors outside of the component.  You can also use the native GH color mesh component to color the text rather than the python component in your example.

The only additional thing I am (and I think Bijit is) advocating for is that the default text for the speed frequency be a different color than black just for the sake of clarity to new users.  Even if it was just a different shade of dark grey, this would be helpful.  I don't think that we need to add another set of inputs on the component to change these default colors as people will always have the ability to override it outside of the component.

Let me know if this makes sense.

-Chris

RSS

About

Translate

Search

Photos

  • Add Photos
  • View All

Videos

  • Add Videos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service