When you apply an instance parameter to a strong/weak reference plane you'll get grips that let you alter the element directly in the view. When you do this to a reference line you get them too. There is a difference between the two Reference types in how they affect the grips though. Here's a pair of "desk" families. Compare the two forms in the image below, look carefully at where the grips are located in this one.


If you build the "bones" with Reference Lines and limit them to the size of the geometry they are meant to constrain you can define where the grips are display with much more control.


Don't worry, be "Grippy"!

Worth an echo. Ryan at The Revit Clinic wrote a post this morning that lists the order of power, the pecking order, the order in which visibility settings and override tools stack up...who wins when multiple things are applied. Good info, check it out! Here's the list...you need to read his post to get the graphics.

(10 is the lowest and 1 is the highest, using walls as an example)

1. Line Work Tool
2. Override Graphics in View > By Element > Halftone
3. Graphic Display Options – Silhouette Edges
4. Override Graphics in View > By Element
5. View Filters
6. View Depth – “Beyond” Line Style
7. Phasing Graphic Overrides
8. Visibility / Graphic Overrides > Override Host Layers > Cut Line Styles
9. Visibility / Graphic Overrides > Projection \ Cut Lines
10. Project Object Styles

Alternate title, "Getting What I Want"

I wanted to show a parameter for Mounting Height. I needed it assigned to a variety of elements. This isn't hard for families that are not hosted. Face-based families on the other hand seem to know what their "Elevation" value is but they are uninterested in sharing that data with a schedule. It's just not listed in the Available Fields list. Mean Revit!

This is a story of a white knight coming to the rescue, or rather Whitefeet coming to the rescue.


Obviously not the cat, I must mean the tools that Mario Guttman has made available to us via his alter ego "Whitefeet Tools". To get what I wanted I created a shared parameter called Mounting Height and added it to my project. For this post and this example I've assigned it to the cateory Data Devices. Once that's in place the steps are pretty easy (apart from getting the tool installed).

You either select all the devices first or just tell the tool to apply it to everything in the model. You start by running the Parameter Tools.


Next you click the Math Calculation button.


Now you've got to fill in some blanks and click a button.


When your information matches the image (change the category appropriately, I show Security Devices for example, Obviously this picture and the next one don't sync up, taken at different times).

Once the routine runs you can close the open dialog boxes and check the results. Cool eh?


Want to watch a video?

Phil Read was instrumental (pun intended) in selecting the entertainment for the next RTC in North America. He wrote a nice post about it on his blog this morning, Read all About it. BIM and Bluegrass in Stone Mountain!

Since I recently wrote a series of posts about them I thought I'd mention yet another source of information about them. Daniel Stine wrote an article recently for AECbytes. Check it out!

Shaan Hurley posts about Autodesk's latest milestone...time flies. I stole this picture from his post...founders "floating" in air.


Happy Birthday Autodesker's, don't eat too much cake!

I've not mentioned subsequent updates for this IFC based model viewer since my original post when it first became available. I received an email the other day letting me know that they released version 1.4.


This release includes enhanced presentation tools and they are really pleased to provide a new dedicated UI for Windows tablets! That should help focus effort on field applications?


A day late and dollar short, they ran two webinars yesterday...should have mentioned this sooner, sorry!

If you'd like to check out some images, CLICK HERE.
Want to read their PRESS Release?

Consistency, CONSISTENCY, consistency...

This post is the result of noticing that families that were using a specific group for some parameters were not showing up in the correct group once they were added to a project.

When you create content the names you use for parameters is one thing to worry about. The Group you assign them to is yet another. We don't get much control over how we present parameters to our users, but Groups are one thing we do get some say about. We can even change them without starting over, compared with getting the parameter name or data type wrong.

If you'd like all your content to show the same grouping you'd better be consistent. Then again even if you are you may not get your way though. I should explain myself now?

Here's a parameter called "Mounting Elevation". It's neatly tucked away in the "Construction" group.

Curious about why I'm using Mounting Elevation when you can clearly see Default Elevation just above it? I can't tag something with the Default Elevation parameter (Data Devices in this situation), it's not among the parameters available in a tag family. I'm using a shared parameter for Mounting Elevation and "connecting the dots" with a formula that is equal to Default Elevation.

I loaded it into a project and all is well. A bit later I notice this. The parameter has wandered into a new group called "Dimensions". Hmmm...


I went back to the beginning, just like Vezzini told Inigo he should. I started with a blank project template and a single family. I added a shared parameter for "Mounting Height" and assigned it to the "Construction" group. Parameter showed up as expected. I went back to the family and tried to change the group to something else. Loaded back into the project, no respect...parameter still located under "Construction". Apparently once the project captured the group, it stuck, even if I change it in the family and reload it.

Next I tried adding a second family that used the same shared parameter but assigned to a different group, no change. Still assigned to the original group. Hmmm... So how did the parameter move?? I started to think that maybe I assigned the parameter to the other group originally and later decided to use "Construction" instead. That was so hours ago, don't really remember now. Just not sure anymore.

Let's mix it up a little with Project Parameters. When you use a shared parameter in your family Revit is kind enough to make them available in schedules without doing anything extra (except for titleblock families, they are a special case). I thought I'd try adding the same parameter to the project and assign it to the group I really wanted. Aaah... the parameter moved to the group I wanted!


If I edit the Project Parameter and change it again it moves to the new group. Well that's consistent at least.


Fire Protection probably isn't the best group to use though eh? My lesson learned from this fun is to think a bit harder about the groups I want to use earlier and to be really sure I'm happy with the setup before putting it in a real project. If I don't I'll either have to live with it or just add the parameter to the project too (which isn't really a hardship even if it isn't technically necessary).

Please respond to the new survey regarding schedules for Revit if you have any notion that they could be better.

David Conant wrote something that appeared on Inside the Factory today called, "Revit Schedules, A Love Hate Relationship". He also wrote the following text at the user forums Revitforum.org and AUGI.

To ensure that Revit can meet current needs and has the capacity for future ones, the Revit team periodically revisits basic features. We are currently gathering information about schedules and similar data reports. This is part of an effort to understand the full range of needs you, the users, have both for the data you want to present and how you want to present it.

If you are willing to help us, please use the link below. It leads to a short survey recording basic demographic and usage information and a link to share samples of your work. I know that many of you have expressed your needs here and in other forums so this may seem redundant. We follow those discussions closely. The survey method is very helpful to us as it provides information in an organized and analyzable form. All work collected will be used by Autodesk for internal research only and will never be shared without your permission. ~ Thanks in advance for your help.

CLICK TO RESPOND to the SURVEY

David Light wrote a post about getting stairs to display better when color fill legends are involved. Then Brian Mackey wrote a post to offer another solution. David's approach involves using a solid fill and matching color to "blend" the color fill and the solid fill colors. Brian's involves using the new "Ghost Surfaces" feature.

To offer my two cents I wrote a comment to David's post after reading his. I mentioned what happens when we use the "Transparent" option for categories in Visibility/Graphics or using Override Graphics in View feature > By Element.

This is what you see on screen (using the "Transparent" option to "Override Graphics in View > By Element")(uh oh):


And this is what you get when you print (oh? okay):


Intrigued because I didn't bother to try the approach Brian suggested, I tried it. Using the "Ghost Surfaces" option to "Override Graphics in View > By Element" you see this on screen (looking good):


This is what you get when you print (oh, not so good):


Tag...you guys are "it"! :)

or alternate title, "Road to Recovery"

When you don't have access to the original Shared Parameter's file there are two ways to get to it, via a family or in a schedule. Either way you need to be able to “touch” the parameter so you can use the Export option for shared parameters. Revit will add the parameter to the current shared parameter file you are using.

In a family you need to open Family Types, select the parameter, choose the Modify button.

In a project schedule you need to take a look at the view properties for the schedule, view the fields, pick the parameter, then click Edit.

In either case you just need to click Export and Revit will warn you that it will add it to the current shared parameter file you are using.

 

If the Export button is not active it is because you don’t have a shared parameter file selected yet. You’ll need to do so first. Go to the Manage Ribbon > Settings panel > Shared Parameters button, browse to find it or create one from scratch.

The only family type that doesn't play along with this scenario is titleblocks. Shared parameters that are used in titleblocks must be "connected" to a project by adding the shared parameter to the project as a project parameter too, since titleblocks are sort of a "tag" for views.