It is hard to really gather my thoughts after such an intense few days, but here goes.
On Wednesday morning, we heard presentations from as impressive group of presenters discussing applications of VDC relating to exterior systems: Will Ikerd (Intertech), Dennis Shelden (Gehry Technology), Scott Mellema (Permasteelisa), Matt Ryan (Webcor), Chuck Eastman (Georgia Tech) and Stacy Scopano (Tekla). Although I spent a decent portion of the morning taking care of BIMForum organizational things, what I heard from the presentations helped put a lot of my work in perspective (speaking both historically and intensity). It was definitely a good idea to start off the meeting with those presentations (compared to in Boston when we ended the meeting with similar presentations relating to steel).
Wednesday afternoon, I sat in on the Process Mapping Task Force where we listened to two presentations related to other process mapping initiatives. The first one was based on a virtual project that Johnson & Johnson, Tocci, KlingStubbins, Gilbane & EMCOR are working on (presentation available here; work product available here). The second one was based on USACE's BIM Roadmap.
Although the discussions of this group are supposed to be related to process, software selection kept coming up (i.e. can the owner dictate a software solution?). I have been thinking about software a lot lately - probably a little too much, actually - so I had a few thoughts on this. When it comes down to it, I suppose an owner can require use of a specific software - directly or indirectly (i.e. by requiring a deliverable in a specific file format). However, requiring a specific software may impact productivity and deadline among other things.
When I think about switching software programs for modeling, viewing, coordinating, etc. I can imagine the learning curve associated to it - especially if it is only for one project. I know that we have developed standards, protocols, and best internal practices for Revit; how would we go about doing such a thing for another software program, while maintaining similar productivity? The use of this program would go on for several years for the GC/CM; construction projects take time (but then again, the use of this program for the FM will go on for even longer)! This of course leads me to think about a potential switch - even if we stopped using Revit on new projects today, we will still be using it for another 2 years on already modeled projects. By that time, any current issues we have with Revit will have already been resolved. So whats the point?
At this point, I should reiterate the title of this post, adding some emphasis to a key point: my thoughts.
More on the BIMForum meeting later.
1.22.2008
BIMForum Miami Meeting!
Although the leadership of the BIMForum met tonight, the Miami meeting officially kicks off tomorrow morning at 8AM.
Attendees and non-attendees alike will have access to the BIMForum agenda and handouts here. As presentations and documents become available, they will be posted, so keep checking the meeting portals! (Thursday meeting portal will be made public Wednesday evening).
Enjoy!
Attendees and non-attendees alike will have access to the BIMForum agenda and handouts here. As presentations and documents become available, they will be posted, so keep checking the meeting portals! (Thursday meeting portal will be made public Wednesday evening).
Enjoy!
1.10.2008
Models From Designers
I love getting models from designers. It isn't as exciting as when we got our first one - I think I actually sprinted down the hall to tell John Tocci about that one - but it is still pretty phenomenal to know that we won't have to do a tedious 2D conversion.
Yesterday, we received the architectural and structural Revit models for a project in preconstruction. Whenever we get a model from an architect, I briefly review it for internal use:
Organization - separate models for structure, architecture & site (just like us!)
Worksets - setup logically and followed well (for the most part) i.e. core items are in the 'core' workset
Geometry - some items aren't model how they will be built i.e. walls spanned the entire height of the building
Allignment - all models line up in Navis - a definite good sign! We'll have to wait for MEPs in AutoCAD 3D to see how well they did that.
Object Nomenclature - a little messy; wall types aren't inherent in the wall names (i.e. walls are named "Interior - Conference Wall" rather than "Interior - 14A"). Wall type annotations aren't 'smart'. This could result in more document discrepancies... There are even walls named 'Generic - 6" '
Assembly Code - does match up with wall function (normal for designers)
Assemblies - are modeled as one object (instead of being modeled in build-able components) - again, typical for designers
I have no complaints about the way they model (well, not too many...). In most cases, I understand where they are coming from. They are modeling to produce a set of design documents. How could and more importantly, why would they anticipate the needs of a builder? (This is very similar to my thoughts modeling philosophy, which I posted over a year ago).
This reinforces the need for standards of modeling for collaboration - I guess we need to hurry up with the BIMForum's Process Mapping Task Force work.
Yesterday, we received the architectural and structural Revit models for a project in preconstruction. Whenever we get a model from an architect, I briefly review it for internal use:
Organization - separate models for structure, architecture & site (just like us!)
Worksets - setup logically and followed well (for the most part) i.e. core items are in the 'core' workset
Geometry - some items aren't model how they will be built i.e. walls spanned the entire height of the building
Allignment - all models line up in Navis - a definite good sign! We'll have to wait for MEPs in AutoCAD 3D to see how well they did that.
Object Nomenclature - a little messy; wall types aren't inherent in the wall names (i.e. walls are named "Interior - Conference Wall" rather than "Interior - 14A"). Wall type annotations aren't 'smart'. This could result in more document discrepancies... There are even walls named 'Generic - 6" '
Assembly Code - does match up with wall function (normal for designers)
Assemblies - are modeled as one object (instead of being modeled in build-able components) - again, typical for designers
I have no complaints about the way they model (well, not too many...). In most cases, I understand where they are coming from. They are modeling to produce a set of design documents. How could and more importantly, why would they anticipate the needs of a builder? (This is very similar to my thoughts modeling philosophy, which I posted over a year ago).
This reinforces the need for standards of modeling for collaboration - I guess we need to hurry up with the BIMForum's Process Mapping Task Force work.
IFCs
I recently received an email from someone at NIST, asking me to look into register for and post on an IFC-BIM Exchange Support Forum. I haven't done either of those things yet - I'll get around to it because I do think that it is important for users with experience with IFCs to talk about them.
But I do have to say that I am a little sick of hearing about IFCs, especially from vendors. We had to use them on a project, and they were really frustrating. The result is that we have very dumb objects in our model. The geometry was preserved, but we have no actual geometric properties (no width, no height, nothing!). We also cannot snap to these objects in Revit, which obviously slowed down our modeling process.
Vendors need to stop saying that IFCs work. They don't. Ask anyone who has used them. The most aggravating part is that they could work if vendors would dedicate to them.
I am clearly not against using something that "isn't quite there" (look at Revit!), but calling IFCs 'experimental' seems generous at this point.
But I do have to say that I am a little sick of hearing about IFCs, especially from vendors. We had to use them on a project, and they were really frustrating. The result is that we have very dumb objects in our model. The geometry was preserved, but we have no actual geometric properties (no width, no height, nothing!). We also cannot snap to these objects in Revit, which obviously slowed down our modeling process.
Vendors need to stop saying that IFCs work. They don't. Ask anyone who has used them. The most aggravating part is that they could work if vendors would dedicate to them.
I am clearly not against using something that "isn't quite there" (look at Revit!), but calling IFCs 'experimental' seems generous at this point.
1.05.2008
Switching from Revit
Over the past year, we have developed standards & protocols based on Autodesk Revit. We spent months creating models in Revit to be utilized on site. Our success at VDC can only be attributed to our hard work and excessive work hours, as well as our ability to develop workarounds. We have retooled existing databases software tools, so that they would sync with Revit.
Unfortunately, it seems that this has all been for nothing (not that we haven't learned a lot, though). In the past few months, we have found flaws in Revit that prevent us from completely implementing 4D and 5D the way we need to.
There is a bug relating to phasing & groups. I don't 100% understand it, but it prevents us from controlling the phase of objects within a group. This is problematic because we need to understand the timing of objects for both scheduling, procurement and cost engineering. This bug extends to instance parameters.
The second major issue is that certain parameters (specifically Assembly Code and Assembly Description) do not export from Revit to Navisworks for certain objects (it seems standard objects). This also affects our 4D implementation and makes it impossible for us to streamline 4D.
Someone else at Tocci put it much more eloquently that I have:
4D: Innovaya can receive the ball, but Revit can't throw.
4D: NavisWorks can receive the ball, but Revit can't throw.
5D: Innovaya can receive the ball, but Revit can't throw.
Autodesk is aware of all of these problems and is working on them (from what I've heard); however, they don't know the timing of a resolution.
So, instead of working on high priority projects this week, I'm going to evaluate Bentley and Graphisoft/Vico. The switch could happen in the very near future, so I need to be prepared to pick a new software platform.
There is a bug relating to phasing & groups. I don't 100% understand it, but it prevents us from controlling the phase of objects within a group. This is problematic because we need to understand the timing of objects for both scheduling, procurement and cost engineering. This bug extends to instance parameters.
The second major issue is that certain parameters (specifically Assembly Code and Assembly Description) do not export from Revit to Navisworks for certain objects (it seems standard objects). This also affects our 4D implementation and makes it impossible for us to streamline 4D.
Someone else at Tocci put it much more eloquently that I have:
4D: Innovaya can receive the ball, but Revit can't throw.
4D: NavisWorks can receive the ball, but Revit can't throw.
5D: Innovaya can receive the ball, but Revit can't throw.
Autodesk is aware of all of these problems and is working on them (from what I've heard); however, they don't know the timing of a resolution.
So, instead of working on high priority projects this week, I'm going to evaluate Bentley and Graphisoft/Vico. The switch could happen in the very near future, so I need to be prepared to pick a new software platform.
Subscribe to:
Posts (Atom)
