Jump to content
  • 7

Christiaan

Question

Despite the advent of Project Sharing we still find ourselves (reluctantly) splitting files up in order to minimise memory usage when working in the main model file (and, to a lesser extent, save and commit time). If we weren't slowed down by large numbers of Sheet Layers and Viewports we'd almost certainly keep everything in one file. 

 

So in order to split files up we have to use Workgroup Referencing. But Workgroup Referencing is cumbersome, because the process of editing the model file, then doing a save and commit, then waiting for Dropbox to sync, then updating the workgroup reference is a long one. But the main culprit is the last step, updating the workgroup reference. Because it fetches the entire file every time you do it and locks up VW in the process.

 

So until Vectorworks can handle a large number of Sheet Layers and Viewports without getting bogged down, it would be great if we had a new form of referencing that worked more like Project Sharing:

  1. It would support delta updates rather than having to fetch the entire file
  2. It would have a refresh button like Working Files do
  3. But it would behave differently to a Working File in the that you could create Sheet Layers that aren't pushed back to the Project File

 

VE-101609

Edited by Christiaan
Edit: changed title from 'Workgroup Reference that works more like Project Sharing' to 'Modernise Workgroup Referencing'
Link to comment

15 answers to this question

Recommended Posts

  • 0

Why not go further and just Improve VW ability to scale to larger projects?

It would be great if we could get to point where there is not WRG or Sharing because the system just handles them for you. Every project would have the ability but you wouldn't care till someone needed to be in same part of the file as you and sent you request to take charge of part of the project.

 

Still, in my mind, it would be an advantage if a project wasn't a single entity but was a "file" per layer but in a container that made them look like a single entity.

The system took care of either opening a stack of files stacked on each other if you have write access or as reference viewports if you don't*. Each layer would only need the resources it needs.

 

* this could be determined by things we tell the system anyway to produce output.

 

  • Like 2
Link to comment
  • 0
11 hours ago, Matt Overton said:

Why not go further and just Improve VW ability to scale to larger projects?

 

My presumption is that this is probably a longer term project, over two or three releases, involving many different aspects. Whereas we'd like a fix to this WGR bottleneck as soon as possible.

 

So—absolutely agree with you—but if there's a stepping stone on the way that alleviates this bottleneck in the short term then this could be it.

  • Like 1
Link to comment
  • 0
Posted (edited)

Workgroup References files are like a necessary evil. We can't do without them because our projects are too big to keep everything in one file and yet they're a consistent source of new and old problems/bugs.

 

They either need a good scrub or they need to be scrubbed out and replaced with a modern alternative.

Edited by Christiaan
Link to comment
  • 0

Another reason for modernised WGRing: wall tags don't work.

 

The reason for this is that all objects in referenced layers are deleted and recreated again when updating a reference, so the data tag is unable to know which object was tagged.

 

https://forum.vectorworks.net/index.php?/topic/68686-ability-to-tag-walls-in-workgroup-reference-files/

 

Edited by Christiaan
Link to comment
  • 0

I think it shows, too, because advances in stability and other areas means that we're now seeing WGRing as one of our main bottlenecks.

 

The ability to copy and paste viewports has also made us more willing to split files up and use WGRing because it's now a trivial task to reverse that decision and merge them again if we need to. But things that make it easier to switch to WGRing end up highlighting the limitations of using WGRing.

Edited by Christiaan
  • Like 2
Link to comment
  • 0

Another reason for modernised WGRing: I invariably find bugs that make something look different in the WGR file than in the original model file. If that bug gets fixed, then next time I find something else.

 

One example I've come across this week is the foliage tool. I have a particular hedge type that looks way denser in the WGR file than in the original model, which forces me to move my viewports back to the original model file.

Edited by Christiaan
  • Like 1
Link to comment
  • 0

I have often thought that a fresh approach is needed since there are issues with both protocols, although we have few with referencing that mean we haven’t needed to use project sharing, and from what you’re saying the mixture of the two looks like a bit of a disaster.


I have often thought that it would be interesting to see a software work on the basis of a finder within the software itself.

 

I imagined it would work by defining a directory (much in the same way you define a file in PS) that contains many files and these files would appear in a directory tree within a dialogue within the software that would allow you to reference or work on any file in that tree and the software would

automatically lock the file or treat it as a shared file without the need to announce it as such if you needed to work on it. It would probably need to be backed up by some sort of server application but by defining the directory as the ‘shared’ dataset all referencing and sharing of files would happen automatically without the current system of linking or working in individual files.

 

large files which are far more common in PS are counter-productive. We prefer to keep files small and referencing is great for this.

 

however, if I could simply click on a file to reference it within a defined data set in the same way I might show a layer…, or right click to open it and have it automatically become a file that is shared and can be worked on by many…

 

Link to comment
  • 0
On 10/9/2021 at 8:11 PM, shorter said:

I have often thought that a fresh approach is needed since there are issues with both protocols, although we have few with referencing that mean we haven’t needed to use project sharing, and from what you’re saying the mixture of the two looks like a bit of a disaster.


I have often thought that it would be interesting to see a software work on the basis of a finder within the software itself.

 

I imagined it would work by defining a directory (much in the same way you define a file in PS) that contains many files and these files would appear in a directory tree within a dialogue within the software that would allow you to reference or work on any file in that tree and the software would

automatically lock the file or treat it as a shared file without the need to announce it as such if you needed to work on it. It would probably need to be backed up by some sort of server application but by defining the directory as the ‘shared’ dataset all referencing and sharing of files would happen automatically without the current system of linking or working in individual files.

 

large files which are far more common in PS are counter-productive. We prefer to keep files small and referencing is great for this.

 

however, if I could simply click on a file to reference it within a defined data set in the same way I might show a layer…, or right click to open it and have it automatically become a file that is shared and can be worked on by many…

 

IIRC Nemetschek Allplan works in that way. Each design layer is basically a seperate file. Makes for easier team work, BUT if you switch from one layer to another you loose the redo history, which is a pain in the a*** in my opinion.

Link to comment
  • 0
On 10/9/2021 at 7:11 PM, shorter said:

I have often thought that a fresh approach is needed since there are issues with both protocols, although we have few with referencing that mean we haven’t needed to use project sharing, and from what you’re saying the mixture of the two looks like a bit of a disaster.

All the specific problems with WGRing that I've identified above are strictly WGRing problems; they don't have anything to do with PS.

Edited by Christiaan
Link to comment
  • 0
On 10/11/2021 at 8:40 PM, Christiaan said:

All the specific problems with WGRing that I've identified above are strictly WGRing problems; they don't have anything to do with PS.

 

most of the issues we have had with referencing we have 'managed' out of the system and we learn to be less pedantic about the loss of some functionality, which in some instances is just technology for technologies sake since there is often a simpler, and more efficient way of doing things albeit not according to the Vectorworks 'paradigm'.  Argh!  In fact, referencing often brings in other functionality not possible if you don't use it.

 

if you expect the software to do one thing and that one thing suits you but is not something anyone else would do, is that the software's fault? (and when I say 'you' I mean 'one')

 

the problem with referencing has often been the lack of understanding of how to use it, and what it is for and what it is good at.

Edited by shorter
Link to comment
  • 0
3 hours ago, shorter said:

if you expect the software to do one thing and that one thing suits you but is not something anyone else would do, is that the software's fault? (and when I say 'you' I mean 'one')

 

Sure, but consider the problems I've identified. These are not in that category:

  1. Data Tags don't work in WGR files, so we can't tag windows in elevation views of the model.
  2. Adjustments can be made to gridlines in the Annotations layer of viewports in WGR files, but those adjustments are wiped out when updating the WGR.
  3. Bugs that have no workarounds, e.g. the foliage tool showing denser foliage in a WGR file compared to the original model file.

And it's now my understanding that because of the way WGR works (i.e. deleting and replacing data) we can't expect these issues to be fixed with the current technology (at least not to 1 and 2). So perhaps Matt is right, the solution to my problem is to deal with the speed problems with large files. That may happen quicker than overhauling WGRing.

 

A project I'm working on at the moment weighs in at 2GB if we keep everything in one file (I was working on one last year that would probably be 4GB). But file size is not the problem (in fact it's more space efficient to keep everything in one file); the problem is navigation through layers slows and working with the nav palette and organisation window slows down significantly.

Link to comment
  • 0
39 minutes ago, Christiaan said:

 

Sure, but consider the problems I've identified. These are not in that category:

  1. Data Tags don't work in WGR files, so we can't tag windows in elevation views of the model.
  2. Adjustments can be made to gridlines in the Annotations layer of viewports in WGR files, but those adjustments are wiped out when updating the WGR.
  3. Bugs that have no workarounds, e.g. the foliage tool showing denser foliage in a WGR file compared to the original model file.

And it's now my understanding that because of the way WGR works (i.e. deleting and replacing data) we can't expect these issues to be fixed with the current technology (at least not to 1 and 2). So perhaps Matt is right, the solution to my problem is to deal with the speed problems with large files. That may happen quicker than overhauling WGRing.

 

A project I'm working on at the moment weighs in at 2GB if we keep everything in one file (I was working on one last year that would probably be 4GB). But file size is not the problem (in fact it's more space efficient to keep everything in one file); the problem is navigation through layers slows and working with the nav palette and organisation window slows down significantly.

 

Of course, all tools should work whether referenced or not, and yes, referencing does need an overhaul.  Referencing in VW is different from Mstn, and I am not sure why, but I am pretty sure there are associative objects in Mstn that when you update a reference you don't lose the connection.  Walls and Spaces, for example, would be great in separate files but linked so that when the wall references updated the spaces did automatically.

 

The biggest issue we see with referencing is resource conflict, and in particular now with styles, invisible resource conflict, like the title block record format.

 

The fact that we even get resource conflict when referencing a wall from an IFC model, isn't ideal.

 

Data Tags in Elevation views is an interesting one.  Where are you placing the tag?  Sheet Layer Viewport or Section Viewport in a Design Layer?  Have found that simply identifying the window using it's own tag, is better than a data tag, given all you really need in an elevation is the window number, or do you do something more elaborate?

 

I would be very worried working in a file that big.  And you use project sharing?  How many people on the team are having to download/upload to that and how often do they do so, and how long does it take to save and commit and then refresh?

 

I suppose there are two schools of thought.  You either keep it lean, with more, smaller files, or all in one big file.  We prefer the former.  What would you do if you had to rebuild that file?

 

Our 400,000 sqft BIM is spread over 10 models, weighing in at a total of 600Mb, with no file bigger than 200Mb.  When combined into one model they are 200Mb.

 

 

Link to comment
  • 0

 

13 hours ago, shorter said:

The biggest issue we see with referencing is resource conflict, and in particular now with styles, invisible resource conflict, like the title block record format.

Yeah, we don't experience this anymore because we almost exclusively use the layer import method. With Project Sharing we don't find ourselves using the design layer viewport method. 

 

13 hours ago, shorter said:

Data Tags in Elevation views is an interesting one.  Where are you placing the tag?  Sheet Layer Viewport or Section Viewport in a Design Layer?  Have found that simply identifying the window using it's own tag, is better than a data tag, given all you really need in an elevation is the window number, or do you do something more elaborate?

We use Sheet Layer Section Viewports for our elevation drawings and we're placing the tags in the Annotation layer of these, which at first is fine in a WGR file, but when you update the reference the Data Tags no longer know what object they were tagged to and go blank. The new Data Tag is superior in many ways and there are quite a few problems associated with the legacy window id and 3D model elevations:

  1. They get hidden behind other objects (e.g. columns); and you can't adjust their position individually
  2. They become difficult or impossible to read if the window is not at right angles to the elevation (e.g. a triangular bay windows, or part of the building that is not at right angles)
  3. They're rastered images rather than crisp font
  4. You can see them edge-on at the flanks of an elevation and have to use elaborate Classes to be able to control visibility (the more complex the building shape the more elaborate the Class scheme becomes)
13 hours ago, shorter said:

I would be very worried working in a file that big.  And you use project sharing?  How many people on the team are having to download/upload to that and how often do they do so, and how long does it take to save and commit and then refresh?

That's only how big it is if we keep everything in one file. In practice we divide up into multiple files—generally drawing groups (floor plans, sections, etc), using Layer Import WGRing. And anything that's incompatible with WGRing (e.g. window tags in elevation) we keep the associated sheets in the model file (which increases the size of the model file and interrupts the logical grouping of sheets into drawing groups).

 

13 hours ago, shorter said:

I suppose there are two schools of thought.  You either keep it lean, with more, smaller files, or all in one big file.  We prefer the former.  What would you do if you had to rebuild that file?

Yes, I'm easy either way—maybe leaning toward a single file because it's less to manage—but in practice we're forced to split the files up. How do you mean rebuild it?

 

13 hours ago, shorter said:

Our 400,000 sqft BIM is spread over 10 models, weighing in at a total of 600Mb, with no file bigger than 200Mb.  When combined into one model they are 200Mb.

We make use of shaded/openGL elevations these days, even for some construction drawings. And we use renderworks elevations for planning conditions for instance. These would normally be in a separate WGR file but we had an issue with the foliage tool (as mentioned above) so we keep them in the model file too. So these contribute quite a bit to the size of the files. Our model file was about 600 MB, but with all elevations (including for planning conditions) it now weighs in at 1.5 GB. Our floor plans file weighs in at 440 MB. 

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Answer this question...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...