Autocad (2020 I think) added feature where you could diff files and see changes (green: added, red: deleted, yellow: modified etc.), which sounds like an apt base for version control. It wasn’t that advanced though.
What do you think about doing this in Rhino as well? Namely, I see a story like this - I git pull Rhino master file, git checkout a new branch where I make my changes and then sync it back with a pull request (or commit to master like a real deal).
I think this would be awesome for architecture firms. Leveraging Rhino’s speed working in 3D with some “BIM” let’s say workflow.
Rhino file format is a binary format, regular diffs won’t work that well in this case.
If you are really concerned about the change history you’d best create a solution with some sort of database behind that can look into the files and determine from that structure what has changed and how.
Thanks for the insight, but if AutoCAD could do it there should be some hope for Rhino as well, no? For example, using rhinocommon to take a snapshot of all the objects in a Rhino document and then compare them to their next state when a user saves/commits the file. Put this way it does sound like a larger task, taking care of all the possible exceptions and edge cases, unless there is some smarter way to go about it?
This is one of the goals of the viewer that I’ve been working on
Right now it can open two models and provide a few different ways to visually diff the model. I’m hoping to eventually hook this up to the github api so those two models could be different versions of the same file in git.
That’s amazing! Are you planning to add more editing capabilities there as well? The viewport feels incredibly smooth, it would be great to have a Rhino Web App.
I think this kind of version control would still come in handy on the desktop app, as well.
Not to be discouraging, but that’s not really a basis for version control, like it’s maybe part of it but it’s like a slice of a slice of the problem. A lot of important changes you want to track as different versions, they’re’ not going to show up with such a tool, not usefully anyway. A lot of what you need to keep track of isn’t even IN the model, so…where does that data live? In the Rhino files or the database? That’s just one of the 2000 questions to answer.
It’s a topic I’ve had an interest in for a long time, done some experiments and mockups, and…yeah seriously attempting something that could be used in a collaborative environment requires…well there are people here who have built entire Rhino-centric workflow systems, and it requires several dedicated staff to develop and maintain.
No worries, the minimum of version control that I think would work for me at least is just the ability to work concurrently on the same model/3dm file and being able to merge those changes with any remaining conflicts left for review. Anything but locking the file…
I think simple trunk-based development even without keeping a history of versions would make a big difference already.
I’m not quite sure what you mean? Why data wouldn’t be in the model?
That’s interesting, can you name any specific team, which tried to do that? Is there anything published from their work? That would be really interesting.
At this point it is simply a viewer and there is a ton of work to just get that task completed. I use it to make sure the javascript version of our rhino3dm library is working properly.
