Hi yeah so as above:
Looks like every time I’ve ‘saved as’ the PO data migrates with the new model rather than duplicating it?
note the file size difference between mainv2 and fork_v3, v3 has way less actual stuff in the RH file:
And it only has a ‘baked’ PO model from GH. @mostapha I can message you both of these files for TS purposes if needed ofcourse
V3 was baked from v2 via GH bake PO model; via internalizing in the _from_RH PO model compo insert spaghetti end of spaghetti–>PO model compo: do bake, the files are contained in the ‘vid about issue’ message dropbox link. #I_break_stuff_good
Hi @tfedyna, sorry for the late reply. I am trying to understand how to recreate this issue on my side:
Are you using GH plugin to read a model from Rhino and bake it back to Rhino?
When I try to use “Save As” the model in Rhino and open it again with a new instance of Rhino. Everything seem working correctly to me.
If I am understanding correctly what you did, then there might be an issue with our GH plugin. @antonellodinunzio might be able to have a better understanding than me. @antonellodinunzio please let me know if you have any insights?
So I baked the model in this file as I needed to do some major simplification to pipe it into WUFI Passive,
The model I baked; while being ID’d as a PO model:
Refresh button etc: it won’t read in all the room names and data on the rhino side nor will the PO Model component read the model into grasshopper again
Hi @tfedyna, until @antonellodinunzio has time to look into it, you could try to use GH to save HBJson file and then import it to Rhino, instead of baking it back to Rhino. This should be able to help you keep working on this model.
To add to @mingbo’s comment - do you delete the original rooms before baking back the new ones? Currently, the Grasshopper bake component doesn’t sync the existing objects. It creates new ones every time.
Hi @mostapha and @antonellodinunzio, has the process for baking Grasshopper models into Pollination improved? More specifically, is there the ability to merge grasshopper rooms with existing?
I am working on a large model where I am controlling the window to wall ratio on one section of the building. Then applying shading to other parts of the building. Struggling with how to merge all the changes into one model again.
Hi, @justinshultz - the process in your Grasshopper script looks good. I imagine the limitation that you currently face is that if you save the model as an HBJSON file and re-open it you will lose the layer information. Is that right? Otherwise, I suspect that your Grasshopper script is making the changes to the rooms successfully.
@mingbo, this can be a good reason to prioritize the implementation of the replace/update model. It was also on my wishlist to be able to use it from the apps (Basecamp Log In). Now we have someone other than me asking for it!
@justinshultz, One [not really important] comment about your Grasshopper script but I can’t help with my desire to teach best practices! Feel free to ignore this. You can use the Gate Not component to invert the boolean values.
We have made some improvements on the Pollination GH plugins since last year, and I think there are a few ways to do to replace the existing model in the Rhino. I just recorded a video to show you how I would do it:
Hi @mingbo, thank you for sharing your workflow and video. Internalizing the room and then baking to rooms is an acceptable workflow.
A feature addition for Bake and Replace would be really advantageous for large models. I am working with a very large model and don’t have a good way to filter the rooms that I’m editing. I selected them individually in Grasshopper using PO_Room > Select Multiple. Deleting them in Pollination Rhino would then require selecting the exact same rooms to delete. A Rhino Layer would help with this a bit but isn’t repeatable if I’m iterating the model import and export process several times. It’s a lot of clicking that Bake and Replace could solve.
Thanks, @mingbo! This is a great option as a workaround, but I think this is something that should be done on the fly. As we discussed before, there are other use cases to have an option for syncing/replacing the model. Basically this!