Different story heights in same model??

[Anonymous]

I have a building that has 2 towers on it, 1 has 15' stories and the other has 10'...can I set up my model so that this can be accommodated?

[Anonymous]

if both your towers' story heights (ie the floor to floor dimension) are the same then your file will just have a total of 15 stories set up and you model 1 tower with 10 the other with 15
if your story heights between the towers are inconsistent then... you have to think about how your plans will be displayed so that you set up storey heights and floor cut planes accordingly...suffice to say that you could set up the storey height to be the height of the 'taller' strorey and 'elevate' the shorter one accordingly...

[Anonymous]

Not quite sure i follow you on how to do that...

[vfrontiers]

I am presuming you want to document the two towers TOGETHER...on the same sheets? And that the 2nd floor of TOWER 1 is DIFFERENT HT than 2nd floor of TOWER 2....

If so, what xristina is saying is that you could choose to set story hts based on the 15 story tower, then when working on the 10 story tower, you'd have to OFFSET the elements (slabs, walls, etc.) to be relative to the other towers floor heights. So if 15 Tower's 2nd floor is +12' and 10 Tower's 2nd floor is at 10', you'd set up one 2nd floor at +12' and set all elements of 10Tower at -2' to the 2nd floor... This will be a bit confusing.

You could also create a unique story for each TOWER's floors

Tower1-Flr15-----------
Tower1-Flr14-----------
Tower1-Flr13-----------
Tower1-Flr12-----------
Tower1-Flr11-----------
Tower1-Flr10-----------
---------------Tower2-Flr10
Tower1-Flr09-----------
---------------Tower2-Flr09
Tower1-Flr08-----------
---------------Tower2-Flr08
Tower1-Flr07-----------
---------------Tower2-Flr07
Tower1-Flr06-----------
---------------Tower2-Flr06
Tower1-Flr05-----------
---------------Tower2-Flr05
Tower1-Flr04-----------
---------------Tower2-Flr04
Tower1-Flr03-----------
---------------Tower2-Flr03
Tower1-Flr02-----------
---------------Tower2-Flr02
Tower1-Flr01-----------
---------------Tower2-Flr01
Tower1-Flr00-----------
---------------Tower2-Flr00

If you are NOT documenting them together, keep them in different files. When it comes time to view them in 3d together, it might be easier to save each file as an OBJECT and place into a SITE FILE.

Or

If you want to MODULE THEM IN, you would have to use the DOUBLE LAYER system above and import each floor individually.

Suffice it to say, there are several ways to accomplish this, each with their own little pitfalls.

[Anonymous]

vfrontiers wrote:

Tower1-Flr15-----------
Tower1-Flr14-----------
Tower1-Flr13-----------
Tower1-Flr12-----------
Tower1-Flr11-----------
Tower1-Flr10-----------
---------------Tower2-Flr10
Tower1-Flr09-----------
---------------Tower2-Flr09
Tower1-Flr08-----------
---------------Tower2-Flr08
Tower1-Flr07-----------
---------------Tower2-Flr07
Tower1-Flr06-----------
---------------Tower2-Flr06
Tower1-Flr05-----------
---------------Tower2-Flr05
Tower1-Flr04-----------
---------------Tower2-Flr04
Tower1-Flr03-----------
---------------Tower2-Flr03
Tower1-Flr02-----------
---------------Tower2-Flr02
Tower1-Flr01-----------
---------------Tower2-Flr01
Tower1-Flr00-----------
---------------Tower2-Flr00

That will work fine...then all I have to do is merge Tower1-Flrxx to its correspondent Tower2-Flrxx in Illustrator or Photoshop, etc. for presentations.

Thanks!

[Anonymous]

To open this topic up a bit more, I'd be interested in hearing people's experience with the various options. We're starting our first project where we've got multiple buildings (5) stepping up a hillside, and we're weighing the disadvantages of various options.

1. Master file has site information and and CD Layouts. Buildings are each in a file, brought in as hotlinked modules. Downside is that materials, wall types, floor types, layers, etc. that get modified when people are working in one building model have to be manually updated in the other four. (Manually means trouble.)

To make it more complex, the project is apartments, so we'll have bathroom, kitchen, and dwelling unit modules in the buildings, which will have to be updated regularly, then potentially the buildings as modules onto the site plan project. We've done nested modules before, but this adds another layer to the process, which always makes things messier.

2. Put all models in one project. People marquee around the building they are working on and have full control. Downside is limitations in layer/material/etc. modifications by various team members when others are signed in - but at least accidental duplication of layers, etc. of option 1 above wouldn't happen.

We'd have ten stories in AC for five 2-story buildings. Going from the first to second floor in the Plan Window for a given building could mean having go go through two or three intervening stories. As a result, we also wouldn't be able to use the Floor Plane Cut Plane effectively.


Are there any other better, more artful strategies anyone has come up with that can make things easier in the long run? There's nothing worse than realizing the strategy you start with has big pitfalls...half way through CD's!

[vfrontiers]

My hypothetical scenario might look a bit different. I don't think I'd consider the SITE plan as the host for all the documentation. Rather, I'd approach it as the just the site and the buildings placed there would actually be OBJECTS for 3d visualization.

If you want the site plan to show floor plans at the site level, simple edit the 2d of the resulting building object to represent the floor plan. If you like to see roof plans on the site, you can leave the objects as they result from the 3d window.

Each building plan would be self contained keeping the story dilemma out of the picture. Then you can decide whether consultant plans need be done on a BUILDING LEVEL or ROOM MODULE level. Likely it will be BOTH. So you can use the module idea throughout your documentation.

I need to work on this a bit, but that's my direction today.

[Anonymous]

Duane, good to hear from you again!

I'm wondering why you'd place objects rather than modules. That's more clunky to update when things change, and in a Teamwork environment, people have to keep re-loading their libraries.

I do like the idea that one could bring in the view of any story or the roof as the 2D view of the building, making for a nicer site plan drawing.

One way around the Floor Plan Cut Plane challenge I mentioned earlier would be to set Views for each plan, and set the FPCP in that View, then always use Views to navigate (as opposed to panning from one building to another.

Further complicating matters, I remembered that on this project we've also got buildings that are split-level...between three and five feet of level change that also needs to be accounted for in the FPCP and stories.

Getting interesting.

[vfrontiers]

Hey Erick...

I guess it's that old paradigm shift again... I am considering that the BULK of each building plan is TOO much weight for the site plan to handle. And perhaps, in my scenario unnecessary as I see the BUILDING PLANS themselves as the DOCUMENTING cog in the wheel.

I don't believe MEP or even structure for that matter, belong in the site plan. I have relegated overall 3d viewing and site documentation to the site and ALL the other building bulk is superfluous.

Further, I don't think Bldg 1 Systems need to know what Bldg 2 systems are doing necessarily.

Most of the SITE involvement with the buildings should be EARLY in the process, therefore changing the "building objects" might be heavy in this phase and lighten later on. Not necessarily because the building changes less, but because the NEED TO SEE IT in the site plan becomes less.

And, in my experience, it takes LESS time to reload libraries than to send and receive changes! In fact ALL team member can reload libs at the same time, whereas S/R will be ONE AT A TIME and is a lengthy process.

Also, by using my scenario, it may be possible for you to skip TEAMWORK altogether! One guy on Site, one on Bldg. 1 and one on Bldg2.... You get the idea..

Again, this is just food for thought. And I thoroughly enjoy this kind of debate. I am actually STRUGGLING with teamwork. Not on these issues as I work on custom homes. But the endless changing of workspaces clearly means I don't have a clear definition of the TEAM parts just yet.

[vfrontiers]

Erick,

In your scenario, how are things such as SCHEDULES handled? I presume in each BLDG file, then cross referenced into the site/documentation plan?