The Grand Secrets of PLOT FILES

[Gregovitch]

Morning experts,

 

I have done some reading about VWX and big files and how to makes them lighter and easier to handle. A lot of time I have stumbled on the words: "Plot file/ Production file", funnily enough it explains a concept but only vaguely.

 

It comes with the idea of having separate type of files:

1. DESIGN FILES, where you have all of your designs It can be split in multiples file for example (exterior walls, core, units, structure,...)
2. PLOT FILES, where your references all of those design files and do the annotation/sheet layers in it. It seems those can also be split per document type (Plan, RCP, Sections, Elevations,...)

 

I am trying it out on a building project, and do start to see some great improvement:

• The design file does not have any sheet layers anymore, making it 1/3 of it's original size
• The sheet file also gets a good lift because it doesn't need stories, not as much design layers and way less classes. 

 

I am stumbling on some issues, and this would be the size of my exported PDF that have tripled it's size: a dashing 4.6 MB for a simple plan (previously 1.4 MB when everything was not split)

 

I have tried to find some more detailed on the how to correctly set up plot files and could not find anything anywhere.

 

Does some of you have knowledge on this? Any advices?

 

Thanks

Edited November 17, 2021 by Gregovitch

[Boh]

This is an interesting idea and one I haven't tried out myself. I'm sure there are others out there that work in this or a similar way who could provide some advice.

 

I am wondering though if the plot files would be able to "read" data attached to objects in the design files? Can data tags in a plot file viewport annotation attach to an object in the design file? Can worksheets in the plot file report on items in the design file?

 

Would referenced design layer viewports be used or old style layer referencing. If old style design layer referencing needs to be used to read data then does it save much in file size?

 

What are the advantages with this if there are multiple people working on the project? I guess one person can be working in the plot file and others in the design file(s).

 

[Christiaan]

1 hour ago, Gregovitch said:

The sheet file also gets a good lift because it doesn't need stories, not as much design layers and way less classes. 

Be careful with that one. I've found that I had to set up all my storeys and levels in the referenced files to ensure everything comes in at the right heights. I exclusively use Layer Import method for the referenced files though.

 

 

[Gregovitch]

2 hours ago, Boh said:

am wondering though if the plot files would be able to "read" data attached to objects in the design files?

We do data tags and worksheets in the Design file. We do keynotes and dimensions in the plot file. 

 

2 hours ago, Boh said:

Would referenced design layer viewports be used or old style layer referencing. If old style design layer referencing needs to be used to read data then does it save much in file size?

I am quite new in VWX so I am not sure which type of referencing I did. I created a viewport from the view menu and asked it to be an exterior source. I am interested into learning how to do it other ways and figure out what would be the best practice for this. I guess that the other way is what @Christiaan is referring to. 

 

2 hours ago, Boh said:

What are the advantages with this if there are multiple people working on the project? I guess one person can be working in the plot file and others in the design file(s).

Everybody has their file no need of shared project file. We had a lot of issue when we where multiple persons working on on document (wall, doors, windows, line and a lot of random stuff disappearing).

[twk]

We had thought about this workflow in the past but never went this route after project sharing came in. Ever since project sharing was announced we have been using it (together with all its issues). There were more cons than pros with using the WGR(Work group referencing, either via Viewport or Layer Import) method or splitting the project into PLOT and MODEL(Design) files. Eg's

1. WGR explicitly splits the tasks for a project. A single user working on the PLOT file must wait for the work in DESIGN file to be completed, update the source, then publish. Upon seeing any mistakes, must then work on the DESIGN file, save, refresh in PLOT file, then publish. It is an 'old style' of project sharing, and works, however on larger files, having to wait for the DESIGN file reference to update can eat up time. With project sharing we've noticed, comitting/refreshing takes much less time, even quicker on VW 2021.

2. Data tags, section-to-viewport referencing do not work with WGR

 

With Project sharing, having everything in a single file just makes it easier to manage things. Like classes, saved views, detail marker to viewport referencing, titleblock revisions, storeys, etc. HOWEVER, for it to work, it requires ALL users to understand the problems with it to properly troubleshoot and possibly avoid them all together, they include:

1. Avoid save and committing at the same time as other users

2. After every save and commit, confirm that you're changes are saved. Either by opening a fresh copy of the project file, or asking a coworker to refresh to check if your work has been committed. 

3. Save and commit a the end of the day, unless necessary. 

4. If/When the file crashes during committing, always check project file first to check if your changes have been committed. Sometimes they have, and committing from a crash file will corrupt the project file. If they haven't and your locked out because the project file thinks you're a new user/opening a new working file, get the admin to release your work and manually copy in your work from the crashed file.

 

We fought with project sharing since its inception, but the benefits outway the other workflows, we've found.

 

With regards to PDF sizes, the following option seems to help:

4 hours ago, Gregovitch said:

I am stumbling on some issues, and this would be the size of my exported PDF that have tripled it's size: a dashing 4.6 MB for a simple plan (previously 1.4 MB when everything was not split)

 

 

 

[Christiaan]

9 hours ago, twk said:

We had thought about this workflow in the past but never went this route after project sharing came in. Ever since project sharing was announced we have been using it (together with all its issues). There were more cons than pros with using the WGR(Work group referencing, either via Viewport or Layer Import) method or splitting the project into PLOT and MODEL(Design) files. Eg's

1. WGR explicitly splits the tasks for a project. A single user working on the PLOT file must wait for the work in DESIGN file to be completed, update the source, then publish. Upon seeing any mistakes, must then work on the DESIGN file, save, refresh in PLOT file, then publish. It is an 'old style' of project sharing, and works, however on larger files, having to wait for the DESIGN file reference to update can eat up time. With project sharing we've noticed, comitting/refreshing takes much less time, even quicker on VW 2021.

2. Data tags, section-to-viewport referencing do not work with WGR

 

With Project sharing, having everything in a single file just makes it easier to manage things. Like classes, saved views, detail marker to viewport referencing, titleblock revisions, storeys, etc. HOWEVER, for it to work, it requires ALL users to understand the problems with it to properly troubleshoot and possibly avoid them all together, they include:

1. Avoid save and committing at the same time as other users

2. After every save and commit, confirm that you're changes are saved. Either by opening a fresh copy of the project file, or asking a coworker to refresh to check if your work has been committed. 

3. Save and commit a the end of the day, unless necessary. 

4. If/When the file crashes during committing, always check project file first to check if your changes have been committed. Sometimes they have, and committing from a crash file will corrupt the project file. If they haven't and your locked out because the project file thinks you're a new user/opening a new working file, get the admin to release your work and manually copy in your work from the crashed file.

 

We fought with project sharing since its inception, but the benefits outway the other workflows, we've found.

 

With regards to PDF sizes, the following option seems to help:

 

 

 

We actually combine both methods on larger projects. But only out of necessity; one project we're working on is a sluggish 2GB file if model and all sheet layers are combined. Another we were working on was even well beyond this because of a number of Renderworks sheet layers. So we split the project up into a model file and sheet layer file(s), and we make all of these Project Files. All via Resilio file syncing. The benefit of this is that you get Project Sharing's multi-user management of the WGR files. 

 

One caveat is that we keep any sheet layer viewports in the model file if they require features such as Edit Section-Place (so sections), or ID Tags (so elevations), or if we run into bugs like a recent one where the foliage tool produced less dense foliage in the WGR file. However now that we can copy and paste viewports across files it's very easy to shift them around. So for instance I kept the sections in the model file while we were working on them and then shifted them to a WGR file once they were completed. The elevations, with their window ID tags, have to remain in with the model file however, because the ID tags break as soon as you refresh a WGR file.

 

But our preference is to keep everything in one project file. We have a four-unit residential project we're working on that works just fine like this, and I've even modelled all the bathrooms in 3D for interior elevations.

 

The bigger schemes mentioned earlier are complex 30 unit and 140 unit schemes.

Edited November 18, 2021 by Christiaan