Workflow for large projects

[Jeremiah Russell]

I'm looking for advice on what the best workflow is for a large multifamily project. The project is 5 floors, 145k+sf. Currently my file is 500mb+ and is seriously killing my computer. It takes forever to do simple tasks. Should I break apart the floors into separate files, then reference them into a master file to pull all my sheets together? Or is there a better way?

 

Thank you!

[Art V]

Referencing is one way to improve operational speed, especially for layers containing quite a few items that rarely change. It may take a bit longer to load the master drawing but it can improve speed.

 

What version of VW are you using and what are your computer specs (processor, RAM, graphics card etc.)? It could be that the hardware is somewhat underpowered. Though at some point things will get slow if you put in enough objects of certain types and much more powerful hardware would not give that much improvement after all.

[zoomer]

Maybe there is some improvement potential in how the geometry is generated.

(E.g. more use of Symbols, deleting Object History, ....)

[Christiaan]

We tend to break up large projects into model file + sheet layer file.

[Chad Hamilton HAArchs]

If there is much repetition in unit types, you might try creating unit types as symbols - this should save crunching geometry.  Another different strategy would be to separate core and shell into one model, and residential units into another.  I'm not a fan of separating models by floor, because then coordination between floors becomes more difficult.

[Diamond]

Yes, large projects can be a challenge to manage. Beyond the software, I find the team is the most challenging part (requiring each team member to put on their big boy/girl pants 😉). Team members will often begrudgingly only use unfamiliar workflows unless forced – but that is all part of going to the next level in their skill level.

 

On 2/26/2019 at 7:44 AM, zoomer said:

Maybe there is some improvement potential in how the geometry is generated.

(E.g. more use of Symbols, deleting Object History, ....)

1. As per Zoomer's comment, invest in your libraries by making sure you are using symbols as much as possible. If you have purely 3D symbol's, convert them to hybrid symbols (or auto-hyrid objects if appropriate0 as much a possible. 3D geometry can slow down redraw times dramatically in Top/Plan views.

 

2. Use saved views to switch between levels and working states. Using the Navigation Palette, and viewport visibility settings is okay for basic switching on smaller projects. But saved view will really switch up your navigation between levels and drawing states (that is, general arrangement plans, RCP's, Floor Finishes, Slab Setout, and so on).  

 

3. Echoing points 1 and 2, as much as you can, turn off 3D geometry, or complex 2D (such as site survey's, and so on).

 

4. Objects need to be classed correctly. One renegade team member can really throw a spanner in the works by using objects assigned to the wrong class.

 

5. Work on your templates and standards. Keep them simple enough for small projects, but be able to import classes and layers from your standard files.

 

On 2/28/2019 at 11:17 AM, Chad Hamilton HAarchs said:

I'm not a fan of separating models by floor, because then coordination between floors becomes more difficult.

I concur.

 

On 2/26/2019 at 10:39 PM, Christiaan said:

We tend to break up large projects into model file + sheet layer file.

Once again, I concur. Although this is an option I would generally only recommend for rendered 3D views, as Saved Viewport Cache can dramatically increase file size.

Alternatively, we tend to break up files into

• Survey, site, + terrain
• Model + plans
• Sections, elevations, + details

 

HTH.

[Christiaan]

Couple of things to bear in mind if you split sections off into a file separate from the model file is that you'll lose the ability to use Section in Place. And in my experience  Section Viewports in referenced files are notoriously buggy.

[Diamond]

5 hours ago, Christiaan said:

Couple of things to bear in mind if you split sections off into a file separate from the model file is that you'll lose the ability to use Section in Place. And in my experience  Section Viewports in referenced files are notoriously buggy.

Yup. And section reference markers. Depending on the project and skill level of the team, we use a hybrid 2D/3D process, so these feature aren't always important.

 

5 hours ago, Christiaan said:

Section Viewports in referenced files are notoriously buggy

I find using layer referencing as apposed to viewport referencing achieves better results for sections and elevations in a referenced file. But then it does bring in all of the resources of the referenced file, and I find stairs linked between storeys can bug out.

 

On the flip-side splitting a project up into multiple files provides some redundancy if a file is corrupted.

 

No one said managing large projects was easy 😉.

 

Hopefully project sharing in 2019 is more robust. We have been having huge challenges with project permissions and changes not being submitted. It can get cray-cray when you have more than ~3 people on the same file. @Christiaan, @zoomer Any suggestions how you manage this?

 

Edited March 5, 2019 by Diamond

[Christiaan]

12 hours ago, Diamond said:

We have been having huge challenges with project permissions and changes not being submitted. It can get cray-cray when you have more than ~3 people on the same file. @Christiaan, @zoomer Any suggestions how you manage this?

 

Yes we run into the odd problem. We will usually create a new project file when we hit problems. One sure way to screw things up, at least when using Dropbox, is for people to do a save and commit and then shut their computer down and go home before it's finished uploading to Dropbox. When somebody else comes in the next day and cracks on with things we've found this to cause problems. So watch out for that one if you're using Dropbox.

[Diamond]

1 hour ago, Christiaan said:

We will usually create a new project file when we hit problems

That is what we have been doing also.

 

Thanks for heads up re: Dropbox. 

[JMR]

One thing we have noticed about project sharing is that it works much faster/better if we don't check out complete DL's, just objects on the fly with the "check out automatically" option checked when prompted.

 

Then releasing the objects via "Custom release" by simply pressing ok.

 

This has greatly reduces save/commit times and crashes.

 

 

 

 

 

[Christiaan]

13 minutes ago, JMR said:

One thing we have noticed about project sharing is that it works much faster/better if we don't check out complete DL's, just objects on the fly with the "check out automatically" option checked when prompted.

 

We've also experienced the other side of the coin on this one, at least when working in conjunction with Dropbox. If your network is congested in any way, say because your internet upload speed is slow or because you're working with large files, Dropbox is slow or you're doing a lot of uploads, then this method can actually be debilitating. You end up with no choice but to sign out whole layers, otherwise you can spend hours in a day waiting for objects to be signed out.

Edited March 8, 2019 by Christiaan

[JMR]

We are only on a local NAS, it's probably very different with a cloud, as you say. 

 

On this setup we don't notice any lags, it's just like working on an ordinary .vwx file after having answered the first prompt. Thinking of all the multitude of issues we had, I'm rather surprised it has worked so much better now.

[Jeremiah Russell]

Thank you, everyone, for your replies and advice. This has been incredibly helpful and instructive. Moving from mostly single family and light commercial to large Multi-family has been an interesting transition. I appreciate all your advice!

 

Cheers.

[Markus Barrera-Kolb]

Looking to pick this thread back up, as we're about to start on a multifamily project comprised of five separate buildings with a total of 52 dwelling units on 4.8 acres. I've got lots of experience using VW for single-family projects modeled in 3D, always in just one file, but in a multi-user environment with a project of this size I assume it's a given that we'll need to split the project up into several files. Similar projects in our office were previously only drawn in 2D, but we'd like to take a BIM approach here. So here are some questions in no particular order:

• If we draw sheets in more than one file, is there a way to pull all the sheet layer / title block information into one drawing index?
• Also if sheets are distributed across multiple files, what's the best way to have the title block graphics & data fields synchronized between all the files? Our office used to just reference a separate title block file and display the graphics in a sheet layer viewport, but that approach didn't take advantage of sheet border & title block functionality.
• Is there a file size / computing load advantage to making repeated unit layouts into symbols rather than multiple (cropped) design layer viewports?
• In a separated core / shell & repeated unit approach, is there an effective way to deal with fenestration? That is, door and window objects would need to be inserted in the shell, but the fenestration locations probably want to be determined by the unit layouts.
• If each building is modeled in a separate file, what's the best way to share / coordinate window & door styles for consistency across the project?

Suggestions on the above and any other pointers are greatly appreciated! Hope everyone is well and healthy during this crazy pandemic...

Edited May 15, 2020 by Markus Barrera-Kolb

[Markus Barrera-Kolb]

...still hoping for some feedback on this topic if anyone has any insights / recommendations on the above points. Thanks in advance, and hope everyone is well!

[DBrown]

On 5/15/2020 at 12:41 PM, Markus Barrera-Kolb said:

If we draw sheets in more than one file, is there a way to pull all the sheet layer / title block information into one drawing index?

I think your only way to do this is referencing a worksheet from a master file

Vectorworks is mostly used in small practices or solo practitioners,  there is few large offices using Vectorworks so there is little to none experience in large projects, even from inside Vectorworks..

[Markus Barrera-Kolb]

Thanks @DBrown — one thing that makes me think VW is intended to accommodate drawings sets spanning multiple files is that when you open the Title Block Manager while more than one file is open, it'll ask you whether you want to load the currently open files along with the active one. This would only make sense if all of those files belonged to the same project. If that's indeed the case, presumably the VW developers have also thought of a way to do a drawing index that includes the sheets from multiple files. Does anyone have any experience with this?  

[Diamond]

Hello @Markus Barrera-Kolb, 

 

I have plenty of experience on these size projects (and bigger – mostly on established education sites, but I started in residential and multi-res). This workflow depends on the experience of the team. I am presuming you are the lead documenter?

 

The size of projects I deal with normally means I am in charge of base build (that is, structure, external fabric, facade, elevations and sections, landscape, and so on). With my base build team (normally one or two others) we divide the tasks up with each responsible for their set of drawings (if you don't make people responsible for their tasks that relate to deliverables, things get missed). Deliverable packages might include – : 

• General arrangement plans.
• Elevations and sections.
• Detailing, especially facade.
• Integrating, interrogating and modelling the structure and mechanical services, and the integrity of the model.

While this is happening we are collaborating with and having input into interiors.

 

Regarding the setup of the Vectorworks model/drawing set – :

1. Regarding referencing, I find layer referencing more stable and reliable, but unless the origins and orientations are set correctly in the building model files, it won't work in your site file (see below).
2. Local Origin points need to be rigorously maintained. Often team members can move them without knowing. Also you need to make sure there are no odd objects way off in space (more than about 5kms away). This breaks Vw' (or any other BIM software's) mathematical engine.
3. I normally treat each building as a separate entity (as the projects I work with are normally staged), with it's own plan/model file with it's own sheet layers (make sure your drawing numbers and deliverables are sorted out first).
4. Each building file uses storeys, and set to correct elevation heights (this keeps the size of each building file down, and only need to change orientation in site model file).
5. If your interiors team is separate, for the sake of ownership and to prevent project sharing clashes, add extra layers per storey for interiors (floor finishes, interiors, ceiling, and so on).
6. Create a separate site/terrain model file.
7. I (design layer viewport) reference the building models into the site terrain model, and rotate to the correct orientation (this can then be used for sun studies, street elevations, and so on).
8. I find hybrid objects such as walls often don't play nice in symbols. Test design layer viewports first.
9. For unit layouts (unless there is a very specific reason) I would keep the exterior walls and base build separate to the interior for each unit. Perhaps you could place where the windows are meant to go on a Guides class, and whoever is doing the facade can place them in the exterior walls?
10. For large projects, I will often use a separate library file that contains all of the latest resources for the project, and reference these into each file. Each project is a bit different, so you need to test as you go.

Hope that helps.

[Markus Barrera-Kolb]

Thanks for all the pointers, @Diamond, and for confirming that others are successfully using Vectorworks for larger projects encompassing multiple buildings. A couple of follow-up questions, if you have a moment:

• Makes sense that you model each building in its own file; do you then create the corresponding drawing sheets in those respective files as well?
• If you do generate sheets within multiple files, do you create your drawing index manually, or is there a way to pull information for sheet layers from multiple files into one index?
• Do you repeat identical interior layouts for dwelling units as multiple copies of design-layer viewports or do you create a symbol for each of these? It makes sense that these would only comprise the interior walls and that the shell would be modeled separately.

Having one dedicated library file also makes a lot of sense; this would take the guesswork out of where to find shared resources... Thanks again!

[Diamond]

1 hour ago, Markus Barrera-Kolb said:

Makes sense that you model each building in its own file; do you then create the corresponding drawing sheets in those respective files as well?

Yes.

 

1 hour ago, Markus Barrera-Kolb said:

If you do generate sheets within multiple files, do you create your drawing index manually, or is there a way to pull information for sheet layers from multiple files into one index?

I had thought the title block object could help you with this. I have never used it as we have used a different system at the day job.

 

1 hour ago, Markus Barrera-Kolb said:

Do you repeat identical interior layouts for dwelling units as multiple copies of design-layer viewports or do you create a symbol for each of these? It makes sense that these would only comprise the interior walls and that the shell would be modeled separately.

You would need to reverse engineer this for what schedules you need to produce on the other end. But once again, use layer viewports inserted of symbols. Or if the levels are the same, why do you need to show anything but the exterior facade? (One plan for multiple levels?).

Okay, for sections I can see why – but create your information once and reuse as much as possible.

Create a typical level design layer that contains a floor layout sans exteriors. Keep each referenced layout (either unit or level made up of units) on their own layer (Vectorworks doesn't like cropping viewports in 3D).

 

Each project requires a custom solution for your requirements. Test as you go.

 

Cheers

[rowbear97]

@Markus Barrera-Kolb

On 6/9/2020 at 1:12 AM, Markus Barrera-Kolb said:

If you do generate sheets within multiple files, do you create your drawing index manually, or is there a way to pull information for sheet layers from multiple files into one index?

When setting up a worksheet criteria you could have the worksheet look at referenced viewports. I haven't done this in a long time as I have moved away from the separate sheet files and design file concept but I recall having that ability. You could also consider referencing other worksheets into your cover sheet and query those references.

[Markus Barrera-Kolb]

@rowbear97 I've so far not been able to reference worksheets from other files, only import, which of course doesn't bring the data over. When I reference a file and then right-click a worksheet in the referenced file, there's no option for referencing (like there is with other resources). Do you have a solution that works for this? Thanks!

[rowbear97]

@Markus Barrera-Kolb I was wrong on referencing the worksheet. And as it turns out my recollection of querying other drawings predated the use of the titleblock styles in 2019. I see in your signature that you are running 2016 so perhaps it will work for you. You need to reference the title block symbol and in your criteria search that symbol name. From there you should be able to get a list.

[Boh]

The title block manager can also create a report of multiple sheets across multiple files.