FredoConnect: Can several users work concurrently on the same model?

[Fredo6]

Can several users work concurrently on the same model?

I have been exploring the technical feasibility for a team to work concurrently on the same SketchUp model. So basically 2 actions: Publish and Update.

I quickly assembled a proof of concept, FredoConnect, based on the following framework:

• Team members have each access to a shared directory , whether on a true office shared drive, or a fast replicated local folder (ex: via Google Drive). The path to the shared directory is declared on each computer. This solves the issues with relative paths.

• Team members always work on a local copy of the model on their own computer . They can make modifications to the model by any tool of their choice (native tools, plugins, XRef replication)

• Team members can publish the changes they made to the model. No need to specify what has changed.

• Team members can update their local copy of the model with the changes made by others. No need to specify what must be updated.

• There are specific rules on the geometry of the model:

  • Synchronization applies to Components and Groups . So, you are not forced to work only with components.
  • Adding, modifying, deleting Guides Lines or Guide Points is not considered as a change . Furthermore, Guides are not transferred to the published versions.
  • Raw geometry at top level of the model is ignored and not considered as a change if it is present and modified. Only the top-level groups and components, as well as their position, do matter.

• A Touch and Lock mechanism is implemented in order to:

  • Detect what is modified, when and by whom
  • Detect conflicts (2 members modifying the same object concurrently)
  • Lock / unlock objects

The videos below illustrate the concept.

- YouTube

HOWEVER, before I continue with the approach, I am interested in hearing from users whether this corresponds to an actual workflow in the real world, versus other methods of sharing a model among a team.

Indeed, additional features can be added, just a matter of UI more than technical difficulty:

• Sharing scenes and styles between members, while letting each one have their own environment
• Visual communication (bubble, etc…) to share comments and to-do lists about the model.

[ch3ck5ix]

WOW!!!
I thought your FredoXREF was a gamechanger for our office workflow (we are currently in the process evaluating the beta version with the intent of revising and incorporating it into our standards and procedures). But this is something else… another level of awesomeness! With FredoConnect I believe it answers some of the limitations of our current workflow especially at the model creator level but also between disciplines (architecture, interior design, engineering, etc.) within our organization. I think the best part of this extension means no more waiting and more productivity.

How do you envision this working with FredoXREF? I am not so concerned with multiple users working on SU files that are located within our local network accessing the file server but am worried if the file is accessed remotely and the connection is disrupted (i.e., file locking, data corruption, etc.). We do not use cloud storage for work files (only for back-up or file transmission) due to previous problems with file access, corruption, management, etc., but I’m sure this will be of concern to others. Also, I think having a Visual Communication feature would be great – no more yelling over the office cubicles or impromptu work disruptions.

Anyway, THANK YOU Fredo for another awesome extension! You already made my week and it’s only Sunday here…

[rtches]

Congratulations @Fredo6 . I think it could be a perfect environment to collaborate in Bim Projects as other modelers do.
Have you tested with big models? I mean with hundreds of components nested between 3 or 4 levels of hierarchy?
Maybe trying the Speckle project can help you to find ideas for your plugin.

[JQL]

If it works it’s huge. There’s no workflow like this that I know of yet, for SU, so I would have to try and see if it’s useful. It might fail by not so obvious reasons or because of simple sync issues. It it’s flawless and seamless, I think it’s a game changer.

[Fredo6]

I am not too much worried by performance. As said, each team member works on a local version of the model. It is only at Publish and Update that part files are copied over from or to the shared drive. For touch and conflict management, only small text files are accessed periodically on the shared drive; so, not a huge traffic.

By the way, the approach could be applied to a remote server rather than a shared drive. This is independent from the FredoConnect algorithm. In this case, we’ll have to replace the file access by some download / upload for files and some Http queries for managing conflicts.

I also made a quick test with a larger model of over 1,100 groups and components and it behaves fine (see video).

The main issue is actually to make sure that the substitution of groups and components at Update does not break the functioning of plugins (among which XRef). I also have to closely look at many cases related to undo/redo, revert model, error management and weird behaviors of the API (and users).

This is something that will take time to verify, but before, I was wondering whether FredoConnect was just a nice idea, but without real applications, just because collaboration and model sharing are done differently by professional practices.

Also, FredoConnect is bound to Sketchup models. Forget managing CAD bits and other 3D formats, which are the goal of Trimble Connect, Speckle and alike. The main difference however is that these powerful tools are more for project consolidation that for joint design work. FredoConnect gives certainly a lot more freedom and requires less planning in task assignment, so the purpose is different.

[maxB]

Wow - it looks like a really useful plugin. I can imagine offices where multiple people work on a project at the same time would be really really happy with this.

I could see some challenges with nested models and people doing ‘unwanted things’ like changing the pivot of a component, changing material attributes, renaming objects etc but all that could (should) be discussed internally in those offices as rules how to not-break the plugin.

Hats off to you for thinking about this and actually making this.

[ch3ck5ix]

@Fredo6 I brought up FredoConnect in our Monday morning coordination meeting and it piqued a lot of interest. Aside from the technical aspects, there was consensus that concurrent work on same SU models would be extremely beneficial.

Currently with SketchUp projects, we’ve had to implement inconvenient procedures to access files, ensure validity, reduce conflict, etc. (this is done by having “work” models on separate folders from the “published” models which are then referenced by different disciplines working on their own “piece of the puzzle”.

I think between FredoConnect and FredoXREF these extensions will definitively change and streamline our workflow. If I understand the concept between these two extensions for our workflow, FredoConnect could be used at the base level modeling for collaboration (though I can see it doing more than that) and FredoXREF would be used to assemble different SU models into what we call a “composite” model (we actually have several different types of composite models depending on what is being published in Layout by each discipline). Note that we do this to prevent unnecessary bloating of the composite SU models: this is true for our interior designers where they love using highly detailed SU components (though we have “special” procedures for them).

Anyway, I’m super excited and hopeful for FredoConnect (and FredoXREF) and encourage you to continue development. Best regards and thanks for what you do for the SU community.

[Fredo6]

Thanks for your encouragements. I appreciate.

FredoConnect and any XRef method overlap and thus clash, because they both include mechanisms to publish and update objects. This is not just FredoXRef but any method of XRefing, whether native (save-as + reload) or other XRef plugins.

The reason is that if you update an XRef component via FredoXRef in a shared model, FredoConnect will take it as a change (not an update) and therefore proposes you to publish it. If another team member does the same (i.e. updating via FredoXRef) in his own copy of the shared model, this will be create a conflict, since both members change the same object.

The normal way to do it with FredoConnect is that only one user uses the FredoXRef updating, and publishes via FredoConnect. Other team members will then get the change via FredoConnect synchronization. But then, this somehow defeats the interest FredoXRef (or other XRefing methods).

The point here is that:

• FredoConnect is actualling doing XRefing, but IMPLICTELY (you don’t have to specify the file name and location)
• FredoXref does it EXPLICTELY, and the XRef external model must have a name and a location somewhere that all team members should know.

if XRef is only used for editing in-place within the big model, then FredoConnect is a better solution. It’s fine to use XRef as an editing tool by individual members in charge of one domain, but then, it is more in the scenario of using libraries of objects and editing the objects in separate models rather than editing in-place within the shared model.

Also, XRef methods have a problem to synchronize components where the container is managed by one user and the objects contained by another one. Say,

• Mr. Blue works on the furniture, chair and table
• Mr.Yellow works on the arrangement of furniture, position and number of chairs and table.

With Xref methods, Mr Yellow locks both the container of furniture and the chair and table, which are nested inside, preventing Mr. Blue to work on the indivdiual chair and table concurrently.

With FredoConnect, each team member can work separately on them, as shown in the video (noting that the objects can also be groups, not just components).

At this stage, the feasibility of FredoConnect is not yet demonstrated. I just have a proof of concept. But, clearly FredoConnect and Xref won’t go together (again, not just FredoXRef). Most likely, FredoConnect would have to include a feature whereby you can explicitely work on a local copy of sub-model (and lock it), with a Publish button to trigger the update in the shared model by other members.