Tuesday, October 30, 2012

Not on Sheets

Let's imagine you've been working on your project for awhile now and your project browser seems a bit out of control. It's pretty likely it doesn't take all that much imagination.

How can you tell which views are properly assigned to sheets and which aren't? I read a post today that offers one solution using a View List, a schedule of views.

You can also use the Project Browser sorting features. All the stock Revit templates include a browser configuration called "not on sheets". It's got a filter looking for views that don't have a sheet name parameter assigned.


If that's true the view remains in the views portion of the project browser. Those that are assigned to sheets are hidden from view. If you are thinking you could do the reverse to see those views ON sheets, really no need. You can just review those by expanding the Sheets portion of the project browser instead.

In fact this segregation lends itself to the notion of using working and production views that I wrote about the other day.

If my role is documentation I can focus on the sheets part of the browser. If I put on my modeler hat then I can move up to the views part of the browser instead. The "not on sheets" browser configuration will strip out all those documentation views for me.

There is also nothing wrong with some naming conventions to help declare their purpose. I like to see user names in working views so we can chase down the person who needed it to see if we can safely remove it. I've met some who manage such things with a scheduled Monday purge of so called working views. Ever run across a project with 200 sections views, all un-referenced? Nah, I didn't think so, your project teams are far too organized and careful.

Many people also use more formal naming for production/sheet views compared with working views. Something like PLAN - OVERALL - FLOOR SIX sure looks more formal than Level 06. If you use the Title on Sheet parameter then it gets a bit harder perhaps. For those just the presence of Uppercase versus lower case can be a subtle clue to their intended use for the team.

A hat tip to a little browser organization!

Friday, October 26, 2012

Pay Content Forward

One aspect of sharing content freely is seeing where things you make turn up. I made a Viewsonic inspired LCD computer monitor years ago and posted it at Revitcity (May 2004 believe it or not!). I routinely see it in models, blog posts, images online etc. Since I made it, it is recognizable to me, but not really distinctively "mine".

It was built with the philosophy of "pretty close is close enough" in mind. No confusion when you see it in a model and few if any challenge it's accuracy or role in a model. It even shows a blue screen and gray "task" bar color when you switch to shaded. Sorry, there is no rendered decal of a Windows desktop, though technically possible. It might be fun to put a Revit 1.0 screen capture on it though?


You may not want to share stuff you make but go ahead share something, not everything necessarily. You may not be able to or your livelihood is derived from selling content. No worries, you'll still get to see your hard work in play. Just get it out there!

Thursday, October 25, 2012

Family Editor Please Respect Visibility Settings

[rant mode on]

I really really really really really wish the family editor would honor the Detail Level settings, as well as Yes/No parameter assignment relationship to elements. It is magical enough working in the family editor environment. When you have complicated geometry meshing with lots of visibility controls and options it would be so helpful if we didn't have to drop it into a project to see if they are working correctly.

Yes the elements turn light gray when Yes/No parameters govern or Detail Level settings, but often it would be so much more helpful if it actually turned OFF!

[rant mode off...maybe...]

Wednesday, October 24, 2012

Why Use So-Called Working Views

When I get to work with people that have recently joined a firm that has been using Revit for quite some time the notion of working and sheet (or production) views is often confusing to them at first. When I first started to use Revit it was just me working on models alone. I didn't compete with anyone for other views.

Enter worksharing (worksets) and now we are sharing all the views of the project with any number of other people. The first view we fight over is the Default 3D view. I want it to show shadows in hidden line with ghost surfaces and Tony wants it in wireframe with all the walls off. The first one of us to make these changes will become the borrower of the view. The other will lose out, sort of. They'll get to see their changes (some kinds of changes, not all) too but Revit won't let them save the changes. They'll see a message declaring this too.

Revit was changed to deal with this conflict better by giving us our own 3D view, adding our Revit username to the default 3D when we create one, by clicking on the Default 3D button. They saw that users were creating and specifically naming their own 3D views that way so they figured, "Hey we can code that in!".

Over time we've learned that having some specific views for modeling activities versus those that we want to rely on for putting on sheets worked to our advantage. It also led me to write about the notion of Revit Roles that I've discussed here before (Modeler, "Documenter", Detailer, and Content Maker)

If I want to change the way a specific floor plan looks I really don't want to have to remember everything that was done to make it correct for the sheet it belongs to. It is easier to just work in a separate floor plan view instead, after all a floor plan is nothing more than a specialized report of the model. Of course View Templates make it much easier to restore a view's settings.

With 2013 View Templates get more aggressive too because they can be assigned to a view and take over many of the things we can alter, forcing users to edit a template instead of just using Visibility/Graphics overrides directly. The change actually enhances or increases the likelihood that working (modeling or personal) views will be useful. Working views don't need to be assigned to a view template because they aren't intended for sharing with others, putting on sheets.

Do you have to use working views and sheet views? No. Can it help improve your project experience, sharing it with others? Probably. It is more complicated, more views to deal with (check out the post by Phil Pleiss about managing views in the project browser), but it does provide the freedom to do certain tasks without the fear of messing up things that people often feel.

Tuesday, October 23, 2012

Surprise You are Now the Borrower

I've run into this in the past but was reminded of it this morning. Using worksets, lets assume you encounter a user that has already borrowed something you want to work on. If you make an editing request but then close your local file before the request is resolved you can end up the borrower of an element, regardless of the fact that you chose to leave.

This happens if they just Synchronize with Central (SwC) instead of dealing with your editing request directly. The SwC resolves the request internally, which grants your request, making you the new borrower, even though you aren't actively working in the project anymore.

This can be avoided if the person you make the editing request from just denies the request before using SwC. So...yes you can be the borrower even if, "But I didn't do anything and haven't even been in the file for awhile".

Thursday, October 18, 2012

Rendering and Revit MEP

I received an email the other day from a Revit MEP user that would like to render some equipment rooms. The wrinkle is that when systems are assigned to pipe and duct and their related equipment the relatively new feature called Pipe Systems (and Duct Systems) override the appearance of connected equipment.

If the equipment you use has material parameters to define what the equipment should look like then it is possible to show both the materials assigned to pipe and duct systems AND what the equipment should look like. Not all equipment has either materials or material parameters though. You like my 4" blue tile covered boiler??


Then you run into equipment that "Breaks Into", like a valve into pipe. The pump and valve in the image above look different but it's really just because I assigned a solid color override to the material. That works for shaded views but you end up with the system imposing the material on the equipment and accessories when you render.


Ideally it would be nice to have an option to tell Pipe and Duct Systems to respect the material assignments of connected equipment. Guess it's a candidate for future wish granting.

Tuesday, October 16, 2012

Watch for Web Update 2

Looks like an update is out, at least for Revit Structure at the moment, the blog BIM and Beam mentioned it.

Thursday, October 11, 2012

Why Does My File Name Include the Word Central

The practice of adding the word "central" to a project file name came about in the early days of Revit to help users see the difference between any stand alone project file, their own local file and the actual central file for their project. Unless you notice a folder with a matching name plus "_backup" there isn't anything obvious to tell us that a file is "special" (central or local file). We used to copy the central file to our own computer and change the name to include our username to identify our local file as different from the central file. With the extra "-central" in the project file name it was easier to see its "specialness".

Since Autodesk changed how to make a local file it is less desirable to add the "-central" to the name. This is because when Revit creates the local file it adds our username to the resulting local file. If we use "-central" in the name we get something like this:

1234 BigProject-central.rvt (the central file)
1234 BigProject-central_Username.rvt (local file, including the -central part)

What made sense then doesn't now.

There are firms that still use a customized process to generate local files (there are other threads about that). For them it may still be advisable or desirable (even required) to continue including the "-central" in the project file name. If you just use the Open and check the "Create New Local" option it isn't as desirable or necessary.

Thursday, October 04, 2012

Load Classifications and Worksets

The early releases of Revit MEP didn't have a method to manage load classifications, they were hard wired (pun intended). It does now.


One downside of various sources of content is the way the family editor (person) assigns the load classification. It can be hard coded into the family (not nice), it can be assigned to a parameter instead (nice) and it can also be assigned a value in advance too (nice or not nice depending on who you are).

Load classifications are part of the project standards workset.


If you choose to be the "owner" of the electrical related project standards and not relinquish them there is still a back door that lets a new family introduce a load classification you may not approve of. Revit only seems to acknowledge ownership if you attempt to alter the existing settings, and that's only true if someone else has decided to make themselves the owner of the workset (Electrical Load Classifications). Loading a new family that has a classification like "Steve's Favorite Motors" will bring it along and add it to the load classifications.

This means trying to keep a handle on your load classifications can be a little troublesome has the project progresses. The electrical design team might behave but all it takes is a rogue HVAC user to load a new single duct VAV, that has its own notion of load classification, into the model (assuming multiple trades in one file).

Further, I think its odd that when I create a new Load Classification (like Steve's Favorite Motors) none of the electrical setting worksets show me as the borrower, especially the one called Electrical Load Classifications! If I change the load classifications I still am not considered a borrower, odd. What is odder still is that the worksets for Cable Tray Settings, Cable Tray Sizes, Conduit Settings, Wire Settings and Wire Sizes DO show me as borrower.

I understand that it might be better to let a family load completely and "sneak" in a new load classification than confront the user with a message about not being able to make a workset editable and refusing to load the family.

Best bet is to require content to be vetted for load classifications before they are added to the project model(s). Provide a list of classifications that the project electrical engineer wants to document. Also provide a set of "in this case, use this classification" examples to make it easier to tow the line.

Wednesday, October 03, 2012

Backup File Numbering

We are familiar with Revit's standalone backup file process. Each time we save it creates a new backup file, based on either the stock setting of 3 backup files or as many as we've chosen instead.


I've never run into a file that used more than the four digits that appears in the file name of a backup file. The other day someone asked what happens at MyProject.9999.rvt. As it happens Revit keeps on numbering and adds a new digit; MyProject.10000.rvt.

Tuesday, October 02, 2012

Interface Inequity - Modify Size

Revit MEP features Duct, Pipe, Conduit and Cable Tray all have a dialog that permits us to edit their information, chief among them is their sizes. Unfortunately the younger brothers, Conduit and Cable Trays, have a extra button, the Modify button that lets us easily change a setting for a size. The older brothers Duct and Pipe don't, pity! It's just like parents to let our younger siblings stay up later and easily modify their size!

In the must be nice category, the Cable Tray size portion of the dialog.


In the wishful thinking category, the Duct sizes.


Also in the wishful thinking category, the Pipe Sizes.


I wish it was as easy to add this sort of functionality into Revit as it was to copy and paste the modify button into these images!! I vote for component size equity!! Let us modify them, let us modify them!

Monday, October 01, 2012

Linked Files with Linked Files

Ran across a recent situation where a good number of units were modelled as linked project files and combined into a "master" file. This master file was then linked into another model. As attached links that meant they would automatically show up as long as the source file was "found" (in a folder it could find).

It may have seemed like a good idea when they started, but the down side is nearly zero control over the nested linked units. About the only way to control what they look like is if every (and I mean every) sort of view configuration you might need in other files that host the combined file are preset in the "master file". The display of nested links can be configured to use the Linked File settings. Unfortunately, this is hard to really accomplish because we might not be able to imagine everything that will need to be done. That means an awful lot of back and forth to get it all to work.

My recommendation? Don't go there...