Jump to content

VW's new 'BIM in Practice' web presence

Recommended Posts

For all those VectorWorks customers who don?t receive, or pay attention to, eDispatch:

VectorWorks eDispatch Vol LXX December 2007:

For VectorWorks customers involved in the building design and construction markets, Building Information Modeling (BIM) continues to be a major topic of discussion. As people consider how to adopt this workflow in their practice, our support teams have received requests for help in how to best structure drawings for a BIM workflow. To most effectively address these needs, a best-practices team was formed at Nemetschek North America last year. This group has two main goals: to generate information about how to most effectively and efficiently use VectorWorks Architect in a BIM environment, and to communicate with R&D about how to improve our features to best match the needs of these types of users.

This week we're launching our "BIM in Practice? section on our website. This section will be the collection point for our recommendations. We've moved the information from the old BIM page on our website and published the second of our best-practice example files. Jeff Ouellette, whom you may have seen active on our discussion forums over the past year, developed this example to show how to structure a file for a multi-person design team on a 1,000,000 square feet mixed-use development. The accompanying white paper describes the strategy to break down the project into multiple files for a design team and to re-use design components. It shows a fairly standard U.S. building type, but the structure of the document can be applied to many different types of projects.

For those of you who are interested in using a BIM workflow in your practice, we'd love to hear your feedback on our approach. Jeff will respond to comments and suggestions on our VectorWorks Architect tech forum . We're also looking for ideas for our next project. Feel free to let us know the direction that would be most useful for you.


Sean Flaherty

CEO, Nemetschek North America

Link to comment


Excellent effort--kudos to all involved. This sort of thing has been missing for a long time and I hope to get some people involved in comment.

I've begun poring over the white paper of the Ellicot Heights project and am intriuged.

The white paper is well organized and well conceived. Good, clear explanation of what you're doing and some good info I didn't know about, particularly in new applications of resource management. Haven't watched the videos; I'm from the school of processing info through words.

I looked at some of the intermediate files and definitely have some comment, but I spent several minutes waiting for the building model file to load and didn't suceed. I left and will check on it later.

(btw-quad mac g5 2.5 with lot's of ram probably let it go for 10 minutes and left. I opened it on an Intel iMac after 6 minutes. VW upgraded to latest service pack. That file is tough to deal with. I think if it got a more detailed set of annotations it might really clog up. Not sure if this is a practical approach to printing/viewing files)

Having said all that, keep it coming


Link to comment


What kind of data do you need to see/show? I've only scrathced the surface with the big Ellicott Height files; it is only in mid-development. The Alexandria Lofts project is more "complete" but the data of it hasn't been fully "mined". That doesn't stop you or I from doing more, but I'm interested in what that more needs to be.

Part of the purpose of these projects and this forum is to discuss what else needs to be shown or done (to the project or to the software) to fulfill our users' needs for a BIM methodology. I would really appreciate some more detailed input about the desired output.

Link to comment


Thanks. The Ellicott Heights project is BIG. The file "Building_Model.vwx" is big because it contains the entire drawing set and "Saved Viewport Cache" is turned ON. With all the section viewports and rendered viewports, this adds up quickly. Also, the new class visibility controls for design layer viewports is being implemented, which adds even more to the file as each class set for each file referenced in is "duplicated/cached" in the main file.

I put this project together on a 1st-gen MacBook Pro 17" with 2GB of RAM. The main file is quite a struggle even for that hardware. I will say that the new Intel machines make a significant difference.

The size of the file and its speed (or lack thereof) do bring up a good topic for discussion on the best way to parcel the project up to get the best performance. I was operating from one set of assumptions, as stated in the White Paper. Others could be debated and explored.

Thanks for the encouragement,

Link to comment


I'd like to comment on your file setup methodology.

I think there's an alternative way to deal with the layers you're calling "Mod-Slab-#" that's (a) easier to conceive and (b) easier to get useful information out of and © more usable to make changes to. As an added benefit it may make some of the performance issues a little simpler to deal with as there's not so much need to go into the same file for multiple uses.

In all the projects that we work on that are anywhere near this scope we have a file that we call "core and shell". In your flow chart it would sit to the left of your level files and feed information into all of them. This yields a "diamond" shape workflow <> with one core_shell pushing layers out to many level files and one integrated building model file pulling (a) many layers from one core and shell file and (b) one layer from many floor files.

In our working method that file contains the kind of info that your mod-slab layers have, but all the levels of the building are together in one file.

That means that when a change has to be made to either a perimeter object or a stair or a shaft has to be located in the building, the change is made in one file and the user can easily see the context of the change and it's effect on other levels of the building or the interaction between a change in one core element and what's going on in the floor above/below without ever having to go anywhere near our equivalent of your "Building Model" file .

Typically, we suffix the layers "_cs" to clearly show they are coming from a core/shell file. We are not using an integrated bim workflow but this file feeds into the various files that are equivalent to your "Level-X_nnn.vwx" files through WGR and does the exact same thing as the "mod-slab". Annotations that are universal and need to be understood in the context of other levels such as slab edge dimension and slab penetration dimensioning, structural grid notation and property bounds dimensions are about the only notation that's done in the core_shell file. Note that our class setup is a little more comprehensive than yours when it comes to putting various annotations in separate classes.

Typically, the following layers are in a core_shell:





ElevationMarkers_cs (holds a symbol that contains elevation markers so we keep that consistent)

If we're looking to do a visualization of the exterior building we can reference the core and shell file into the 3d model file. Even more importantly to our workflow we can easily reference the core_shell into a seperate RCP and Construction files so 2 people can work on them at the same time.

If I wanted to do an integrated BIM project I'd obviously be well setup to do this by simply making my existing core and shell file contain the 3d data (which it already does to a pretty great extent). And I think I'd be in better shape for visualizing what a change on the exterior of the building looked like without having to go into the entire integrated model to see it.


Link to comment

I can see the logic in both approaches. Which you use depends on how you want to control the project.

As a team member though I think I would prefer to be working on a whole area of the project rather than being assigned to only do one particular aspect of the project (eg. ceiling plans). There might be more management required in Jeffrey's method but I would think the team morale would be higher because everyone would have a part of the project that they 'owned', and no one would be assigned to only dealing with the drudge repetitive parts of the project. In my experience a happy team is likely to be more productive.

Link to comment


I don't understand your feelings that I am ignoring something. The sample projects (Alexandria Lofts and Ellicott Heights) offered for download (the project VWX files in addition to the PDF files) on the new "BIM in Practice" web page are fully modeled. They contain extensive amounts of 3D data. They make heavy use of our parametric objects, doors, windows, spaces, and walls, including structural members such as joists, beams, and columns, that contain record formats for a wide array of data. They have a few examples of interactive database worksheets.

I've explained in the descriptions and white papers that these examples are not exhaustive in their presentation of data and drawings, they are not "final quality" construction documents. But, they contain enough information and examples to lead our users down the path.

These projects, with more in the pipeline, will be the basis for much of our research and development of VW capabilities and user needs. But user input and precise critique of these projects is crucial, otherwise all we can do is blindly speculate about what those advancing needs and capabilities are. I believe that this is an excellent opportunity for our users to actively and constructively engage NNA in the discussion about workflows, data, and tools needed to "do BIM" with VW.

As I said earlier, I am open to suggestions for information that our users would now like to see be extracted from these sets of sample data. Are there particular drawings/model views that you would like to see? Are there particular schedules/datasets that need to be shown? If so, what are they and what format would you like to see? Are there particular methods of modeling, scheduling or presentation that you would like highlighted, explained, or expanded?


Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...