Like many others, I recently read AECbytes "tips and tricks" on the Workflow Between Revit Architecture and Inventor.
I was a little disappointed because the article focused on a use of the workflow that doesn't come close to maximizing Inventor's value. The article didn't even mention the most valuable utilziations of the workflow.
I will be able to speak to this more specifically at a later date. In the meantime, I will say that Inventor can leverage design content from Revit, create fabrication-ready content and then has the ability to feed that content both back into Revit as well as into CNC-fabrication systems.
10.28.2008
10.10.2008
BIMForum DC Meeting - BIM WITH OTHERS
I normally try to summarize BIMForum meetings, but this time I don't have to..because the meeting was popular enough for someone else to! Thanks James.
10.02.2008
Satisfaction of Clash Detection
Yes, clash detection is a low hanging fruit. Anyone with all trades modeled and a license to NavisWorks can do it. But here’s the thing about it – it’s really really satisfying.
We just finished “clashing” design-intent systems for the Crate&Barrel project. The process is straightforward (although a bit tedious): Clash, Review, Discuss, Report, Resolve, Recheck Clashing is the easy part. Select the disciplines and click go.
Reviewing is one of the most time consuming steps; the VC modeler found hundreds of clashes in each batch, so had to review each, clean-up the view to actually see the clash, locate the clash in comprehensible terms (Level 2; Grids Y & 8A versus Navis’ x/y/z: 345.7, 10.2, 627.4), and then determine is the issue is legitimate (i.e. is it a supply pipe running through the cavity of a wall or a sanitary pipe running through a piece of duct work?). Many clashes are also reported several times, so those are grouped (by renaming them). We also like to group clashes based on location). This generally whittles clashes down from 200 to 20.
The team (including PM & super) discuss the actual clashes, so they can recommend the solution they would like to see. Since this is design-intent coordination, we don’t actually have subcontractors on board – if we did, they would definitely be part of the discussion. The other time consuming part of this is reporting. The VC modeler put together DCRs, and then sent those to the design team for review. Since the design team is still hosting the model, they will take care of the ‘resolve’ part.
After they’ve resolved the issues, they send us an updated model, so that the VC modeler can do a quick ‘reclash’ and make sure that all issues were resolved, and that no new issues have come up. Sometimes is nice to work on something linear, with a well-established process and a clear deliverable.
We just finished “clashing” design-intent systems for the Crate&Barrel project. The process is straightforward (although a bit tedious): Clash, Review, Discuss, Report, Resolve, Recheck
Clashing is the easy part. Select the disciplines and click go.
Reviewing is one of the most time consuming steps; the VC modeler found hundreds of clashes in each batch, so had to review each, clean-up the view to actually see the clash, locate the clash in comprehendible terms (Level 2; Grids Y & 8A versus Navis’ x/y/z: 345.7, 10.2, 627.4), and then determine is the issue is legitimate (i.e. is it a supply pipe running through the cavity of a wall or a sanitary pipe running through a piece of duct work?). Many clashes are also reported several times, so those are grouped (by renaming them). We also like to group clashes based on location). This generally whittles clashes down from 200 to 20.
The team (including PM & super) discuss the actual clashes, so they can recommend the solution they would like to see. Since this is design-intent coordination, we don’t actually have subcontractors on board – if we did, they would definitely be part of the discussion.
The other time consuming part of this is reporting. The VC modeler put together DCRs, and then sent those to the design team for review. Since the design team is still hosting the model, they will take care of the ‘resolve’ part.
After they’ve resolved the issues, they send us an updated model, so that the VC modeler can do a quick ‘reclash’ and make sure that all issues were resolved, and that no new issues have come up.
Sometimes is nice to work on something linear, with a well-established process and a clear deliverable.
We just finished “clashing” design-intent systems for the Crate&Barrel project. The process is straightforward (although a bit tedious): Clash, Review, Discuss, Report, Resolve, Recheck Clashing is the easy part. Select the disciplines and click go.
Reviewing is one of the most time consuming steps; the VC modeler found hundreds of clashes in each batch, so had to review each, clean-up the view to actually see the clash, locate the clash in comprehensible terms (Level 2; Grids Y & 8A versus Navis’ x/y/z: 345.7, 10.2, 627.4), and then determine is the issue is legitimate (i.e. is it a supply pipe running through the cavity of a wall or a sanitary pipe running through a piece of duct work?). Many clashes are also reported several times, so those are grouped (by renaming them). We also like to group clashes based on location). This generally whittles clashes down from 200 to 20.
The team (including PM & super) discuss the actual clashes, so they can recommend the solution they would like to see. Since this is design-intent coordination, we don’t actually have subcontractors on board – if we did, they would definitely be part of the discussion. The other time consuming part of this is reporting. The VC modeler put together DCRs, and then sent those to the design team for review. Since the design team is still hosting the model, they will take care of the ‘resolve’ part.
After they’ve resolved the issues, they send us an updated model, so that the VC modeler can do a quick ‘reclash’ and make sure that all issues were resolved, and that no new issues have come up. Sometimes is nice to work on something linear, with a well-established process and a clear deliverable.
We just finished “clashing” design-intent systems for the Crate&Barrel project. The process is straightforward (although a bit tedious): Clash, Review, Discuss, Report, Resolve, Recheck
Clashing is the easy part. Select the disciplines and click go.
Reviewing is one of the most time consuming steps; the VC modeler found hundreds of clashes in each batch, so had to review each, clean-up the view to actually see the clash, locate the clash in comprehendible terms (Level 2; Grids Y & 8A versus Navis’ x/y/z: 345.7, 10.2, 627.4), and then determine is the issue is legitimate (i.e. is it a supply pipe running through the cavity of a wall or a sanitary pipe running through a piece of duct work?). Many clashes are also reported several times, so those are grouped (by renaming them). We also like to group clashes based on location). This generally whittles clashes down from 200 to 20.
The team (including PM & super) discuss the actual clashes, so they can recommend the solution they would like to see. Since this is design-intent coordination, we don’t actually have subcontractors on board – if we did, they would definitely be part of the discussion.
The other time consuming part of this is reporting. The VC modeler put together DCRs, and then sent those to the design team for review. Since the design team is still hosting the model, they will take care of the ‘resolve’ part.
After they’ve resolved the issues, they send us an updated model, so that the VC modeler can do a quick ‘reclash’ and make sure that all issues were resolved, and that no new issues have come up.
Sometimes is nice to work on something linear, with a well-established process and a clear deliverable.
From Tape measures, string & stakes to models, lasers & robotic Total Stations!
One of the ways we are using the model in the field on the Autodesk project is layout. Rather than rewrite an explanation of what we did, here is what Rich (the APM on the project) put together to communicate the process.
Layout Prep: Model & Robotic Equipment
Construction Phase: The Layout Begins
Design Phase: It all begins with a site survey (or this case, an integrated site survey & laser scan)…
Once the survey & laser scan are complete, they are imported into the model, to provide both existing conditions and tie the model into real world coordinates. The laser scan allows the team to understand the exact geometry in the existing structure so that as they lay in components, there are fewer size inaccuracies.
In short, the laser scan is the world’s best as-built; down to a fraction of an inch!
Layout Prep: Model & Robotic Equipment
First, the team must decide what geometry will be extracted from the model and marked in the actual building: floor opening, partition locations, penetrations, lighting fixtures, critical ductwork, and the list goes on. After the components are selected, points are marked in the model. [LH add– for the first layout mobilization, we are only laying out partitions and demo work; we will do RCP components] These points become the basis for layout once in the field. Once all points are identified, the information is imported into a robotic total station, layout equipment. Since the process began with a site survey, the total station can translate the points in the model to points in the building.
Construction Phase: The Layout Begins
Tocci, armed with a model containing the latest (and final!) design content, begins the layout process. First step: establish the same control points that were used during the initial survey/scan of the building. Once the points are established, the layout team begins marking all points that were preselected in the layout drawings. As these points are marked, the design team takes a few choice points to check and compare with their design – simple check and balance. Once the architect blesses the layout, all points are connected, lines are snapped and the layout is complete and ready for construction.
The benefit: layout can be completed prior to any interruption from construction activity, allowing for a greater level of detail, not to mention that it is being extracted directly from the team’s model.
Model Compare
About a month ago, Revit released a few plugins for Revit MEP & Architecture – I think they have been available for Revit Structure for a while. We were particularly interested in one tool called Model Compare, which “provides a functionality of comparing two projects defined in Revit products. The comparison results will be provided in a form of an html report and differences between projects will be highlighted.” (I can’t remember where I found that description, but I won’t pretend to plagiarize.) Sounds particularly promising because we are desperate need of something that can help us compare two models.
As it turns out, although the tool does compare two Revit projects, I don’t think the VC modeler who tested the tool would use the term “functionality” when describing it.
After reviewing and discussing the tool, we found a few issues with it, which we brought up to Autodesk:
- It is difficult to tell what has changed regarding a particular object. The tool only supplies Family, Type, & Revit ID of each “changed object”. The tool does indicate if an object is new to a model, but other changes aren’t called out – it would be helpful if it could define whether something moved or was joined or type changed or something.
- It is really difficult to identify where the object is located. If nothing else, add Level (and other parameters – selected by the user). OR, include a ‘Create a new view in the Revit model that zooms to the specific object and hides any objects that are in the way’ button – kind of like Architectural Design Studio. I love that button.
- It would be helpful if users could (easily) customize and select rules to look for only specific objects or specific changes (i.e. find out what walls have moved). We would also be interested in using rules to group changes (i.e. group all changes within 6” of each other that are the same type of change as a single change).
- Reports should be customizable to fit in the reporting standards of various companies. Although, we take the output as is, if we could add other parameters to the items.
One good point that Autodesk brought up in our meeting (and we agreed) was that the tool was originally designed for structure, so it contains the functions needed for comparing structural models. I think this tool could be very valuable, especially since we are starting to receive models from designers, but aren’t necessarily sharing in real time for all projects. How else can we quickly evaluate what has changed since the last submission? At the same time, it needs a little it of work to make it ready for use in production for models created in Architecture and MEP.
As it turns out, although the tool does compare two Revit projects, I don’t think the VC modeler who tested the tool would use the term “functionality” when describing it.
After reviewing and discussing the tool, we found a few issues with it, which we brought up to Autodesk:
- It is difficult to tell what has changed regarding a particular object. The tool only supplies Family, Type, & Revit ID of each “changed object”. The tool does indicate if an object is new to a model, but other changes aren’t called out – it would be helpful if it could define whether something moved or was joined or type changed or something.
- It is really difficult to identify where the object is located. If nothing else, add Level (and other parameters – selected by the user). OR, include a ‘Create a new view in the Revit model that zooms to the specific object and hides any objects that are in the way’ button – kind of like Architectural Design Studio. I love that button.
- It would be helpful if users could (easily) customize and select rules to look for only specific objects or specific changes (i.e. find out what walls have moved). We would also be interested in using rules to group changes (i.e. group all changes within 6” of each other that are the same type of change as a single change).
- Reports should be customizable to fit in the reporting standards of various companies. Although, we take the output as is, if we could add other parameters to the items.
One good point that Autodesk brought up in our meeting (and we agreed) was that the tool was originally designed for structure, so it contains the functions needed for comparing structural models. I think this tool could be very valuable, especially since we are starting to receive models from designers, but aren’t necessarily sharing in real time for all projects. How else can we quickly evaluate what has changed since the last submission? At the same time, it needs a little it of work to make it ready for use in production for models created in Architecture and MEP.
What Happened To the "Single Model"? (And Co-location, part 2)
When we started the Autodesk project, we assumed that the project would use a single model (comprised of several Revit files, of course) during design and construction. Not the case.
The short answer: M/E/P/FP
The long answer: Our subcontractors, who are “BIM-enabled” and have been using 3D programs for quite some time, cannot use Revit MEP. There are the obvious reasons of the lack of content in the library, but the real reason is software functionality: Revit MEP cannot do the appropriate calculations and Revit MEP doesn’t support spooling, an important function for pre-fabrication.
Because of this, for the past few months, two models have been developing concurrently and separately: the engineering model (Revit) and the fabrication model (CAD-MECH, Hydra-CAD, etc.). Coordinating the content to make sure they are identical has been quite an effort, and we have had issues with it from the start. It is near impossible to verify that every tweak and change that KlingStubbins made was communicated to the subcontractor - tools like Model Compare work in concept, but not in reality, when design is moving so quickly.
The solution came from the subcontractor and ended up being quite obvious and simple – short-term co-location. For two days last week, the HVAC engineer and subcontractor worked side by side at KlingStubbins Cambridge (the engineer is actually based in
It was the most logical thing – and it was definitely an “IPD success moment”.
Subscribe to:
Posts (Atom)
