Why am I using separate files?

[Christiaan]

Following various advice on BIM best practice I've been setting up a project involving two buildings with a separate file for the site model and separate files for each of the two building models. All origins are synced across files (I'm using rotated view to work on the models) and I've managed to use Layer Import mode when referencing by having unique names for Design Layers + Story Names and Prefixes across the project. 

 

But workgroup referencing is bringing with it a whole host of trouble-shooting problems (and another [long] step in the file-save process). I find it very buggy. Which begs the question: why am I putting my building models (and sheets) in separate files?

 

I would rather work in a single file for a host of reasons (including being easier for my colleagues to manage). Vectorworks can easily handle a project this size (two houses with 4 levels). And in terms of collaboration with other consultants, it doesn't matter that I have separate files or not does it?

 

Convince me. @shorter?

[shorter]

🙂 which ever way you do it, @Christiaan you will never be satisfied.

[Christiaan]

Haha, fair enough 😆

[shorter]

Current projects include a 400,000 sqft model segregated into multiple models assembled into one to print and to export.

 

an eight building project with 6-8 floors shared with three other architects all on vectorworks split by building and architect.

 

large hotel project with a team of 5-6 architects similarly segregated.

 

just about to embark on another 8 building project…

 

these are all 3D. Projects were even bigger and more complex in 2D. No problem with wgr.

 

personally I think there is a limit to PS, not because of the software or the technology but due to the inability of people to keep their files clean and disciplined.  There is therefore more mess in one file and that has to be a problem ultimately and back in the day we spent most of our time unpicking the various layers of user idiosyncrasies to even print the latest drawing from those ‘single files’.  I would hate to go back there.

that fact that we don’t generally have problems with referencing is due to the way we set things up and manage things. There are rules and it will

break if you don’t follow those rules so we make sure the rules are followed.

 

it is though a matter of preference. PS works for you. Great. WGR works for us.

 

it gives us a simple logical system that makes it easy to manage all aspects of the delivery of drawing, schedule and model.

Edited March 2, 2023 by shorter

[shorter]

I should also add ‘it’s also a state of mind’ thing

[shorter]

By the way, we are seeing similar setups in Revit in order to speed up the synching process but also keep file sizes down to project BEP limits.

 

I watched a practice using PS the other day and a small model, perhaps 50mb saved in Dropbox.

 

the time lost waiting for the files to save and commit and then refresh must add up.
 

we have heard of models taking so long to open even that everyone working on the model comes in early, open the model go and have breakfast and come back to the office to work.

 

how can that be efficient?

 

they are wasting hours.

 

all in the name of BIM

 

i would rename your post ‘still have all your eggs in one basket?’

 

😉

[Jeff Prince]

47 minutes ago, shorter said:

we have heard of models taking so long to open even that everyone working on the model comes in early, open the model go and have breakfast and come back to the office to work.

 

Reminds me of the old pen plotter days 🙂

Print a sheet of details... enjoy a 2 martini lunch.

 

Once you get burned having all your eggs in one basket...

hosted on the cloud...

people return to the tried and true methods.

[shorter]

1 hour ago, jeff prince said:

Reminds me of the old pen plotter days 🙂

Print a sheet of details... enjoy a 2 martini lunch.

And come back to find the pen ran out of ink…

[Jeff Prince]

11 minutes ago, shorter said:

And come back to find the pen ran out of ink…

and tore the vellum or gouged the mylar as it skid across the media without ink...

[Christiaan]

6 hours ago, shorter said:

the time lost waiting for the files to save and commit and then refresh must add up.

That's how I feel about updating WGRing. And WGR is like a box of chocolates. You never know what you're gonna get.

[shorter]

8 hours ago, jeff prince said:

and tore the vellum or gouged the mylar as it skid across the media without ink...

Halcyon days!

[shorter]

4 hours ago, Christiaan said:

That's how I feel about updating WGRing. And WGR is like a box of chocolates. You never know what you're gonna get.

sort of but you got to know how to always get the purple one.

[Christiaan]

One reason I've found to keep the buildings in separate files is that it makes it straight forward to generate and update a VGX view on VCS for each separate building without the site.

[Barb S.]

I have started at a new firm, and starting to use Vectorworks after coming from an Autocad background for 30+ years. This firm does all 2D and ALL drafting occurs in the "paper space/plot sheet" file. So, no viewports, etc. The boss finds its easiest for coordination to keep all drwgs. in 1 file. Drawings are not linked to each other and therefore when making a change on 1 file you need to remember to follow through in other drawings/update "manually". Thoughts on pros/cons?? I'm used to xrefs and viewports in Autocad where you "automatically" see changes and then can update as nec. Also with this new method details are drawn separately at a larger scale and if original base changes and affects the detail, you need to remember to update the detail.

[Matt Overton]

4 hours ago, Barb S. said:

I have started at a new firm, and starting to use Vectorworks after coming from an Autocad background for 30+ years. This firm does all 2D and ALL drafting occurs in the "paper space/plot sheet" file. So, no viewports, etc. The boss finds its easiest for coordination to keep all drwgs. in 1 file. Drawings are not linked to each other and therefore when making a change on 1 file you need to remember to follow through in other drawings/update "manually". Thoughts on pros/cons?? I'm used to xrefs and viewports in Autocad where you "automatically" see changes and then can update as nec. Also with this new method details are drawn separately at a larger scale and if original base changes and affects the detail, you need to remember to update the detail.

Wait so basically just an electronic drawing board?

 

[shorter]

16 hours ago, Barb S. said:

I have started at a new firm, and starting to use Vectorworks after coming from an Autocad background for 30+ years. This firm does all 2D and ALL drafting occurs in the "paper space/plot sheet" file. So, no viewports, etc. The boss finds its easiest for coordination to keep all drwgs. in 1 file. Drawings are not linked to each other and therefore when making a change on 1 file you need to remember to follow through in other drawings/update "manually". Thoughts on pros/cons?? I'm used to xrefs and viewports in Autocad where you "automatically" see changes and then can update as nec. Also with this new method details are drawn separately at a larger scale and if original base changes and affects the detail, you need to remember to update the detail.

 

@Barb S. The equivalent of xrefs (both attachment and overlay, though only simultaneously if you use 'layer referencing') are possible in vectorworks architect, and highly effective and efficient means of reducing the overhead you describe of chasing your tail when information changes on many drawings.

 

Xrefs (the process is called 'workgroup referencing' but I will refer to it as 'xrefs') will always be necessary and recommended for coordination with consultant data (you should never import a dwg directly into a live VW file), or for refering to survey data, etc, as well as working between large scale plans and details.

 

Xrefs can help keep files sizes down which is something that should not be underestimated as a critical factor in the efficiency of any cad system not to mention reliability.

 

Xrefs like autocad are the glue to an efficient cad system, but there are 'idiosyncrascies' you need to be aware of.

 

Xrefs can help manage many things too, like symbol (i.e. block) libraries, graphics via the equivalent of pen and style tables which includes hatches and line types, notes databases, and of course 2d and 3d data.  There are some notable exceptions like the inability to update data visualisation settings via referencing or saved views or class and layer filters... one day, perhaps.

 

Xrefs help enforce spatial coordination but take care if using design layer viewports as they can be moved and often move of their own accord if the coordinate system of the files have not been set up correctly and consistently throughout the dataset.

 

Some find systems using xrefs 'complicated'.   This is usually because there has been no strategy, no structure to the dataset, and no patience.  I recall seeing someone present at a conference and judging by the diagram they presented of their 'structure' I am not surprised they had problems.  They singularly failed to understand what xrefs were for.

 

Coming as I do from a microstation background, discipline was drilled into me from an early (cad) age.  You need rigourous cad standards, and folder structures, and protocols, and you need to stick to them.  This is true of all efficient cad systems, though this in turn can be a bone of contention with other members of staff who may have their own way of doing things, and things tend to go awry if staff do not follow the script, so management, monitoring, and maintenance (my 3 'ms') are essential.

 

We have been training and supporting architects for many years, and have used xrefs in anger in vectorworks since they were introduced in Vectorworks 8 (?).  We have helped large teams deliver huge projects with great efficiency (I have been quoted by one client that they deliver projects 40% more efficiently using my 2D system than when using BIM, over 300% more efficiently than old school drawing board approaches, and in one case 15x more efficiently versus an unstructured approach using design layer viewports...).  In short it is perfectly possible to use Vectorworks on projects usually only considered possible using Microstation or AutoCAD but only if the approach is right.

My advice would be to set up a system as you would in AutoCAD, and if you have any problems, or would like me to review what you are proposing, to give me a shout.

 

Sorry if the above looks like me blowing my own trumpet, but I am in effect giving VW a backhanded compliment for being capable of delivering large projects when it's set up correctly and not used like a drawing board! 😉

Edited August 26, 2023 by shorter