So, David Light has done a fantastic job writing up all the major new features for 2012 (link above). So, rather than re-iterate I'm going to dive into some of the features I'm passionate about and give a more in-depth editorial on them...
Point Clouds:
Obviously, I'm on the point cloud bandwagon full bore. So not surprisingly, I'm a big fan of the new point cloud interface in 2012. If you remember from last year, Beck was a beta tester for Avatech's Scan to BIM which brought point clouds to Revit for the first time via the analysis framework. This implementation is much faster and far more flexible as it brings point clouds in "natively". Ultimately, the strategy isn't all that different. What is different is the SPEED! This thing is way faster thanks to the native implementation.
Mmmm... Pointy goodness in Revit - Yes, that is my house. No, you don't want to know how many beers I used to bribe a scanning crew to swing by one afternoon...
Here is a Revit model of my house made by tracing over the point cloud in Revit 2012. I can spin this around, zoom in, and do what I'd normally do in Revit and the lag is only a few seconds despite the several million point visible in the section box. Cut this down to a plan section and trim out some of the points on the sides and it isn't even noticeable. This is a huge step forward in making point clouds usable in Revit.
In plan this works perfectly to trace over, and in section it just looks cool. Matching roof slopes can be a pain, but the trees look so cool I don't care, and the pool makes it look like a beach house in this section - it isn't...
Now, there aren't a lot of object creation from point cloud options in Revit. We can snap to them as we use existing tools and that is about it. I would assume that the next iteration of Scan to BIM will utilize the points in Revit and leverage their existing code to create walls/duct/etc.. from those points as they do now using the analysis framework. (Full disclosure - we're not part of any current alpha or beta testing on Scan to BIM so this is purely speculation on my part!) What the future will hold for tools in Revit remains to be seen, although I have my hopes and dreams to be covered in a later post... All in all, this feature gets an "It's ALL Good!"
Parts & Assemblies:
The other new feature that is "construction oriented" does not get such a glowing review from me. I do want to start by saying that I'm thrilled that Autodesk is considering construction workflows in Revit, and their focus on supporting integrated project delivery in their software is the right way to go. However, the parts and assemblies in 2012 just fall very very short in my book. I'm also not convinced that the construction focus of these tools belong in Revit at all. To me these tools would be awesome in Navisworks, QTO, Innovaya, Synchro, and all the other construction tools we use. On our third party jobs using design team's BIMs we just aren't in the position to open their model and mess with it making these tools useless in a third party construction scenario. Once some of the core issues below are resolved, we'll use the heck out of these on our integrated projects. I'm just not sure how these address the needs of the majority of construction work in the market. Really, these give contractors even more reason to build their own BIMs and ignore the design BIMs, and that is the wrong direction to head.
I'm also really disappointed that these tools were not considered in the light of architectural documentation. Both the parts and assemblies tools have huge potential to improve documentation workflows if used correctly, and there are some seemingly trivial decisions that were made that have effectively prevented their use in this fashion. To be clear, I don't mean that executing any of this was trivial, quite the opposite I know a lot of good people put a lot of hard work into these tools. But, what might seem like a trivial decision such as where do parts fall in the program - their own category or as subcategories under their host object - can have a huge impact on the actual use of the tool. In this case, a seemingly simple decision has basically doomed parts to being unusable for design documentation.
- Parts - The whole concept of parts is that system families that are made up of layers (walls, roofs, ceilings, floors, etc...) can now be broken into their constituent layers or into separate chunks in Revit and modified individually. The workflows I hear the most from the factory are breaking up slabs into pours, and breaking walls into individual layers for construction scheduling and quantity takeoff. But, there are some BIG gotchas in this system.
For starters, it creates duplicate geometry that now overlaps. You still have the original wall and now have additional part elements for all the layers. There is a nifty view control to manage this mess, but it hardly makes it go away. It just hides it in Revit. In other tools this has to be done manually right now - though I would expect them to update their export options accordingly in the near future. Fundamentally, I don't like this workflow. We aren't creating duplicate objects - they are the same objects! The software need to recognize this not ignore it!!! Parameters from the host elements (a wall that is fire rated) need to apply to the parts (this is CRITICAL!). Right now, for construction usage, this is a purely modeling centric solution as it actually complicates and degrades the "I" in BIM. Also, there are restrictions in what you can turn into parts.
So, notice the "N"s. Anything point edited is out of bounds. The real killer is roofs though. I could not find a single way to slope a roof that didn't prevent me from creating parts. Can anyone tell me how many roofs are actually perfectly flat? None? So, for all intents and purposes parts don't work for roofs at all because roofs are never flat. Parts for construction are an unfortunate case of great intentions that result in an epic fail...
How these parts are organized also causes big problems. The factory chose to break out ALL parts into a "Parts" category. So, wall parts, floor parts, roof parts, ceiling parts, any parts all are in the same lump of a category. What does this mean for us? Well, you know all those view templates, VG Filters, Object Style settings, and other visibility controls you use to make your documentation look great? They won't work on parts. Parts are parts are parts. So, all my hopes and dreams of cleaning up tricky wall join conditions correctly (instead of the edit cut profile tool) in plan and in section, gone. I can't have the parts show up like the wall should. It would take hundreds of man hours in training and implementation to get this to work now. If, instead, parts came in as subcategories of the host element they were created from then all this would have just worked. This was a total face meet palm moment for me as a user when I saw how it was done. So, this is a case of parts never being considered as a documentation tool, and therefore not working as a documentation tool despite all the potential.
- Assemblies - On the whole, these get a much better reception from me than parts do. This tool was thought out in some sense in terms of documentation possibilities, and addresses a number of issues I've had with groups for a long time. Basically, these allow you to select objects (including things that are parts of a host element like curtain wall mullions and panels) and call them an assembly. Then, the cool part kicks in. It searches all existing assemblies for matching geometry and information properties and if it finds a match the assembly is automatically turned into an instance of the existing type. If there is no match, then it makes a new type. No duplication allowed. Nifty!
There are really a limited number of things needed to make this an awesome tool. However, there is a potential for confusion. Assemblies are similar in nature to groups, and we as end users have to keep an eye out for where each of these should be used. Why do I say that? Well, assemblies are like groups with documentation in mind, but minus some productivity features. Here is a simple chart:
As a construction tool, everything but the lack of propagation is acceptable. That makes the workflow of managing a large project with many assemblies very difficult, and since the solution for this exists (let us include them in groups!) I'm hopeful it gets resolved quickly (as in a mid year release). Assemblies fall into the almost there category.
There are two limitations that really hurt design usage of assemblies. The first is that the assembly views can only be placed on their own special sheet. If we could make assemblies out of all our storefront in a project, set assembly views of those, and drop them on sheets together along with other model views we have just replaced one time consuming workflow for documenting storefront types with one that is far more intelligent and much faster to boot. The second is that assemblies don't work in design options. This little oversight is a disaster for use in design workflows. You can only effectively use assemblies on things you're pretty much sure of. It is so close, but close only counts in horseshoes and hand grenades. Once again, almost there...
I do want to thank the factory for all the hard work they put into these features, and all the others that are in the 2012 release. I think this is another home run release to follow up 2011, so overall great job to all! My criticism of the construction features is not meant to knock all that hard work, but to hopefully make the tools that much better next year. So, here's looking to 2013.
Adios!
