topic Re: Different story heights in same model?? in Modeling

Different story heights in same model??

Anonymous — Wed, 08 Apr 2009 23:52:33 GMT

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?

Re: Different story heights in same model??

Anonymous — Thu, 09 Apr 2009 09:01:07 GMT

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...

Re: Different story heights in same model??

Anonymous — Thu, 09 Apr 2009 12:25:01 GMT

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

Re: Different story heights in same model??

vfrontiers — Thu, 09 Apr 2009 13:37:58 GMT

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.

Re: Different story heights in same model??

Anonymous — Thu, 09 Apr 2009 13:42:52 GMT

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!

Re: Different story heights in same model??

Anonymous — Sat, 11 Apr 2009 22:02:24 GMT

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!

Re: Different story heights in same model??

vfrontiers — Sat, 11 Apr 2009 22:44:54 GMT

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.

Re: Different story heights in same model??

Anonymous — Sun, 12 Apr 2009 04:40:02 GMT

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.

Re: Different story heights in same model??

vfrontiers — Sun, 12 Apr 2009 05:34:53 GMT

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.

Re: Different story heights in same model??

vfrontiers — Sun, 12 Apr 2009 05:36:21 GMT

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?

Re: Different story heights in same model??

Thomas Holm — Sun, 12 Apr 2009 08:21:07 GMT

aggie463 wrote:
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!

To answer aggie's question: No need for Photoshop or Illustrator. You just save views of each floor plan and then place/join them on layouts in your Layout Book, using the Organizer.

This documentation part is one of Archicad's greatest strengths. You're wasting your time if you don't use it!

Re: Different story heights in same model??

Ignacio Azpiazu — Sun, 12 Apr 2009 20:41:00 GMT

Layout book PLN/s receiving drawings from site PLN, building PLNs, units PLN, component modules PLN/s . It will probably make sense to publish PMKs from the model files and create the layout drawings from those.

One PLN for the site/master. Published story modules from individual buildings are placed on it; site-level construction elements and annotations reside on it; produces site-level views (plans, sections/elevations, perspectives, movies, schedules). I strongly prefer keeping all elements (walls, roofs, windows, etc.) symbolic, and use 'projected' only for those funky elements (skewed walls, clerestory or attic walls and roofs, whatever) that need it —it is much easier to set up, manage, avoid, trace and correct mistakes, and it is less demanding on the processor. It is best to use this file (alternatively, a project 'attribute management' file, but for most typical-sized projects this adds complexity without any benefit) to create all new attributes —materials, fills, layers, layer combinations, line types, etc., and take them from here to the other files using Attribute Manager. At any point in the process you should be able to just overwrite all attributes in the other files if there has been some screwup there.

One PLN for each building. Published unit and building component modules are placed on it; building-level construction elements and annotations reside on it; produces building-level views; publishes building-level story modules containing only the information that needs to go to the site file (if you don't want/need the WCs in your site views, you don't include the layer in the 'Building-to-Site module' layer combination; you can always change this combo at any time if you find you need them; this way not only the site plan doesn't get cluttered with elements you don't need there, but also you can use the same layer to contain different information in each file, especially neat for dimensions, annotation layers).
[If you have repetitive stories you might have an additional layer of module publishing within the same building, using one story as a master and publishing modules placed in the other stories.] Typically structure, mechanical shafts, demising walls, lobbies and lower stories want to reside in this file, and unit plans, core plans, envelope&balcony are modules generated somewhere else and placed here.

One PLN for generating unit infill plans (partitions, finishes, furnishing, equipment; unit-level annotations and dimensions). Produces unit-plan-level modules (Unit module layer combo-view-publisher set) and views. Building or room components may be placed on them (envelope panels and balconies, bathroom and kitchen modules, etc.), unit-plan elements reside on them. One unit plan is modeled in each story, so that the file is actually a stack of unit plans. In the module publishing combo you include what you want to send to the building pln. Even if you have little or no repetition in the unit plans and there is no advantages from moduling in that respect, individual unit plan drawings are needed for client review and marketing purposes. This makes working on the unit plans very easy and fast —you can find-select the toilets/partitions/tiled floorings/whatever for all the unit plans in the 3D window and with a single command change all instances in the project. Creating new units is a snap, and making changes across all units works very fast -story up, story down.

One PLN 'module factory' file for each of the component types over which you want to have central control across all the project (envelope panels and balconies, core modules, kitchen modules, bathroom modules, etc.), stacking them just like the unit plans. Produces component-level modules placed in the unit plan and building files, and component-level views (balcony drawings, etc.). Because you are publishing components from here and placing them in the unit plans and building files, this is the only way of easily and manageably modifying say all windows across all the project. Not only that —if at some point you want to try out new unit plan criteria, like say smaller kitchens + no walk-in closets + larger bedrooms, you just make a duplicate of the factory file, rename it, and publish modules from there; if you want to go back to the previous unit plans you publish modules from your first file.
+
One PLN 'module depot' file for each of the component types you are producing from module factories. Here you place in a single story, neatly arranged in grids or whatever, once in each module's lifetime, one instance of each of your envelope modules (or bathroom modules, etc.), so that from then on you just copy-paste your modules from here to your building or unit plan files, without having to touch Hotlink Manager or having to care about the name of each module (which you'd better be systematic about anyway, but you only care when you create them).

This makes all files very light, manageable for the user, the computer and the network, and the file structure makes it easy to split up the work without having to touch Teamwork, which is nice to have but it is nicer to avoid. Of course, in the unlikely event that at some point you need two guys working simultaneously on the unit plans (or site plan, or layout book, or whatever) you can always teamwork that file.

There is a diagram showing how the system works in a single-building project at http://www.ignacioazpiazu.com/samples/Wyndham_file_structure.pdf —I'll put something together for multi-building projects, but the concept is the same.

WARNING: as far as I know, the disappearing-elements-in-mirrored-modules bug hasn't been solved in AC 12 yet.

Re: Different story heights in same model??

vfrontiers — Mon, 13 Apr 2009 09:10:01 GMT

Ignacio,

Nice! I do still question the need to "recreate" each building in the SITE pln. I think I'd still prefer to create an object and place it on the site. I'm thinking of the times when I'll need to move a 20 story building on the site... You'll have to do it story by story, yes? You can't use MULTI-STORY modules as all the STORY to STORY heights might be different?

So instead of PUBLISHING modules, I'll have to keep updating (or versioning) a few BUILDING objects. Might be nice as a way to study alternate building solutions in the context of a CAMPUS Plan, tho. If I KEEP versions of the same building as "design alternatives" I can easily swap one object for another... Bldg1a > Bldg1b > Bldg1c, etc.

Now if we could only create 2d HOTLINES from the 2d symbol portion of my building objects, that would be great! I do currently have to place a bunch of HOTSPOTS at the corners to be able to "register" them on the site plan.

Re: Different story heights in same model??

vfrontiers — Mon, 13 Apr 2009 09:29:54 GMT

Also note that when Campus plans get big, you can Save the OBJECTS in BINARY format which will help rendering times when you need to visual the entire project.

Re: Different story heights in same model??

Ignacio Azpiazu — Mon, 13 Apr 2009 20:40:04 GMT

vfrontiers wrote:
II do still question the need to "recreate" each building in the SITE pln. I think I'd still prefer to create an object and place it on the site. I'm thinking of the times when I'll need to move a 20 story building on the site... You'll have to do it story by story, yes? You can't use MULTI-STORY modules as all the STORY to STORY heights might be different?

If a building needs to move, you drag it around *in the building file* either in the 3D window or 2D with thick marquee, and republish. It is a single operation.

[Building files should keep the site origin (so that at any point you can cut-paste stuff between site and building files, and things fall into place), unless you are talking of some more equipment-like pavilion which is not really attached to the site and that can move around, or of which there are many instances--but those are typically 1 story, 3 stories in the wildest cases.]

With objects you don't have control over layers, model display options, etc., and you can't generate site plans or diagrams, sections, elevations, perspectives, animations, schedules, from the site model without any extra work, live. You don't have a 'BIM' site-level model.

And creating and updating objects, even forgetting that they don't allow you to filter data for the documents mentioned above, is actually *a lot more work*. Once you hotlinked the stories (placing each story module once in the site file, at the start of the project—it takes a few minutes), you don't need any more work over the project's lifetime.