Managing Multiple concepts; Layers vs Files

[woodwerdtx]

Looking for tutorial or thread on best practices for managing multiple concepts. For example, have the as built for a kitchen, but I want to show two different levels of concepts from the AS BUILT. Best practices to use two files (what I have done for years) or learn how to manage layer sets better? To be layer sets or not, that is the questions.

[SHCanada2]

multiple files is best IMHO. layersets method falls apart as soon as there are walls close together. you can try using no room definition walls if you want to give it a go. 

 

I do the as built, and then create copy in the project browser, and then rename that copy as my as built.

 

 

[Alaskan_Son]

If it requires using any parametric objects (walls, windows, doors, cabinets, roof planes, etc.) then storing in a single plan comes with all sorts of problems.  That being said, one thing I personally do for relatively small options changes like a different kitchen cabinet configuration for example is just group select "Kitchen A" and drag off to the side a specified distance (say 50 ft. so its well out of the way).  I then drawn in "Kitchen B".  Option A remains off the side where I can easily group select (unless it already in an Architectural Block) and then move back the specified position to where it previously was.  using this method allows for a way to at least store your various options in a single plan.  Doesn't work so good for super complex changes though.    

Edited Sunday at 12:19 AM by Alaskan_Son

[johnny]

I’d highlight that if Chief (a) allowed us to block all elements, and (b) enabled editing within a block without having to break it apart, then the grouping block layer (as an override to sub-block object layer) would give us a much more elegant solution to this problem. It would let us edit the contents of a blocked container (version) seamlessly and toggle layers on and off in the same x/y/z space effortlessly.  

 

one day i hope....

[SHCanada2]

the other thing I do is if you are only moving/removing an interior wall or two, I will use plines for these walls instead of walls, then turn the layer on and off. but that doesnt work so well if there is currently a door in the wall

 

Edited Sunday at 01:14 AM by SHCanada2

[JiAngelo]

2 hours ago, johnny said:

I’d highlight that if Chief (a) allowed us to block all elements, and (b) enabled editing within a block without having to break it apart, then the grouping block layer (as an override to sub-block object layer) would give us a much more elegant solution to this problem. It would let us edit the contents of a blocked container (version) seamlessly and toggle layers on and off in the same x/y/z space effortlessly.  

 

one day i hope....

Starting with your last point first, you can already reference another plan file in the same x/y/z space.  In Plan 0 you can toggle off the walls and objects you plan to change.  Then Reference Plan 1 (or Plan 2, etc.) with only the changed walls and objects turned on in the referenced Plan layers etc.  The blocked container version you are referring to is precisely what the option files called Plan 1, Plan 2, etc... already are.

 

With regards to A&B, Chief defines spaces as rooms.  You can't add, subtract or move "alternate" walls without redefining the rooms they contain.  Imagine you wanted to shrink a 10'x10' laundry room 1' so that your 10'x10' kitchen could be 1' larger.

There is no way a 10'x9' opt. laundry and 10'x11' opt. kitchen can coexist in the same plan file with the (2) 10'x10' original rooms.  However they could be referenced within the plan 0 and quickly toggled on/off using layersets. Make a change in Plan 2 and the reference will update if displayed in Plan 0.  And within each optional plan file you can accurately create the material list, calculate floor areas, and room volumes accurately.  This is especially beneficial if you had Plan 1 showing a wall with 4 ganged windows and Plan 2 had 3 separated in the same space where Plan 0 originally had no windows at all.

 

@SH_Canada stated it correctly.  However I often use @Alaskan_Son's  method in the short term when initially designing spaces and I'm trying different room layouts to see which one works best.  Eventually I have to delete all those offset ideas so that my schedules are correct when sent to layout.

[johnny]

15 hours ago, JiAngelo said:

Starting with your last point first, you can already reference another plan file in the same x/y/z space.  In Plan 0 you can toggle off the walls and objects you plan to change.  Then Reference Plan 1 (or Plan 2, etc.) with only the changed walls and objects turned on in the referenced Plan layers etc.  The blocked container version you are referring to is precisely what the option files called Plan 1, Plan 2, etc... already are.

The entire premise of this discussion I thought was to find a layer-based method that avoids managing multiple files. That’s where a contained or “blocked” option system has a clear advantage....everything lives in one place.

 

What you’re describing, on the other hand, is essentially accepting the multi-file workflow. The issue becomes obvious in a typical scenario. Using your example of three separate plans.... if the client hasn’t finalized their decision but you still need to keep developing the project, you’re forced into a difficult position. You either:

• Update all three plan files in parallel to keep them consistent, or
• Move forward in just one file and risk investing time in an option the client may not choose

Both paths introduce inefficiency and risk. If those options were contained within a single file.....organized as blocked or grouped alternatives... you could continue developing the project once, while simply toggling between options as needed. That eliminates duplication of effort and keeps everything coordinated.

 

15 hours ago, JiAngelo said:

With regards to A&B, Chief defines spaces as rooms.  You can't add, subtract or move "alternate" walls without redefining the rooms they contain.  Imagine you wanted to shrink a 10'x10' laundry room 1' so that your 10'x10' kitchen could be 1' larger.

There is no way a 10'x9' opt. laundry and 10'x11' opt. kitchen can coexist in the same plan file with the (2) 10'x10' original rooms.  However they could be referenced within the plan 0 and quickly toggled on/off using layersets. Make a change in Plan 2 and the reference will update if displayed in Plan 0.  And within each optional plan file you can accurately create the material list, calculate floor areas, and room volumes accurately.  This is especially beneficial if you had Plan 1 showing a wall with 4 ganged windows and Plan 2 had 3 separated in the same space where Plan 0 originally had no windows at all.

I understand that Chief Architect defines spaces as rooms....and that’s really at the core of the limitation we’re discussing. That said, I don’t think it fully justifies the current workflow constraints. In principle, it should be possible to:

• Group or “block” elements like walls that don’t actively define a room boundary
• Edit those grouped elements without fully breaking them apart each time

Right now, Chief’s handling of architectural objects makes that kind of flexibility impossible.

Edited Sunday at 06:35 PM by johnny

[JiAngelo]

My apologies, I thought the best method achievable today to manage multiple concepts was the premise of this general discussion.  

 

Your desire for "a contained or "blocked" option system" describes what every plan file actually represents.  Being able to reference portions of one plan file within another plan file is the method to achieve precisely what you desire today.  When you reference portions of Plan1 or Plan2 inside Plan0 they appear as a your "Group or "block" elements like walls that don't actively define a room boundary."  Inside Plan1 or Plan2 is where you "edit those grouped elements without fully breaking them apart each time."  Because each appears as a group when referenced inside Plan0, but exist as individual items in Plans 1 & 2. 

 

Click over to Plan2 tab, make some changes.  Click back to Plan0 tab and those Plan2 changes, if they were on the referenced layer set, appear instantly in Plan0.  I don't see how it gets any simpler than having a few open tabs with one click to visit the unblocked optional "contained" plan versions.

 

Here's an example that was done in reverse.  Here's the Plan 0 foundation.  

Here's Plan 2 option client chose

Inside Plan 2 I have already referenced Plan 0 within it.  Here's what happens when I turn reference layers on in plan view.

  Damn, I need those dimensions on the reference layer turned off. Lets redefine the reference layer (Plan0) to not show dimensions or room names.

Wait a second, there was a shed we forgot to show on Plan0 behind the garage.  Let's click over to Plan0 and add it.  And instantly look what happens to our view in Plan2

And before i forget,  Here's Plan 1 inside this addition.  Compared to Plan2 (with reference Plan0 turned off)

I did this in reverse because I personally wanted to make sure I didn't place new foundation over any of the other old garage walls.  Then I waited until clients chose which option they want before refining the one they chose, ready for permitting.

 

Two options plus the as-built inside one plan file introduces several problems as other users previously noted.  Schedules, material lists, conflicting roof planes if you are showing two different room addition options.  Ceiling heights if one option is to open the ceiling to a loft above.  And there's an entire thread devoted to auto foundations.  Imagine this turned on with multiple upstairs options simultaneously present - or you start switching between them???  Lastly, you need to call out the reference plan separately, or twice, one in plan view and again in 3D view.  This is achievable today.