generative modeling for Rhino
This topic doesn't necessary need to involve grasshopper but i was hoping you guys could help me out a little. In most projects multiple people work on the same Rhino model which causes a lot of different variants. (for instance final_model01.3dm, FINAL_final_model01.3dm, THIS_IS_THE_REAL_FINAL_MODEL_model034.3DM etc. etc.) Probably you already understand where i´m going with this.
I was wondering if there is an easy way to have one masterfile and have multiple users edit this file, without having 10 versions. This causes besides frustration a lot of extra work sometimes, because people working in the wrong model and doing stuff double or deleting stuff that was not meant to be.
I was thinking of setting op your masterfile with block instances. Like roof, facade, construction, context etc. and making different files for those and let them load into the masterfile.
I don´t know if this is the smartest way or maybe there is another method.
Please let me know how you deal with this or what suggestions you might have.
Have a look at the Rhino Worksession Manager...
Manages a list of models that can be used as reference geometry.
The Worksession command lets many users work on a large project by breaking the project down into many files. Each user can edit a different part of the project and see the related portions of the project simultaneously. By refreshing as needed, each user can see the current version of the related portions of the projects. Only one user can have a file open for editing, but many users can see it.
The attached file can be in any format that Rhino can import, not just Rhino models. Attached geometry cannot be edited (Move, Scale), but it can be used for input to creation commands (Copy, Extrude).
The attached file geometry appears on a unique set of layers under a parent layer with the name of the attached file, and the attached file layers as sub-layers of the parent.
You can change the layer state of reference layers (Color, On/Off, Locked, Print Color, Print Width, Linetype), but you cannot add new layers to or delete layers from the attached file. The list of attached files are not saved in the current model file, but are saved in the worksession file (.rws).
i feel kinda stupid for not figuring this out by myself :)
Grasshopper behaves somewhat different than most programs when it comes to files. When you open a file a program typically locks that file, so nobody else can change it. Grasshopper doesn't. I don't really have a good reason for not doing this, maybe I should be locking.
The biggest danger here is that's now quite easy for multiple instances of Grasshopper to open the same file, and whenever one of them saves, it will undo the changes saved by the other and vice versa.
Locking will stop this from happening, but it won't solve anything. Any ideas about how to make it so that multiple people can work on the same *.gh file are welcome.
But wouldn't you ultimately want the changes from user A and B apply to the same file? Putting multiple files into a single *.gh blob doesn't accomplish much more than just having multiple files to begin with.
The biggest problem is always merging changes from multiple users. We (McNeel) use Tortoise SVN to manage source code. Every developer has complete source on their machine, and when they change their local copy, they need to 'check in' the changes to the central repository. You're not allowed to check in files if someone else has updated the file since last you 'synched' with the server. You have to first get the changes from the server and then the source code is merged on your local machine. The source merging algorithm in Tortoise is pretty good, it rarely chokes.
Unfortunately I cannot use a similar approach to Grasshopper files. The gh and ghx files are too fragile (if that's the correct word for it). Just combining two files in all likelihood will not give you a valid result.
This is how I imagine it should work, when two or more people work on the same file. Everything is the same as it is now, except maybe I'll lock the file, to avoid people overwriting it in turn. Then there's an option to 'lock' part of the file. Say you want to work on only the facade, you don't care about foundation. So you select all components that are important, and you request ownership. Anyone else who now opens this file, will see those components locked and won't be able to change them. When User B saves her part of the file, everyone else who has that file open will see that there's something to update. Ideally I'd even like to see a way to talk to User B using some form of in-program chat, so you can ask relevant questions.
All this stuff is pretty complicated, especially when Users A and B are on a network.
Now I'm thinking what if 1=foundation , 2=floor 1, 3=roof. So consider each of the 3 built as a cluster. There is a master file that when opened simply shows 3 clusters connected. User B opens the master file and notices that there is a lock on cluster 2, when hovering over it it says User A has it opened and maybe has a back log of recent saves. so user B goes to work on cluster 3, he clicks cluster 3 and it's contents explode outward revieling the definition of the roof. Now in User A's file cluster 3 has a lock on it. User B finishes and saves and closes an the definition folds back up into cluster 3 and now cluster 3 in user A's file has an update symbol. User A clicks it and now the roof is updated in user A's file.
ithink this is a really good idea, i will like to have an open file betwen two or more users and be able to changue it in turn, save mode must be validated and save as can make a copy appart, this can be great for teaching-learning process
is there a way where i can see what the other user are doing in the file, i mean putting components and wire them in the definition?