Design Alternatives or Versions

Michael Mayer

How do you deal with alternative Design Versions or Design Branches ?

• Duplicates of the whole Drawing ?
• Referencing Files contaning only the geometry that differs ?
• Separating by Layers only ?
• Putting related geometries into separate Blocks ?

Or something completely different like some separation/Sorting
by Structure Tree and Visibilities ?

ScottS

If alternatives differ substantially, I create separate drawing files and when time allows try to separate common elements that stay constant using xrefs. For less extensive variations, I'll make them into blocks on distinct layers that can be independently frozen. Both approaches are awkward to manage.

I finally started looking at the version control feature new in v22. Is anyone making use of that for this purpose?

The associative links between generated drawing output and the BIM files are already fragile, in my experience, with regard to renaming files or sections (as better naming schemes often arise later as designs develop...), so I am leery about how version control might help us with the parallel development and presentation of multiple design schemes.

Tom Foster

Call me naive, but I just Save As the old file from say 316B.dwg to 316C.dwg, leave 316B.dwg archived where it was, in project folder 316, and carry on working on 316C.dwg.

I do this after I have made a significant issue of drawings 316B-nn. Drawings (PS layouts) are saved, as issued, as part of 316B.dwg. They remain named 316B-nn in 316C-dwg but of course the linework auto-updates as I modify MS, so when it's time to issue once more I re-name their title block then to 316C-nn (or leave them as 316B-nn as a record of which ones weren't reissued this time). Trivial issues of drawings, I don't bother with all that, just issue as sub-version 316Ba-nn.

Why would I want to turn unchanged things into Xrefs? I use loads of large Blocks, e.g. one for each Plan/Elevation/Section. Those Blocks remain in 316B.dwg archived in that state; as they get modified, same name but different state, they're kept safely segregated in in 316C.dwg. I'd hate them to be Xrefs kept somewhere else! Why would I put the Blocks on distinct layers, freezable? I'm never going to swop/freeze/unfreeze Block versions within the current .dwg.

I don't see why the above can't include views generated from BIM, as reliably (or fragilely) as ever.

Versions can be sequential in time, or can be concurrent design variants. I suppose with the latter, there could be need for both to update ea other (Xrefs - but are they bidirectional? OK in Microstation but can they do that in .dwg?) except for the variant bit(s).

ScottS

Tom, I am thinking about concurrent design variants, e.g., exploring different interior configurations of a building, or different massing options and so forth.

Your process works fine if you're able to contain essentially everything in one file. Once you start involving xrefs (for reasons such as collaboration, asynchronous design iteration, or file size management), the best practice I have found, since before BIM, has been to avoid changing the filename with each iteration, keeping the current version always without any suffix (B, C, or date, etc.) so as not to lose it when externally referenced. Instead, backup copies are saved into an archive folder and renamed with dates and/or some index. If we ever need to revert to a previously saved version, we simply swap the current file with the desired backup, removing any suffix added, and the links still work.

As an example of freezing separate layers, I was recently studying fenestration options for a residential remodel. For each option, I made a block containing wall and window elements, which involved several standard layers. I put the blocks, however, on their own special individual layers so that I could freeze the options I wasn't currently working on. To present all options side by side, I could start by setting up the elevation in one paper space viewport, then duplicate it a couple times and use layfrz to freeze all but one of the special block layers in each viewport. That way, I could leave all the standard layers thawed to show whatever context they might contain, and I didn't have to create dozens of new layers, nor save redundant geometry.

Tom Foster

Yeah, mine's a different world from yours! I have indeed used concurrent-variant versions - if three, I've reproduced my MS 3x over within the same .dwg, and same for affected PS layouts, suffixing them v1 v2 v3. Keeping them all updated together manually, non-automated. Risky and laborious, much mistake correction.

I did try similar, automated - I have As Existing views in MS, whose linework forms the basis of the As Proposed views. Each view is a Block - at least 2 plans, 4 elevations, 1 section, in both As Existing and As Proposed - 14 Blocks minimum in MS. Frequently the As Existing view/Blocks continue to get detail added or corrected and I've wanted to have them update the corresponding As Proposed view/Blocks automatically. All this as you say contained within one .dwg.

I did make it work -
each As Existing Block consisting of 2 nested Blocks - As Existing unaltered and As Existing to be removed and each As Proposed Block of 3 nested Blocks - As Existing unaltered and As Existing to be removed (but greyed feint BY BLOCK) plus As Proposed new work.
Shifting entities from unaltered to removed (often only partially removed) etc - massive complication, perfection required, risky, laborious, in and out of REFEDIT even more than usual - after one version round I deconstructed the system back to manually updating As Proposed when As Existing changed! And showing simplified removed as manual dashed feint line in As Proposed. More work but much easier!