Just thinking, would you do detailing for an option? Is the detailing not further down the design road from options...
Jus' sayin'...
|
|
|
Just thinking, would you do detailing for an option? Is the detailing not further down the design road from options...
Jus' sayin'...
http://forums.augi.com/showthread.ph...17#post1004017
Check this link to a post I recently wrote. You can detail your options, the process is just slighlty different.
I think Design Options are really intended for major scheme variations during early concept design--for instance:
Option 1 : Barrel Vault entry canopy
Option 2: Pitched Roof entry canopy
i.e. fairly major design schemes---and not smaller, detailed options.
Too often I see Design Options being "over-used" --like 25 or more!
and lingering too far into DD/CD phases--which adds a lot of complexity
to the model, confuses new team members, and slows down the model
and users' ability to work quickly, clearly and efficiently.
Our policy is to develop several of them for Concept/Schematic Design, during our rapid
design study phases, and present the options to the client, get decisions made,
and then delete them--and move into DD/CD phase.
I do not recommend taking Design Options all the way to the con doc detailing level.
It can be done, but adds a lot of complexity which is better avoided by getting
decisions made earlier, and then moving forward with detailing on the approved design
in the main model.
Of course there will always be some exceptions to this, but the point is to establish
a standard of practice which keeps the workflow smooth and as painless as possible.
This becomes especially important on large, complex projects with 10 or more users.
Just my take after seeing it done a lot of different ways.
cheers........
We do. We provide a prototype with the entire, complete set of construction documents with every option. Apparently, we're the only firm doing this with an insane number of options. To make matters worse for us, you can't have a design option within a design option (within another design option).
As noted by twiceroadsfool, binding merges the MODEL, not the documentation.
Ryan could you not simply compile your full project documentation from 2 (or more) .rvt files, each addressing the associated feature/option? It's a CAD approach, yes, but if you're invested the time to detail each option separately with it's own reference tracking, then you can link the main/base model into the option, link the option into the main/base, etc. for visual continuity, but do a compiled documentation print with sheet names adjusted accordingly.
I've been reading (and gathering from your posts) that design options should be used for early schemes as well as smaller parts of a larger model. Our firm is currently collaborating with another design team, and each of us has an "option" to present the client. So, our entire office is trying to work under "Design Option 1" for our work. We keep running into sharing problems. Does anyone know if Design Options are checked out as an entire set when collaborating inter-office? If so, what ways could we work around each other and be able to edit different components/buildling parts without interfering with one another, yet still share the same "Design Option" umbrella?
adafchik - if the two design teams are working on completely different concepts, then why attempt to put them in a single file? (especially if the teams are physically separated, as a WAN adds to the complexity of things).
Why not establish the 'common' features (existing building, site, for example) as a separate file LINKED into 2 separate development files. The presentation model can be the 'common' model with 2 links - Option 1 and Option 2. Just turn off the workset of either option to display for presentation.
Technically their mental model for Design Options was production home builders that have many options and need to generate sets for any combination. The Design Options would definitely not go away in that scenario. The recommendation to remove them applies to large projects that really won't need to keep them. If a project needs to hang on to them...that's what they were meant for.
I was looking into using the Link/Bind method to bring modular prototype designs into a model.
It works pretty slick. There is a certain amount of clean-up you may need to do such as ungrouping and modifying the workset of each element (they all come in on "Shared Levels and Grids"). You also need to re-tag everything. Of course you would need to clean-up where the prototype and the model connect. The only real gotcha I've encountered is sometimes our door swings flip (swing family is nested inside the door family).