From Webster:
- Math. a quantity or constant whose value varies with the circumstances of its application, as the radius line of a group of concentric circles, which varies with the circle under consideration
- Any constant, with variable values, used as a referent for determining other variables
- Usage objected to by some
- a boundary or limit
- a factor or characteristic: usually used in pl.
Some of these definitions deal with dimensional characteristics pertaining to geometry. Revit is powerful, especially in the Family Editor, where a distance can be given a name and different sets of values grouped by types.
Another favorite example are the view names and numbering. The annotation, view title, list item in the project browser all use the same property and this property can vary in different instances. In teaching I make sure to explain that these different manifestations of view properties are not coordinated. It is the same information.
So as cool as this is did it go far enough? What other opportunities exist?
An opportunity that has struck me lately is naming. What if we names could contain references to other properties?
When you create a new view and set its view phase filter property to "Phase 1" you may next name this view "Exterior View - Phase 1". <record scratch>Data was just entered twice!</record scratch>.
Would it not be better to name the view "Exterior View - %view phase filter%" or "Exterior View - %view phase%"?
How about naming a family type:
"Casement Window - %width% x %Height%" returns-> 'Casement Window - 12" x 24"'
"Door - Has Vision Lite: %VisionIsVisible%" returns -> 'Door - Has Vision Lite: Yes'
What other areas could leverage parameters? Think of the times you have to go back and maintain something. Where does Revit fail you specific to coordination?
Good topic, Family names and their actual sizes that don't match the type name can be a big problem in our office. Very un-revity.
Would be nice if this is similar to a "Field" in Autocad and could be extended to text notes. For example, we refer to certain details in our text notes sometimes, it would be nice to be able to refer to the actual view number/sheet number listing using %view#/Sheet#%.
How about including the room location in interior elevation view names so we can include this in the view title? (Interior Elevation - Reception)
Unrelated to naming, but I'd also just like to be able to have an element's tag display whatever parameters the family has should we need it. If the family has a length parameter, why can't we include that information in a tag so it is automatically referenced?
Posted by: Donnie | January 25, 2010 at 12:30 PM
Those are some good cases. More access in tags and text especially.
Posted by: Erik | January 25, 2010 at 01:59 PM
I would say access to calculated values in Tags would be invaluable as well.
Posted by: Rafael Alvarez | January 25, 2010 at 02:04 PM
The ability for elements to querry other parameters from different family types for example, Door/Window reference Wall parameters.
Posted by: Tucker | January 25, 2010 at 04:15 PM
You opened a great can of worms that I believe Revit could really shine. Revit's parameters are it's greatest tool in so many respects, but is limited by it's access. Some one mentioned AutoCAD's Fields. Revit's parameters need to function much like the Fields in AutoCAD or better yet AutoCAD Architecture. The ability of Revit Categories being able to see each others parameters would open so many doors. Speaking of doors, being able to use the room number with a suffix or prefix to create the door number and use it in a tag. Enter the data once just like you mentioned...
Posted by: Bruce | January 25, 2010 at 04:15 PM
I agree with the above posters. However I would exercise caution as the structure you are suggestion looks a lot like Bentley and I would not like to see CGF files that reference other CFG files and so on and so on. One misspelling and the whole house of cards comes crashing down and people lose production capability. Move forward cautiously with this
Posted by: Chris Hubbard | January 25, 2010 at 04:31 PM
Yes, yes, Please YES!!!
Everyday I bemoan the lack of functionality broached here. Ecspecially the ability for one family to communicate with another in a project environment.
Also, (a more basic issue really) please don't put default parameters in Families that can't be modified or deleted.
Posted by: Erik | January 25, 2010 at 05:37 PM
This would be exceptional!! Especially if an value in the project could be used, including Shared Parameters!
If this would work for Materials and the other aspects of the project already mentioned this would become an extremely effective way of managing our projects.
Would it be possible to represent this to the users as the %parameter% and through a Dialog book that looks similar to the Label: Add Parameter dialog from the family editor?
Posted by: Matthew Pettengell | January 25, 2010 at 05:45 PM
A UI would be surely be the nicest way to enable such a behavior. Right now this is just a thought experiment but your comments are encouraging and helpful.
Posted by: Erik | January 25, 2010 at 10:57 PM
I'll reiterate Chris Hubbard's comment. Too many dependencies make for a brittle system: it fails poorly. And unlike computers, people can (and often do) make mistakes. A building isn't a program, and sometimes the effort spent to enter "Phase 1" a couple times pales in comparison to the grief caused by someone new to the file who's not 100% familiar with the systems in place.
All it takes is some rookie not paying for a second, and things can get really screwed up. C'mon, you know we've all seen it happen before...
Posted by: David Zeibin | January 26, 2010 at 02:03 AM
Wow, this is the right direction indeed. Enabling wider use of text in parameters and formulae and not least parameter use in a project environment is the true path for Revit. After learning what a family could do, we were all a bit disappointed on the project side. Of course, dependencies can be extremely complex, this is why a "Trace dependencies" command or something with similar functionality would be key to success. It could map out all links in a tree like fashion. You probably don't need to keep track of them all the time, but examine the database as and when the user requires. Think of all the possibilities...
Posted by: Balazs | January 26, 2010 at 05:29 AM
I hear those who call for exercising caution. The problem in these cases are often accidental changes that have large repercussions. One reason a user may do this is the system fails to communicate the amount of data being changed or preview the results of the change. This is perhaps another topic I'd like to discuss. How can constraints and other hidden behavior be made more visible.
Posted by: Erik | January 26, 2010 at 10:40 AM
I like all these suggestion. I totally agree on the caution aspect and the not stated but implied that such functionality should NOT come from some external file. The examples cited by the OP of view names are all internal to Revit. We do not have to worry that changing the name in properties will not work because we forgot to edit some text file. I am thinking of shared parameters here. I would love to see them go away. Way too many ways to mess them up.
Two other items I would love to see: concatenation in parameters (just like in Excel, ParamA & ParamB should give ParamAParamB), and view references in schedules. For example in a door schedule where a typical detail is referenced. This should be a real reference, not manual text input.
Thanks! Would love to see all of the ideas in this post and replies explored fully.
Posted by: Paul F. Aubin | January 26, 2010 at 11:58 AM
All excellent suggestions, especially the concatenation. With Filters and Views, and View templates, and Revits inherent limitation to The Family Catagories provided by the Factory, we use a lot of parameters to control drawings, in terms of finishes, structures, ratings, etc.
It would be great to do away with the Schedule issue of slamming two columns close together and having to make do. TAGS can now read dual Labels, i cant wait until a schedule field / text field can!
Posted by: Aaron Maller | January 26, 2010 at 01:12 PM
I very much agree with the notion of broadening the idea of parameter access in names, to a greater access to data in general. Too often we find ourselves pulling out our hair when we can't access some aspect of model data in the way we need.
Making it work, though, involves much better text support across the board. Formatting is difficult enough as it is now, but mix in parameters with variable lengths, and the wrapping and justification issues get worse.
Not having external configuration files I think should go without saying. The model should stand on its own. Create a class of object in the Project Browser, and put config stuff there. Start with the keynotes! This solves filelocking problems, version concurrency, and they can be in worksets for access control. (And worksets need to be able to be set to be uneditable without someone needing to check them out. Borrowing allows for too many accidental changes).
Parameter concatenation would be fantastic!
Posted by: Joel Osburn | January 26, 2010 at 07:37 PM
I find that some of the most obvious needs are pointed out by those that are just starting to work in Revit. from the mouths of babes. Today I performed a Quickstart - something that we do for all new to Revit project teams. A simple request like giving the user the ability to make all elements on a particular workset or woksets visible but not editable (in the literal sense, not the Revit sense of 'not editable'). Basically just like locking a layer. Another example of Revit not really seeing the grey area.
Posted by: Jason Bailly | January 26, 2010 at 09:15 PM
It would be great if dimensions in the project can be labelled and use formula and parameters and be used as parameter.
exemple
the lengh of a wall labeled : "Longueur" could use the formula "= 1.618 * modulo" where "modulo" is a project parameter.
And the height of the wall uses the formula "= Longueur * modulo".
Posted by: gravelin | January 28, 2010 at 02:44 AM
Family editor constraints in the project environment. Le Corbusier would be proud.
Posted by: Erik | January 28, 2010 at 09:14 AM
Just want to add to the already apparent and longstanding wish of concatenation/string manipulation formulas request. Ability to access similar functionality in the project would also be highly welcome... Looking forward to further discussion on such functionality.
Can we get that by release 2011 ;D I'd be the first to have 2011 installed and be working on coming up with a solution to get rid of 80% of our time per project spent on mapping Revit objects to our internal item codes.
Posted by: DoTheBIM | January 29, 2010 at 09:22 AM
Excellent suggestions.
This ability definitely seems to fit in Revit's Parametric Paradigm.
My concern is that actually using these parameters would be just one more thing added to the calculations that Revit performs and slow the program even more.
Would this be something that Revit has to constantly calculate? Or would the computer processor only deal with the parameters when editing the names/parameters?
…just my two cents.
Posted by: TRC | January 29, 2010 at 10:38 AM
I would recommend being able to reference a view withing a text note. example: See Detail 4/A453 for more information.
Posted by: Weston Tanner | January 29, 2010 at 11:08 AM
This is related somewhat...I wish, as far as families communicating to one another, that we could have the capability to see how much opening or glass (SF) is in a room. For example, if I put a window on a wall, the room adjacent to that window should somehow report the SF of opening in the wall. If we were able to see this data in Revit, we could use schedules to lighting calculations/requirments directly within Revit in a very automated way. I know that to a certain extent, this could/might be achieved using the API with a macro or plugin, but the Revit database aleady contains this information, they just need to report it in the right place for us to use calculated values within a Room schedule.
Posted by: Josh Moore | January 31, 2010 at 05:40 PM