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 21 hours ago 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 20 hours ago 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 3 hours ago by johnny