Dev Camp AEC Keynote

A few interesting tidbits out of the keynote this morning by Nicolas Mangon.

Point cloud support is coming (someday) to Revit. Nothing specific, in terms of time, but I would say '12 or '13. This information supports my suspicions as in '11 you'll note a bunch of .dll's for "AmberCore" which turns up some interesting Google results.

Another interesting note, it sounds like for MEP '12 we can expect to see a focus on Plumbing/pipe development/improvements after this years focus on M and E improvements.

Autodesk AEC Dev Camp 2010

Spending yesterday, today and tomorrow at Dev Camp. So far its been interesting. Today we'll really get into the "meet" of the classes, I'm looking forward to some solid re-enforcement of what I've self taught myself, plus learning new tips, techniques and best practices.

What is particularly nice is the high ratio of Autodesk staff to attendees, its a great chance to network and really talk about some "under the hood" type stuff.

Guide Grids

I’ve been exploring these a little bit as we get ready to roll out 2011 to the firm. I have to say they are an odd mix of Revit objects and attributes. For instance;

How do you delete a guide grid?

Well oddly enough, to detele a Guide Grid from a project, you simply select it, and delete it! If you have multiple Guide Grids defined you cannot purge them, and they don’t show up in the project browser. They simply exist in the sheet view(s). What is even odder is what this behavior implies. A guide grid is effectively an instance of a datum object similar to Grids, Levels or Reference Planes. There are no type properties of a Guide Grids, there is a single “Type” within a whole project. When you manipulate the Instance Properties of a particular Guide Grid in the Properties Pallette, it updates the Grid in all the sheets you’ve “placed” the grid in. In fact what you’ve really done is actually make that particular instance of the Type Guide grid visible in the particular sheets you assigned it to. You don’t actually place the Grid. What this also means is that the location of any particular grid is based on the origin of a sheet view.

Interestingly enough, if you get to thinking about it, Sheet Views are really nothing more then a Drafting View whose behavior has been specialized to allow Views of the Model to be added to them. They have an origin just like drafting views, but “we” can never see or find that origin perse (its important to note that using the API you can find the origin in both Drafting and Sheet Views, or using a linked DWG).

The point is, that the Guide Grid function operates based on the premise that your titleblock locations share a common origin, much as Grids operate on the premise that your model is built around a commong origin from floor to floor. If you move your titleblock (for whatever reason) within the Sheet View Canvas, the Guide Grid will be in the same place, but not relative to the Titleblock.

What this also means is that even though the Guide Grid uses a very basic implentation of the “Pattern” functionality to create the graphical grid, it effectively represents the coordinate system of the Sheet View(s) with the one minor fact that you don’t know where 0,0 is.

What really gets me about this whole thing is, why implement each individual grid as a separate instance of a single Type? Why not allow multiple Types to be defined? Multiple Types would make more sense in the long run, and would allow for some type of “management” console to see all the defined type at once, and delete/modify, etc. Instead all we get is a drop down in view properties, which in reality is simply turning the visibility of a particular instance on or off. Furthermore, when you click on the “Guide Grid” button once again you’re creating “new” by way of placing a new element of an existing Type. Lastly, this comes back to the “delete” issue. In Revit “delete” can be and sometimes is confused with “removal”. One can easily imagine a user opting to “delete” a grid from a particular view, when in fact they simply want to make it no longer visible in that one view. Hitting delete however may have the un-desired effect of completely removing the Guide Grid from the whole project (which might be a big problem!).

I have to say, the one really nice thing about the functionality they did add, is that if, like us, you’ve added your own “grid” and visibility controls to your Titleblock families (with Symbolic Lines) then you can actually use that to snap to and align your views (or offset them from the grid to a specific point, etc.). What is nice about this approach is that the grid is relative to the Titleblock, so if you move the Titleblock, or for some reason delete it, then add a new one back later, you will always have the “same” grid no matter what.

For now, even though there are some drawbacks in terms of management and printing with our own TB grids, I think I’ll generally stick with them, as it seems to have fewer pitfalls, and is potentially less confusing in the long run, then Guide Grids.