Orientation is not Managed by View Template

When we choose to assign a View Template (VT) to a View, that makes the template the view's boss. It takes over control of each setting we choose to make it enforce. In this image notice the parameters that are gray, not editable?

Those are being managed by the View Template. I've got to edit the VT to change one of those parameters or use Enable Temporary View Properties to override them briefly.

I noticed yesterday that the Orientation parameter does not behave like other View Properties even when a VT thinks it is in charge of it. This is the VT's dialog showing it is currently assigned to Project North; we can choose either Project North or True North. The check in the Include column (on the right side) indicates we want the VT to take over.

Therefore I find it counter intuitive that we can still interact with and change the Orientation parameter in the Properties Palette even though the VT is in charge.

If the VT is changed the view will follow along as expected. I wouldn't expect to be able to change it back in the View's properties with the VT in charge, but I can. This means the Orientation parameter is affected (managed half-heartedly) by a VT but it isn't truly in charge of the parameter, not like it is for other parameters.

It is inconsistent, perhaps a bug?

Revit 2016 - Rotate Project North

Technically this isn't a new feature. It’s an improvement of the existing tool. In the past this tool did not faithfully rotate all annotation elements consistently. We’d often find some annotation was either not rotated at all or moved into different positions. They've revisited the code to ensure more consistent results. It’s not a guarantee they've resolved everything since they can only tackle issues that have been identified as problems. We are pretty ingenious at doing things with Revit that the developers didn't imagine. Hopefully we’ll find that it is more reliable when/if we need to use it.

Let me take this opportunity to remind you that Revit’s bias has always been to create a model or building with Project North in mind FIRST. FORGET about the real orientation on site, initially (please). That’s what using Rotate True North is for and Acquiring Coordinates.

Those tools existed long before Rotate Project North. In fact it was only added because people can’t seem to remember to start their project using a Project North orientation. If you’re interested in more of my writing about using Shared Coordinates you can check out my blog post summary.

Import CAD - Orient to View

This is what the Autodesk Help documentation says about this feature at the moment.

Orient to View - This option is useful if True North and Project North are not aligned in your Revit project. If True North and Project North are defined identically in the project, then this option will not affect the way the import/link is oriented. The World Coordinate System (WCS) is used to orient the CAD file in the view.

If the current view is set to True North and True North is rotated away from Project North, then clear this option to align the CAD file with True North. If you select this option, the CAD file will align with Project North regardless of the view orientation. Note: CAD files are always imported into the current view from the top view direction. The CAD file is brought into the view assuming that the current view is a top view.

It also does something important or relevant when importing into elevation or section views. When people draw sections and elevations in CAD they are often doing so in the plan orientation of the file. It isn't all that common to see people reorienting their view in AutoCAD and then drawing those views oriented to Front or Back etc.

When we select this option and import such a file into a Revit elevation or section view it will rotate the plan of the CAD file into alignment with the section or elevation view. If not then the imported CAD file is aligned with the plan orientation of plan views and we only see the edge of the files lines in the elevation or section view.

If the option Current View Only is chosen then this On by default

Family Orientation

It is quite common to find the orientation of families confusing, both when we make them and when we attempt to place them in a project. What we consider front, back, left and right doesn't seem to follow consistent logic. Okay, there is some consistency it just seems opposite of what we might expect. What do most of us expect? Speaking for myself at least; Front is the bottom of a plan view, Back is the top of a plan view, Right and Left are the right and left sides of the plan view.

If we examine every family and family template in the stock content we'll find that Front IS at the bottom of every plan view in all of them. The View Cube also matches that convention. The thing that confuses us is that a portion of the stock content has been modelled in the reverse. That which we think of being the front of the object being modelled is the back. Even in those families however, upon closer inspection, we will find that the reference planes are oriented correctly (if they are named at all), the geometry orientation is wrong. The direction the geometry is facing is wrong.

If we consider a chair family most if not all of them are modelled with their front toward the top of the view (which is Back). If we compare that with a desk we'll find that it is modelled with the drawers (can we agree that they'd be the front?) toward the top of the view. These two families oriented this way don't allow the user to place a desk, horizontally for example, and then a chair horizontally so that they are oriented correctly with respect to one another. In the case of this desk there is no visible clue to know which way the desk is facing during placement. We'd be rich if we got a dollar every time we noticed the desk was backward when we open an elevation view later.

Looking at the View Cube the chair looks wrong, but only if we happen to agree the front of the chair is the side our legs are on. In the context of being placed next to a table or desk it means that the chair is facing the wrong side of the desk or vice versa. They had to pick an orientation but in the case of a desk that has drawers they picked wrong. Other work surfaces and tables might not matter nearly as much. It would make more sense to me if the desk were modelled with the drawers facing front, the bottom of the plan view. This would allow us to place a desk and chair and their orientation would make sense regarding each other.

Another apparent mismatch of orientation logic is base cabinet and wall/upper cabinet casework. Base cabinets are modelled with front facing the bottom of the plan view but the wall hosted upper cabinets are facing the back, the top of the plan view, opposite of base cabinets. Placing them in a project however defies the apparent orientation mismatch because the origin of the base cabinet is at the back and it is for the upper cabinet too. This means they orient logically when used together despite being modelled facing different directions in the family editor.

Also contributing to confusion is that the original content for doors and windows all assume that their Exterior side (and Placement Side) is what Revit considers the back side of the family. I've always thought of the exterior side as the Front of a door or window, the side that faces people as they approach the house. A door was the very first family I made with Revit. Afterward I believed that Front was the top of a plan view in the family editor. At least until I encountered enough other families to realize I was wrong.

To appear more consistent, while working in the Family Editor, Autodesk would need to revise most if not all of their hosted content (and others) so that the geometry orientation respects the bottom of a view being the Front view. The placement logic it uses must compensate for the placement side orientation of the geometry not being consistent with the notion of Front. If they revised the orientation of content to please Family Editors then they'd have to be careful to also revise the placement side logic.

Family Templates and View Orientation

An exchange of posts at Revitforum.org with Alfredo regarding family templates prompts this post. The thread began with a question about orientation. I've written about this in the past. I was confused by the use of Exterior/Interior labels then.

I find a fair number of new Revit family editors seem to start out with door families. If that's your first foray into content you might starting thinking the top of the view is "front". It's labeled Exterior. I tend to think of the exterior side of a door panel as the front side when making one. This tripped me up for awhile. I wrote the post thinking the other templates were wrong when compared with the door template, at the very least different. Technically they are all the same, front is at the bottom of the page.

I recently examined every imperial family template (release 2014) that is used for 3D geometry. They all respect the notion of orientation where the bottom of the view is front, the top of the view is back, the right side is ride and left is left. Some templates have labels like Exterior/Interior and Placement Side. In the thread at RFO Alfredo noted that the Generic Model Adaptive template does not respect this orientation. In my view it does but when the template was created the front and back views were named incorrectly. The front view is really the back. If we examine geometry using the view cube we'll find every family will show the geometry the same way when we manipulate the cube.

He also mentioned the Profile Mullion template. They've provided labels to help orient yourself when you sketch your profile. In this image you can see that I've created a bullet shaped mullion profile and applied it to a curtain wall. The bullet ends up on the exterior side.

What is curious is that if the profile is not symmetrical the result is a mirrored condition when applied to the mullion in the project. That's a little unexpected.

If, in an elevation view, I place a detail section that looks up the profile matches what I see in the mullion family.

So we have to twist our perspective around a bit to get a sense of orientation. The short story is that mullion profile is a mirror of what we see in plan with respect to right/left orientation. Exterior and interior are displayed as the labels imply.

Definitely quirky...

In-Place Massing and Project Orientation Inequity

In-Place families are necessary for some geometry, in particular the massing environment. I've always stressed that people should start a project without being concerned about site alignment immediately. Revit was (is) designed to allow us to adjust True North easily after the fact. As I've written before, just make it easy to "draw on paper".

A recent post at RevitForum.org underscores that bias when it asked if the two project orientation tools seem to work differently? Actually it was just focused on Rotate Project North (RPN) and that in-place massing didn't play along when it was applied. Rotate True North (RTN) on the other hand does work.

In this image the massing has been created aligned with the "site" but we've realized that it would be easier to document if Project North were aligned along one building edge.

In this image I've used the Rotate Project North and picked the reference plane I sketched to mark the East/West bearing I wanted. I had to rotate the text but the tool rotated the reference plane correctly but the massing is unchanged.

As I wrote in my reply there, RTN is sleight of hand while RPN is really altering the entire model and related views to change orientation. In other words RTN rotates the world under the building and RPN rotates the building on the world. Rotating the world is actually "easier" (less work) for Revit than grabbing every element and everything in every view and rotating it (the building).

If you heed my Two Pieces of Advice, you'll start a project off better...