Cautionary Tale?

Posted on May 20, 2011 by nmcclure

A cautionary tale of #BIM?
I say it’s a segway to an important discussion on LOD definitions on your projects!

Interesting comments unfolding through the LinkedIn RTC Community group – join the discussion!

Posted in BIM/Revit | Tagged , | Leave a comment

Weaning down the model warnings

Posted on May 3, 2011 by nmcclure

As a design model grows in complexity, and multiple relationships between elements are created either by the system or by the user, it is inevitable that changes will either invalidate relationships, or create conflicts with intermediary items. Significant changes such as an adjustment to a Level elevation can cause a string of elements to require revision, especially elements with constraints at both base and top.  Revit is constantly regenerating and reestablishing element relationships, so a growing list of warnings can significantly degrade overall processing efficiency.

Generate a list of warnings from Manage > Inquiry > Warnings. The list groups similar warnings together, and each warning item can be expanded to identify by element ID number what it is affecting.  The list can be exported to an html file for a record copy, or just to have handy while researching the issues, as you have to close the warnings dialog to go back to working in the model.

NOTE: While the warnings list can be daunting, not every listed item is worth hunting down and resolving. Many are relatively inconsequential, and present minimal impact on the design or model processing.  Issues involving the following items, however, DO have significant impact, and should be reviewed and resolved:  Rooms, Areas, Stairs and Ramps.  Review duplicated element warnings as they can throw off your quantity counts for scheduling.

Posted in BIM/Revit | Tagged , | 2 Comments

New Project Setup Guidelines

Posted on April 19, 2011 by nmcclure

I’m often asked to outline definitive steps for a team to setup a new Revit project.  If you review a typical Revit manual or handbook, the process seems pretty straight-forward:

  • Start a New Project – Select a Template
  • Setup Levels
  • Model near the template’s center

Now, in an isolated design model world, this really IS enough information to get going. However, in the real world of architectural design, this is rarely ever the way to go. What really needs to happen can’t be outlined step-by-step, because there are too many variables that need to be considered, which can redefine the specific steps significantly.  What CAN be outlined, however, is my suggestions for the assessment process:

  • Define the design team as much as feasible. Know what software they will be using, and what format their deliverables will be, and what they need to get from your team.
  • Catalog the key resource documents. Is there a survey available? Are there existing building documents? What are their formats? Will the proposed design documents need to ‘marry’ back to these resources?
  • Define – really define! – what deliverables are expected from YOUR team. Handing over the model is QUITE different from providing CDs and CA services. This includes having a concept of what is critical to model in 3D, and what isn’t, and how to make those decisions.
  • Know who will be using your model as the basis of their own discipline’s design work.  Establish a ‘chain of order’ of who will begin modeling first and subsequently.
  • Be realistic about the project size. Plan ahead for needs to divide up a large program model to manage file size and workflow. Assess your design team to setup logical divisions of work. This is truly a critical aspect for successful project processes!
  • Establish a team lead for model maintenance. This includes managing model exchanges, model maintenance, model coordination review. This does require a process which increases in complexity very quickly, and a person to see that iterative process through.
  • Know which team members WON’T be modeling. Know if they will be contributing to or reviewing the design in the model environment, or if export processes need to be used throughout the design progression. Plan for specific, repeatable methods. This is key for efficiency, and to gain confidence in modeling as a design process.
  • Establish internal goals for both the project and your firm’s overall BIM initiative. Set aside time/budget to measure, assess and adjust as necessary.  Just as a design never progresses in a perfect linear progression, neither does the modeling process.  Allow for adaptability.

And my final and most adamant piece of advice: Don’t over-commit what you will deliver with a 3D model. Know what aspects take on the highest priority per the project needs and client desires, and set expectations accordingly.

Clearly, there are many considerations, and each project will be different. Plan ahead, and be diligent in maintaining processes, and keep the Big Picture – your specific project goals – in mind!

Posted in BIM/Revit | Tagged , , | Leave a comment

Worksharing: RL early, RL often!

Posted on April 12, 2011 by nmcclure

During the early modeling phase of a project, as team members are busy creating new elements, there may not be much traffic conflict regarding worksharing. You’re creating something new, so there’s relatively little conflict with other users’ actions. Later on in the project development, things get a bit more complex. Now, small changes are happening everywhere, and all the default and/or added relationships between elements become more… tempermental. Users begin running into the warnings that advise them they can’t complete their action until “user “coworker” has released the element.”  Another scenario – you make a series of updates, no conflict warnings, you sync back to the central file. A half-hour later, you pan back over your view, and – lo and behold! – those updates are right back to the WRONGness they were at the start of your day. What gives?

The common culprit:
…of these nasty hijinks is users’ lack of sufficient Reload(ing) Latest. The RL command draws into a local file all the current changes synced out from numerous users on the project team, and brings a lone local file up to date.  I highly recommend to project teams to do frequent RLs – I like a minimum 3:1 RL:STC, myself.  In other words, 3 RLs between each STC.  For large modeling teams, they might consider the ratio to be even higher.  Think about it – if there are 5 modelers, thats 4X the amount of activity/modification going on outside of each individual modeler’s local file. That’s a lot. If an individual local file goes too long without drawing in all those updates, they are a) certainly not responding to the latest and greatest data/geometry, b) not releasing all the elements they’ve been modifying, thereby blocking other user’s actions, and c) more likely to reach a “file out of date, cannot sync to central” crash. And you can imagine what that means. Heads will roll!

.
Now let’s consider the Perfect Storm:
…a relatively new modeling team, a crunch towards DD deadline, and a large model. I throw in that last factor, because the larger a model size gets, the more a newer team inherently resists syncing – they don’t like the ‘downtime’ of waiting for long sync periods, and so they just…. don’t.   Here’s the scenario: a few of the modelers aren’t diligent with their RLs and STCs. They’re cranking away on deadline, so they’re heads-down buried in their own project tasks. Several on the team, however, are diligently syncing out lots of changes – shifts in plan, embedded data updates for advanced schedules. Here’s where the warning bells should alert!  Because Revit’s worksharing process actively tracks physical tugs-of-war – I’m trying to move an element someone else has already borrowed – active conflicts are easy to notice. But now, we’ve got some users syncing diligently, thus borrowing elements left and right, but releasing them again with each sync. And remember, once released, Revit allows another user to modify it at will.  Meanwhile, we have a few users who have toiled away in now outdated local files for hours.  When those Johnny-come-latelys finally DO sync, they are pushing OLD DATA – old locations, old geometries, old embedded data – right back over the work of the diligent syncers.  Chaos ensues.
.
How can this be prevented?
I highly recommend ALWAYS doing a RL prior to a sync. This makes sure that other user’s updates are pulled into your local BEFORE you push out your own changes. Also, increasing the frequency of RLs between your syncs makes sure that local files are up to date, incrementally, with the collective progression of the project. If the entire team is on board with this system, then no one would have old, outdated geometry or data to accidentally override work that had been done by others. Also, increased RLs mean shorter sync durations, because there isn’t as much out of sync to begin with. That means less queuing up of network traffic, less frustration over long waits, more efficient productivity. In short, happier campers… I mean, modelers.
.
Long story short:
…a few bad apples can spoil the pie.  All it takes is for one team member to be a reluctant RL/STCer, and you’ve got the potential for old overwriting new. This isn’t really a Revit phenomenon, old data overwrites can happen in any program, but because Revit is an all-inclusive model environment, with lots of responsive interaction between elements, it’s repercussions are more, how shall we say?..  dramatic.
.
So get it implemented – RL early, RL often!
Posted in BIM/Revit | Tagged | 4 Comments

Daunting Reputation

Posted on April 5, 2011 by nmcclure

Ah, the Danes and their dragons!  I came across this gorgeous piece of architectural sculpture while cycling along Bredgade heading towards the Kastellet. In addition to being awed by the captured sense of power and movement, I love that the sculptor connected it to the architectural trim flanking it.

Posted in PublicArt | Tagged , , | Leave a comment

Copenhagen Rundetaarn

Posted on April 5, 2011 by nmcclure

Top of my list of fabulous sights in Copenhagen is the Rundetaarn, located in the Latin Quarter of the city. Built between 1637 and 1642, it combines church, library and the earliest known European astronomy observatory into one building complex.

As stately as the building is, with lovely brickwork and graceful exposed timber beams, the real delight is the Spiral Walk in the tower -  a 209 meter long ramp that winds itself 7.5 times around the hollow core of the tower. This construction is unique to Europe, and I pondered if it was to enable the installation of equipment (telescopes) rolling to the top observatory.

 

The ramp itself is tiled in the direction of the curve, creating a beautiful texture, enhanced by the bounce of natural light off the whitewashed walls onto the stone tiles.


Posted in Architecture | Tagged , | 1 Comment

Revitizing Pre-Design

Posted on March 29, 2011 by nmcclure

There’s a whole lot of work that goes on for a complex design problem before a pen hits the sketchpad (or the cursor hits the screen, whichever is your process). For any project, no matter the scale or scope, there is programming to be done to define the needs, the users, the required adjacency and spatial ratios necessary.

A lot of programmers use simple bubble-diagrams (and lots and lots of trace paper) to distill a spatial scheme from a simple parti to an area plan.  It’s quick and very visual. However, they are difficult to control in terms of representing real space – so a fantastic sketched diagram can hit some serious challenges once real numbers are applied, and that’s usually after a lot of time investment against what is often a by-phase fixed fee.

Others approach the task from a spreadsheet point of view – start with the data, organize and calculate it, then take the tabular printout and try to visualize it into a scheme.  A more accurate approach, certainly, but few designers get sculptural inspiration from a spreadsheet.

I’ve been devising two customized Revit methods for working more visually in the pre-design phase, but still leveraging the database capabilities of Revit.  Why two methods? Because based upon the goals of the project (functional efficiency for a hospital, for example, versus more fluid, sculptural goals for an art gallery) less (or more) spatial constraints can be more (or less) beneficial.

METHOD 1:  Data Enabled Bubble Diagrams

This method uses Room Boundary lines and Rooms, creating sketches (from rectangles to literal bubbles) to define a target area enclosures with Room elements reporting area and holding other customized programmatic data.

These are grouped individually or in sets, then easily copied and moved to represent various layout options.

Tip: I generally lay out several options side by side in the same file, with embedded data allowing me to schedule out per scheme.

Color Legends create immediate, visually defined diagrams that can quickly communicate various reviews of relationships, adjacencies, circulation flow.

 

Considerations:
Using Rooms allows for Color Legends in 2D views, for flexible, immediate visual diagrams.


As design is developed architecturally, these pre-design rooms can be easily moved into the developing design model, transferring all embedded data seamlessly.

METHOD 2:  Dimensionally Controlled Masses

This method uses customized Mass boxes to quickly define appropriate spatial footprints based upon area targets and a desired length dimension.  The masses are developed to parametrically divide a stated area by a defined width dimension to produce a desired length in the mass (ie: 175 sf / 10′ depth = 17.5′ length).  For programs that must compactly organize sequences of spaces, this can very quickly produce an accurate plan diagram, and masses can be aligned and organized in intelligent ways for efficient manipulation in alternate schemes. 

Customized parameters allow for filtering and organizing data into schedules, and application of embedded materials can provide visual coding.

Considerations:
More accurate spatial footprints than the bubble-diagrams of Method 1, but also more rigidly organized. Color diagrams require more set-up and are less flexible. Data will ultimately need to be transferred to Room elements in the future.

 

Both methods give the Planner/Designer the power of getting cumulative area data that can be organized and processed natively in Revit to validate the design against the project goals.

These are methods for Pre-Design that use Revit Architecture alone to ‘get real’ with conceptual layouts. For very large programs that have owner requirements of significantly more complexity, consider using a Revit add-on program such as Ideate’s Revit BIMLink to extablish a push/pull exchange with Excel spreadsheets.

 

Posted in BIM/Revit | Tagged , , , | 2 Comments

I (cycle) CPH

Posted on February 28, 2011 by nmcclure

I’ve been an urban cyclist since living in Frankfurt, Germany and while I’m certainly not a hardcore bike commuter, I do enjoy viewing new cities from the seatpost.  A recent trip to Copenhagen had me excited to be immersed into what some say is Europe’s most bike-centric city.  Over three days, I cycled through the historic Latin Quarter, the bustling downtown business districts, the bucolic field-flanked trails in Christiania. I checked out the first tier of suburbia as well, and was pleasantly surprised to see that bikes ruled even over longer distanced commutes where cars typically reign.

I snapped a lot of shots, but many were lost in a tragic memory card accident, so I’ve pieced together some contextual shots from the remaining few. As they say, it’s just a reason to pay another visit, right?

A few things worth noting:

a) Everyone cycles. Men in suits, women in heels, grandmothers loaded with a basket of groceries. I saw a JUDGE riding mid-day, clad in official garb! Now, let’s all try to imagine OUR civic leaders eschewing an appointed driver and pumping the pedal! (SF and Sacramento do actually have some, thankfully.) People even cycle holding riderless bikes alongside them.  Bikes have trailers for heavy items, and front bins for toddlers.

b) Bicycles are everywhere. There is not a single stretch of wall surface that doesn’t have a bike leaned up against it, or parked on a rack beside it. Nearly every architectural photo I took at street level had cyclists peddling past. Imagine if every iPhone in SF was a bicycle – that’d be a great parallel statistic!

c) Infrastructure accommodates cyclists. Granted, this was within the city limits, so not major thoroughfare conditions, but bicycle traffic definitely held equal footing. There were traffic lights for cyclists. Delineated bike lanes often had physical separation from vehicle lanes (major routes had raised bike lanes on level with the pedestrian sidewalks, clearly marked), and even dedicated turn lanes.

d) Cyclists are civilized. Not to say that they’re not in other cities, but in Copenhagen it has a definite feel of collective cooperation at work.  Cyclists use hand signals, change lanes with awareness, and read traffic flow like seasoned professionals – no erratic weaving, lurching or impulsive stopping for photo ops (at least not after I learned the consequences!).  I never felt ‘run off the lane’ by aggressive riders, and the underlying order was easy to pick up just by observing a few busy intersections during peak commute hours. This is a social system in place!

e) Cycling is ingrained into lifestyle. The prevailing fashion sense conveys it, from head (although most urban cyclists did not wear helmets) to toe (although I did witness several women riding in seriously stiletto heels – yikes!). There is no outstanding ‘bike messenger’ aesthetic – people are just people, on bikes.

While my week in Copenhagen was blessed with fabulous early fall weather, and my chosen routes were relatively level and well populated by other cyclists, I really felt that what I saw during my rides are indicative of the general way the city’s inhabitants integrated cycling into their daily lives.  I was truly inspired to bring a bit of the Copenhagen cycling flavor to my San Francisco riding experience, so I’ve traded my decade-old heavy hybrid mountain bike in for a bright colored, upright riding, step-through ‘urban’ bicycle that makes me yen to peddle it out to meet friends for brunch, flowered skirt flowing in the breeze.  I will, however, be wearing a bike helmet.

Posted in Urbanism | Tagged , , , | 1 Comment

Revit Language Skills

Posted on October 1, 2010 by nmcclure

“Parlez-vous Francais? Non? Pourqoi pas?”  I spent a week in Paris in 2009, and while I had attempted to dredge up my high-school french vocabulary, I was sadly at a loss to communicate with language-proud Parisians.  I faltered, I feined, lost my confidence and ultimately, I choked, resorting back to English. Thankfully, most people acquiesed politely.

This experience is not unlike that of infrequent visitors to the land of Revit.  Folks who’ve taken the 3-day Fundamentals course from their software vendor, or once downloaded all the tutorials, but after getting revved up for a few days, don’t keep up with it, and when later thrown on a project immersion-style (so often the situation during these overhead-restricted times!) the vocabulary fails them, and there’s a retreat back to CAD.  It’s a law of languages, and being conversant in software languages is no different: Use it or lose it!

And the risk of what may be lost isn’t just in applicable project time. I recently attended an AIA Mentor Group meeting, and the panel discussion focused on the number of currently unemployed designers and architects all vying for the sparse opportunity listings. Literally hundreds of applicants offering a spectrum of qualifications may be reviewed for a single position, and one panelist stated that aside from the most obvious qualifiers of education and applicable experience, that he looks to see what an applicant has done SINCE their last employment position.  Have they pursued parallel interests? Acquired new skills? Brushed up on old ones?

Being between jobs can be the perfect time to get back into solidly learning Revit skills, to strengthen that vocabulary so that if the opportunity to ‘speak Revit’ comes up, you don’t have to resort to flash-cards!

Autodesk has several redeployment offers to make the software accessible, and for discounted training and tutorials. Take advantage of them! And once the tutorials have been run through, keep practicing on datasets you build yourself – model your home, your corner coffeeshop, you last firm project that was documented in CAD. Yes, working on your own will run you into stumbling blocks, but not unlike attempting to read Little Prince en francais, you can take your time with it, research each step through the help files and other sources such as AUGI forums.

I also highly suggest forming your own learning networks – I often attempted to connect sole practitioners who took my formal training classes to trade contact info and meet up weekly to discuss what learning curves and hurdles they hit while modeling on their own. I myself lead a small group of designers – some employed, some not – that meets online via conferencing software once a week. We review issues with their current projects and lay the groundwork for thinking strategically about the next steps. The group is building their vocabulary up, little by little, and are becoming proficiently conversant in their Revit worlds.  All are building their confidence up as well, and as I can vouch for with attempting those new (or newly exercised) language skills, confidence goes a long way.

Posted in BIM/Revit | Tagged , , , | 1 Comment

Revit ‘dummy’ tags

Posted on September 19, 2010 by nmcclure

In the past week, I’ve had two requests for ‘dummy’ tags to use in Revit – something that really makes me cringe. I’m a firm believer that the incredible value of using a database system that Revit is, is in that actual data. ‘Dumb’ tags are against that concept completely. However, after thorough discussion and disection of the issues at hand, I agreed with the feaseability in both of these situations.

Faux Detail References:

One of the teams I work with is still in a transitional mode towards Revit documentation – meaning that they still rely heavily on their existing CAD detail library, and in editing details in that format. While I’ve outlined the process of bringing CAD details into the Revit environment and thereby leveraging the auto-tracking referencing, this particular team has some real world limitations: not enough Revit licenses for their extended detailing support team to work in Revit, and workstations that aren’t powerful enough to manage a large-scale project in full Revit documentation. Therefore, they will be producing CAD details on CAD paperspace sheets, and simply intersplicing the output for their final deliverables.  This IS the real world, after all, and accomodations are necessary.

The challenge wasn’t in making a reference bubble that the team could manually enter in the detail/sheet of the appropriate CAD detail, it was in making the callout regions and section cut graphics by standard Revit means, while applying the manual reference system.  While Revit allows a user to “Reference other view” with both these tools, it has no out of the box (OOTB) means of allowing what the team needed.

Revit’s reference tracking system is one of the most amazing efficiency tools it boasts. I personally have lost weeks of my life to the CAD system of manually tagging and tracking related details to their respective locations on a project plan, and the accuracy of Revit’s system continues to delight me. All that coding that goes into such functionality, however, means that if those items were open to easy manipulation by all users, chances are something would get mucked up in the works, and the functionality hits the skids (the truth hurts!). Therefore, these system annotation items are somewhat protected by a pretty complex layered hierarchy of nested families. In a simplified distillation, it goes something like this:

Separate .rfas create the graphics of the reference bubble, with hard-coded parameters making up the data-drawing labels.

System annotation types designate which of these bubble .rfas will be applied, depending upon the nature of the view being created or referenced.

Appropriate graphics, browser sorting, etc also respond to the nature of the view being created or referenced.

So how was the ‘dummy’ reference accomplished?  I created an .rfa based upon the standard reference bubble, but removed all the standard labels for detail and sheet numbers. In the project, I duplicated the standard callout and section families and created a new type that drew in these ‘blank’ detail bubbles. I created a Symbol of two labels with custom parameters for Detail # and Sheet # to be manually entered by the user.  I created a single drafting view “AAA – CAD detail” to always show up at the top of the list of referenceable views when a user created their CAD-detailed callout/section view.  Once the system recognized the view as a drafting view, it applied one of the detail callout/section types, which was then specified to be the ‘blank’ type by the user. Once positioned, the user then placed the symbol over the blank bubble, and entered in the CAD reference data.  A less than automated process, yes, but the only way to ‘fool the system’ and create manually inputted references.

Faux View Titlebars:

Another team has been very progressive about embracing the methodologies of Revit, and they’ve been quick to adapt to the change in methodology that a new system often requires. They are, however, sticklers about graphic fidelity to their previous CAD production output. Ahhh, such a double-edged sword!

A main sticking point for them has been view arrangement on sheets, and the layout of interior elevations in particular. They prefer all four elevations of a room to ‘unfold’ across a single horizontal, with N,S,E,W designations all united by a single titlebar.  Personally, I prefer this layout approach as well, and I’ve outlined the process for them to assemble the individual elevation views in alignment, and stretch a single titlebar from the initially placed view across all four.  This seemed fine, but the trick of the N,S,E,W designations was pondered.  It either called for a ‘dumb’ symbol to be placed under each view, minus it’s individual titlebar, and manual data entry – OR – (wait for it!) a customized Revit titlebar that drew the directional designation directly from the view title.  We liked that approach, and customized a view titlebar type accordingly. However, that lost the ‘uniting’ single titlebar under them all.  We concluded that leveraging the ‘smart’ tagging approach of the customized individual titlebars was the most beneficial way of using the automation of Revit, and that a manual ‘collector’ titlebar with minimal mis-tracking risk (detail number on the sheet) was the way to go, so I simply created a Symbol mimicing the standard View Titlebar graphics with an instance modified line-length.

So, there’s smart ways to use ‘dumb’ things, all based upon what goals need to be achieved, and where the team is getting the most value out of what IS automated in Revit!

Posted in BIM/Revit | Tagged , | 3 Comments