cr_gixxer
2012-06-29, 04:37 PM
As you may see in my several other posts, I, like others am trying to make townhouses more efficient, I have decided to step back from all my current modelling with groups etc, and re-theorize how to structure these projects. I have a large file with all groups, and its at a standstill....I am spending more time trying to do things than actually doing anything.
My strategy that I am exploring now is to attempt to link files:
-separate files for the different unit types, exterior shells only.
-separate files for the numerous interior options.
(all of these files would use reference planes for alignment....not sure if grids would be better....)
Right now I'm thinking all these separate files will be linked into a large "site" file. (Ideally this would only be a file for each block for CD's), but first I need to put together a tender set with everything together
I'm not sure how to approach the grid lines in the large file. I might need to paste opaque "GL" text over the unique grids. I could then saveas this file for each blocks' CD package, and delete the other blocks that I don't need.
What I'm really hung up on right now is that the shells have options:
One instance is for a balcony. So the only difference between UnitA and UnitA-balcony would be a window changes to a patio door, and the balcony tagged on the outside. Would it make sense to have a balcony file linked into the shell file. Could I turn this off and on? It's easy enough to have the two UnitA model files, but as things go in architecture, the client will want to change something...let's say a window goes from a casement to slider and move it 2 feet down the wall. My issue is that I would have to make that change twice.
Another instance is that one shell might have stone rather than siding on the street face. Again the same issues with making a change would be double, or triple work.
I have 8 unit types, although 3 types basically cover 80% of all units on the site.
I've mapped out all the unit types and variations I need, and it goes something like this:
UNIT TYPE A *end is on the end of the block, interior is midblock. HiVis has a bumpout and side windows*
-LoVisibility End Unit
-LoVisibility End Unit - Stone street front
-HiVisibility End Unit
-LoVisibility Interior Unit
Some or all of these may or may not have a balcony.
So you can see why one single change would be alot of work for me. ( I would have to go into 8 files to make the change)
The number is "options" with this client is kinda ridiculous, and having all these options simultaneously is what I think is the real source of thjs. I've looked at how this has worked for them in the past with their consultants in CAD, and it's just as ridiculous for them, with just as much work.... so I'm not going to play the blame the software game.
So in looking at Design Options as a solution...
From my initial playing around, design options seems to be global when linked into another file. Whatever is primary in the linked file will propagate through all instances in the large file. Is there a way around this?
I wish I could set up a linked file similar to a family where I can associate modelling with a type or instance parameter that I can toggle with an on/off switch.
My strategy that I am exploring now is to attempt to link files:
-separate files for the different unit types, exterior shells only.
-separate files for the numerous interior options.
(all of these files would use reference planes for alignment....not sure if grids would be better....)
Right now I'm thinking all these separate files will be linked into a large "site" file. (Ideally this would only be a file for each block for CD's), but first I need to put together a tender set with everything together
I'm not sure how to approach the grid lines in the large file. I might need to paste opaque "GL" text over the unique grids. I could then saveas this file for each blocks' CD package, and delete the other blocks that I don't need.
What I'm really hung up on right now is that the shells have options:
One instance is for a balcony. So the only difference between UnitA and UnitA-balcony would be a window changes to a patio door, and the balcony tagged on the outside. Would it make sense to have a balcony file linked into the shell file. Could I turn this off and on? It's easy enough to have the two UnitA model files, but as things go in architecture, the client will want to change something...let's say a window goes from a casement to slider and move it 2 feet down the wall. My issue is that I would have to make that change twice.
Another instance is that one shell might have stone rather than siding on the street face. Again the same issues with making a change would be double, or triple work.
I have 8 unit types, although 3 types basically cover 80% of all units on the site.
I've mapped out all the unit types and variations I need, and it goes something like this:
UNIT TYPE A *end is on the end of the block, interior is midblock. HiVis has a bumpout and side windows*
-LoVisibility End Unit
-LoVisibility End Unit - Stone street front
-HiVisibility End Unit
-LoVisibility Interior Unit
Some or all of these may or may not have a balcony.
So you can see why one single change would be alot of work for me. ( I would have to go into 8 files to make the change)
The number is "options" with this client is kinda ridiculous, and having all these options simultaneously is what I think is the real source of thjs. I've looked at how this has worked for them in the past with their consultants in CAD, and it's just as ridiculous for them, with just as much work.... so I'm not going to play the blame the software game.
So in looking at Design Options as a solution...
From my initial playing around, design options seems to be global when linked into another file. Whatever is primary in the linked file will propagate through all instances in the large file. Is there a way around this?
I wish I could set up a linked file similar to a family where I can associate modelling with a type or instance parameter that I can toggle with an on/off switch.