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.
Then Click on Ghost Surfaces:
A small, but possibly overlooked new feature in 2011 is a change to Text and Labels (you may have already heard Text is going to support bullets, numbering and several other new features). What I want to focus on in this post is the new border feature.
These new tags are pretty straight forward. You have to create a "body" which can hold as many pointers as you like. The pointers allow for the creation of elevation views. There are some limitations as you will see in the video, but overall the implementation is really good (and I wish it would come to section heads too). There is a new property for text and labels that controls the relative rotation of the text to the symbolic geometry. Lastly, the same problem that has plagued section heads, plagues elevation tags too, where masking regions will mask symbolic lines. Thus you either must create many separate masking regions to get all your required edges, or skip the masking regions, which can be a problem in complicated spaces or when floor patterns/finishes are visible in views. See the video for a fairly quick demonstration of the new feature(s).
