Last time I learned from you that a HB daylight recipe can accept a compressed HB objects, which is very helpful in running big models.
Following this idea, I wonder if a recipe can accept multiple compressed HB objects, say we have urban context in one object, some building geometry and grid in another object, and lastly facade as itself? I think this will be helpful if we want to change facade and reused the rest objects, or just split a big model into pieces.
If this is not currently available, can this feature be added in the future? Keen to know your thought. Thanks.
Can you describe the pain points that you are experiencing by just putting all of the objects in one model and corresponding compressed file? At the moment, I don’t fully understand why you are asking for this. Are you running our of memory on your machine or something like that?
Maybe we can enable to recipes to take a model Radiance Folder as input instead of a model file. Then, you can just throw whatever extra .rad files that you want in the folder.
Thanks Chris. Out of memory could be a paint point for bigger model but I think the biggest benefit we can get from this are the flexibility and time-saving.
For example, in one model we may have some object that are not changing while we evaluate different design options. So this will avoid re-creating the objects that are not changing. We may also have grid base sim as well as view base sim in the same project so it will be beneficial if we can just save grids and views as objects and then pushed from to the recipe together with model.
As you suggested, being able to create rad file and then put extra rad files in the folder could achieve this. This functionality was available in legacy and honeybeePlus as the radiance scene files so I would love to hear if we can bring them back.
That is why I was asking because enabling the recipes to accept multiple .pkl inputs would not be time-saving. It essentially means that each file would have to get loaded up and joined into one .pkl file before being sent to the rest of the simulation, which could significantly increase the run time.
Conversely, all of the current Radiance recipes start by translating the Model file (either in the form of a HBJSON or HBPKL) into a Radiance folder. So, if we allowed you to plug the path to a Radiance folder into the recipe instead of a model file, this could actually save some time in the first step of the recipe. Moreover, you could drop whatever extra files you want into this folder as long as you put them in the right place according to the Radiance Folder Structure.
We already have a component that can translate your Honeybee Model to a Radiance folder and we can easily add another that just serializes lists of objects into individual .rad/.pts/.vf files. So, then, you can write or coy these files into this Radiance folder. Or, better yet, we just add an input on the “Model to Rad Folder” component for _add_files, which senses the file extension and drops the extra objects into the correct subfolder.
I guess I’m just uncertain if this whole effort is really worth it because being able to create honeybee objects from meshes in LBT is already pretty fast. We had been thinking that this essentially replaces the speed that you got with “scene files” and “additionalRadFiles” that you had in older versions.
I would just want to be sure that it’s the creation of these files that is really THE pain point and not some other issue that arises when you create models like yours, which must have hundreds of thousands of polygons. For example if this is the bigger pain point, maybe we should be focusing our efforts elsewhere.
The rad folder option sounds good to me. Should give the flexibility as we had before.
I agree with you that loading different honeybee objects into grasshopper could make things worse. In terms of time saving, the benefit may not come from meshes to honeybee object but come from loading geometry, assigning material etc. These steps are not necessary the LBT’s responsibility but creating model piece by piece can be sweet for big models.
Ok, you won me over with the flexibility argument and the fact that the octree creation didn’t turn out to be a bigger pain point. It will take a while to implement, though, and the first step is to enable the command that currently translates the HBJSON and HBPKL files to the Radiance folder to accept a zipped radiance folder as input. I opened an issue for it here:
… and you can check there to see the progress on enabling this.