I was just working on upgrading a daylight script from legacy v. 0.0.66 to the latest LBT version. In doing so, I found that grasshopper froze a lot when importing geometry.
As you can se below, the HB Face component is about 19 times slower than the legacy Honeybee_createBHsrfs component.
This was very apperent, when I tried testing the updated script on a project, where it took about 3 hours to create the HB faces from an imported model. Not to run the simulation, but to create the HB faces with reflectances.
For instance, the gh.profiler noted that it took over 2 hours just to assign reflectances for the 5557 frames in the model. And after doing so, I could barely do anything on the canvas without grasshopper freezing.
Well I know that I have some small elements like these in my model, which isn’t great (I was too lazy to clean it up properly. But I don’t see how that effects the difference in the simulation time, as I’m also using this detailed geometry in the Honeybee_createBHsrfs component.
So since I use the same geometry for both components, the main problem must be the components, right?
I’m sending you a private message with the model in question, as I don’t want to share it on the forum. This way, we can hopefully see whether it is the HB Face component or my model that is causing the problem.
If you want to test the script on another model, make sure that the geometry you test is on a layer called 0_Solids::Frames_0.70. Otherwise, group number three won’t work
Sorry for such a late response. I have been in the proverbial “code cave” for the last few weeks.
Generally speaking, the LBT plugin does most of the geometry translation work to the engines when it creates the HB Objects as opposed to legacy where the translation happens when you run the simulation. So that may partly explain what you are experiencing here. In the end, the total time to run a single simulation is somewhat the same between the two but LBT is much better for parametric studies since the translation process only needs to happen once at the start of your script instead of re-translating it every time you start a new simulation.
One quick suggestion is to just mesh your geometry before you create Honeybee Faces with it. The LBT translation code that handles non-planar Breps has a lot of fancy checks in it that try to planarize the geometry as cleanly as possible but it sounds like you don’t need this level of cleanliness for your simulation. So meshing it first will likely make the whole translation process a lot faster.
That makes a lot of sense. I tries passing the geometry through a mesh component first. But when I do this, Rhino shuts down without a warning. I then tried meshing all geometry except the window frames, which worked fine, so I guess that the problem is with the geometry of the frames… I haven’t worked much with meshes, so I don’t exactly know what the problem might be.
I just send you my rhino file in a personal message.
Glad that the meshing seems to have helped but if something like this is happening:
… it sounds like you might have found an issue that’s more on McNeel’s side than ours. I was able to recreate the crash and automatic closing of Rhino on my end by trying to cast your window frames to a mesh in Grasshopper.
So you might want to post this question along with your window frame file to the McNeel Discourse. Or, maybe if you can post it here, someone from the McNeel team like @wim might be able to take a look.
But, if we can’t even get the geometry to convert from a Brep to a Mesh, we’re pretty certainly going to have issues getting it to another format like Radiance. It’s also worth noting that the file you sent me in the PM is over half a GB and this is around the maximum file size for a .3dm file that I’m usually comfortable working at (beyond that the frame rates can get really slow and I usually find it more practical to split the content between multiple .3dm files). So it may be worth keeping in mind that you’re operating a bit beyond what I would consider the recommended range of file size.
You can upload a file you are having issues with on our upload page. You can use wim@mcneel.com as the recipient and make sure to add a link to this thread in the comments field.
Apart from that, I’m not seeing a crash report in our system from you nor @chris. If the crash reporter comes up, please always send those in.
-wim
@wim I just send you the file through your upload page as requested. I just sent the entire model for good measure. Note that the frames are placed under this layer.
The entire geometry is exported from Revit using Rhino.Inside, so I am aware that the detail level is fairly high, but I have used this workflow multiple times before, and though the script usually is slow, it has never crashed like this before. As mentioned early, I have removed doorknops etc. to clean the model a little.
@chris it is interesting that you say this, because this might be the lightest model I’ve worked with in the last two years Previous models were usually in the range between 850-600 MB. That being said, I have for a long time been aware, that I need to find a way to clean the models. It is ALWAYS the frames that take most space and makes the most trouble, but considering to split the model is probably an easier and more practical solution I guess. So thanks for the tip!
Takker. That crashes here as well and the crash reporter never appears.
I’ve put this on the developer’s list to take a closer look - RH-73664 Grasshopper: Brep to Mesh crashes
-wim
Previous models were usually in the range between 850-600 MB. That being said, I have for a long time been aware, that I need to find a way to clean the models. It is ALWAYS the frames that take most space and makes the most trouble, but considering to split the model is probably an easier and more practical solution I guess. So thanks for the tip!