CS 01: Multifamily Units – 01 The Campus Project

Round 1- The Campus Project

Project Overview
The first project was 7 different building types arranged on a site plan. The unit mix included 6 different unit types in the base building block. All buildings were modeled in their own files and linked into a site file where they were arranged in their locations. The site file was used for all documentation including details which were shared amongst all the buildings. The different building types were all the same architectural style and had similar elevation/massing elements between them – bay windows, end cap gable forms, balconies, etc. The variation was in the assembly of the similar elements and modules.

The Process
The first unit plans were developed with the building types. No groups or links – as if nothing repeated on the project. Once the first building type was created and developed, it was saved as another file and modified to create the other building types. Then the units were grouped, converted into links and replaced in all the buildings to keep the information consistent across all the buildings.

Several problems arose with the links and determining what the bounding elements of the unit should be. The first round of links did not include the bounding walls (exterior, corridor, demising) – Reference planes were used to delineate the boundaries of modeled elements. Several of the component families were deleted in the process because they were hosted to elements (walls and floors) that were not included in the groups/links. This is when we began creating component families that are not hosted.

The process of converting a group to a link and back had just been introduced and proved to be a little finicky. Halfway through the project, we ditched the separate links and just stayed with the groups. The units were developed well enough to this point, that we decided to make any changes in each building. We held on to the groups since there were several instances of each unit in each building.

Pro’s

  • The units as links stayed up to date in the separate models/buildings like they did with AutoCAD.
  • ​The units as groups kept the layouts within a building consistent.
  • The units were fully modeled allowing the elevations and plans to update simultaneously.
  • All of the interior elements were visible/modeled for the building and wall sections.


Con’s

  • As links, the units were all separate files, so a small change to a door family had to be changed or updated in every unit link separately, then re-loaded into each building. Same held true for the buildings – lots of duplicate effort and transferring project standards.
  • Using the site file for documentation meant setting up sheet views (plans only) in the separate building files for the element tags. All the elevations, sections and details were created in the site file as well as the dimensions. A small adjustment to coordinate a tag and dimension in the same place meant opening 2 files (only 1 at a time).
  • Walls in the links did not clean up with walls in the buildings. When our exterior condition changed slightly, there was allot of extra modeling to make up the difference and extra graphic cleanup to make the plans presentable. To help with the cleanup, we switched the units from links to groups before printing. Eventually the links went away all together.
  • Links bring their own levels with them, when switched to groups, the levels go away, sort-of. While levels could be hidden in a linked file by overriding the graphics of the link in a view, you could not do this on a link 2 files deep: site-building-unit. Another reason groups made more sense.
  • Groups work well when they don’t have to interact with anything else in the model. They also work well when everything is hosted to a single level. Flipping 2 story units from groups to links to incorporate changes from another file was problematic. Some days it worked, others there were so many errors, we would delete the groups and re-insert a new link. By the end of the project it became faster to make the same change in multiple buildings instead of flipping and re-linking groups.
  • We hit our technical limit on file size with all the buildings loaded into the site file. We recently purchased top of the line machines and no one could open the entire site with all the buildings loaded.


Final Thoughts
Using links with separate building files is still the only way to keep the units updating automatically. The lack of interaction between the units and buildings added countless hours of 2D graphic cleanup so groups ended up the better option. Tagging across links was also not available at that point, so there was lots of back and forth between the building and the site when tags and dimensions overlapped.

If I did it over again, I would have modeled the buildings and units in a single file, all inline with each other, i.e. no site orientation. This would require a separate process to lay out the buildings on the site, but they only showed up together on the site plan. Just one 2D plan view – I’m sure there’s another program better suited for that work …

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s