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
Also the baked model:
(Cant seem to figure out how to get the PO RH manager to populate?)
This is an interesting one for @mingbo to have a look at. Can you provide more information about how you created V3 from V2? Is it only a simple SaveAs?
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 
@mingbo hello! I just wanted to see where this all landed if you happened to have time to take a look
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.
I fortunately have numerous copies of the model, so alls well: I found a “Checkpoint” I saved and stashed in a folder so I’m on track.
AHHH That’s good to know about the current Gh bake:
I did not delete the OG rooms fortunately; tho I did internalize and bake to a clean Rhino file
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, we don’t have a here native workflow but if you provide a small example that explains the problem I can show you how to deal with this using a few lines of Python.
I am not able to share the Pollination model but the Grasshopper script will show the workflow I’m applying.
20221005 Add Windows and Shading to Tower_ForShare.gh (426.9 KB)
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.
Yes, it’s a working method. I agree, a replace/update model would be much easier though! I second this request @mingbo!
Good to know! I was not aware of Gate Not thank you for showing me.
Thirding that request 
Will make inevitable pollination based inter-disciplinary colab awesome!
also… some git features feel like they may be kinda topical soon 
Hi @justinshultz, and @tfedyna,
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:
Please let me know if this helps.
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! 
