Announcements
Welcome to the Revit Ideas Board! Before posting, please read the helpful tips here. Thank you for your Ideas!
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

More BuiltIn Parameters...

More BuiltIn Parameters...

Rather than rely so heavily on the Shared Parameter file... ADSK should just add in (lots of) industry standard parameters as Built-In parameters. The shared parameter file is (was) a necessary evil to coordinate tags and families.

  • Build in more parameters to the family templates. Not things like "Frame Width" in the door template that can't be scheduled or tagged.
  • Eliminate project based parameters like "Frame Material" from doors that is created when the family is loaded. These belong in the family template so they can be preset. Everyone just ignores this parameter anyway. Gibberish.
  • More project based info. How about all the code information as fields that can be used for calculations. Right now I have to make a bogus schedule for Analytical Nodes to I can create this sort of data. How about a project team directory I can place on the titleblock?
  • Add more tag templates to resolve the coordination of Built-In parameters. For each family template category, there should be a tag template.
  • Simple stuff like NCS discipline and discipline designators for sheets? Why have every firm make there own parameter with a different name and GUID? How about an index number and sheet x of y for sheet numbering.
  • OpenRFA.org tried to control the shared parameter Tower of Babble, but it isn't too progressive and the information there is thin and not really going anywhere.
  • Maybe just start with the crappy parameters the government wants? They area idiotic, but the Corps wants then. Everyone making these as shared parameters with different GUID is stupid.
  • A cloud hosted parameter database of shared parameters to maybe give the industry a little more consistency. No really one uses manufacture created families because it takes longer to clean up the parameters than to do it yourself.
  • The parameters are the object model. They are the I that make BiM BIM.
5 Comments
pieter1
Advisor

You mention 'the code' and 'the government' but there are thousands jurisdictions having authority all over the world. Are you suggesting to include all possible data for all these codes as built in parameters? I fear that would lead to thousands parameters which would often compete/contradict each other.

 

Also, what a parameter actually means can be very different. For you, 'Door Opening' might mean the rough opening, for me it might mean the actual opening (depends on region, discipline and even the office). I might need it as a type parameter, you as an instance. I might want to add a tooltip to it, or change the data type.  Or rename it so my users understand what it's for. Or hide it if it's not applicable. None of these options are available for Built in parameters.

 

Therefor, I feel that the number of Built In parameters should be as limited as possible (built-in meaning: hardcoded) and only used for special stuff like Level, Scale, ...). 

 

However, if you're instead proposing to just have better regional templates that have already set up the right parameters appropriate for that region/discipline: more power to you 🙂

 

 

aaronrumple
Enthusiast

ADSK already provides many localized versions of Revit. Plus imperial and metric. Rolling out parameters such as occupancy type, don't limit what info goes there or how it is related to the code. As an example - doors already have fire rating. That's not the same the world over. But usable the world over.

 

You second point is exactly what needs to be avoided. Otherwise the information isn't ubiquitous, usable or understandable by all. Maybe when you create a door you really use the Window template and window placement tool? Of course not. At one point Revit just had Width for doors. Now it has Width and Rough Width. We all get that and it works. It is an industry standard. Both are in the template as type parameters. But can be switched to instance. (In fact I was just doing that moments ago.) They can be type in that family, instance in this and everything still works. It is just data.

 

In early releases of Revit, there was only Width for doors. So people made up "Rough Opening", "RO", "R.O." (with or without space?) . Everytime someone did this it was a different GUID. That's a mess to manage as an industry. Should ADSK remove Width and Rough Width from doors and let everyone make up their own fields? Of course not.

Doors are a great example. They are pretty similar the world over. American doors have square edges. Italian doors like their Rabeted frames. The English would prefer a rebate. Russians like to upholster their doors. But they all do pretty much the same thing. 

 

Imagine if every door on the internet you download was built the same way with the same data.

 

And yes - all of you not filling out the tool tip for your parameters - shame on you.

pieter1
Advisor

@aaronrumple  I think we can agree to disagree 🙂 And that's totally fine, that's what the idea station is for: to propose and debate ideas.

 

Just a few thoughts: 

 

The reality is that for a huge portion of the world, there is no localized version. https://knowledge.autodesk.com/support/revit-products/troubleshooting/caas/CloudHelp/cloudhelp/2019/...

 

For example, there is no Revit version for my mother tongue (Dutch). Are you suggestion ADSK releases dozens more Revit localized versions? If you read the changelogs you'll notice these localized versions actually require quite a bit of bugfixing/maintenance. So that's time that can no longer go to new features (there are +6000 ideas on this station right now).  

 

Or are we supposed to assimilate and use the English terms? Width and Height might be obvious, but things like 'sill', 'rebate', 'miter' and evening 'rough opening' are not as obvious as you might think. 

 

If OTB parameters could be

  • always tag-able / schedule-able 
  • renamed
  • hidden
  • put in a different parameter group
  • set to instance/type (I'm aware that since a few versions you can change some of them)
  • have a custom tooltip

I would be more convinced. 

 

You mention occupancy, but for the Belgian code that field would be pretty much useless. We would need a field that is driven by a formula that would calculate the max possible occupancy based on room type and area. That can be done through a formula field in the schedule for example. The OTB occupancy parameter would just be there to confuse people.  

 

I don't understand why you're against the shared parameter file. People who want to use it can, but I don't see any point in forcing people to use a system that doesn't work for them. All that will happen is that people will find workarounds.

 

From where I'm coming, the idea "Imagine if every door on the internet you download was built the same way with the same data." is a utopia that's just unrealistic.

 

There's actually quite a few ideas on this platform that ask for the exact opposite: 

 

 

 

 

 

aaronrumple
Enthusiast

"You mention occupancy, but for the Belgian code that field would be pretty much useless. We would need a field that is driven by a formula that would calculate the max possible occupancy based on room type and area. That can be done through a formula field in the schedule for example. The OTB occupancy parameter would just be there to confuse people."

 

Now - see - that is exactly the same thing done in the US. Room Type x Area = Occupancy. (Of course that Occupancy can't be tagged - which we have to do - because you had to make a calculated field.) And from my travels, pretty common around the world. Why should everyone start from scratch? Stick the field in. Let it be driven by a formula. Or not. Just give me a place to stick data I can depend on.

 

From the viewpoint of someone developing custom content, you know your stuff isn't going to be universally usable except for the information in the most rudimentary BuiltIn parameters. If I manufacture doors and make a parameter called "Under cut" and another company makes a parameter called Undercut, another does something like Bottom_Gap and another doesn't have the field at all, all of that information is useless. So all that data is lost. Or people spend a few hours rebuilding the family to make it work with their particular office standard. Or like many offices, they don't allow downloaded content to be used at all.

From the viewpoint of someone writing custom software for Revit, which I'm doing, not having the BuiltIn parameters means that you have to custom code for everyone's personal pile of shared parameters. Or you have to force your own code generated parameters into someone else's process. In the US we use net for some spaces and gross for other spaces on code calculations. So I have to generate a shared parameter with a GUID I can depend on, that may conflict with a name that someone else used to store these values. Then pump the data into these custom fields - do a few dozen calculations this way for occupancy. Do another few dozen calculations that way for toilet counts and stuff that into places that don't exist.

Or I could hide all your data in custom dictionaries inside Revit that you can't see or understand  and make you pay high yearly subscription fees to access and use your data. Because only my software can read my data in your file. (This is a LOT simpler for me as a programmer. And that's where AutoCAD went with all those Object Enablers.) I'm not an advocate.

Ric_Weber
Collaborator

I am not in favor of this particular idea, sorry.  The built in parameters get in my way more often than not. 

 

However something mentioned would be extremely helpful, if possible.  A "universal" shared parameter list of sorts.  But more than that.  it would be multi-lingual.  So for instance, Rough Opening Width would be the same GUID even if the language is Portuguese or Italian, or English.  This could even go for things like Sill Height for instance.  In a different region and in the local language it is call "Bottom Rail Height" or whatever.  But both of those things would have the same GUID, so if I imported one of those families, the GUIDs would match up.  

 

I think for this to truly work well, it would need to be cloud based and included with all Autodesk subscriptions.  I doubt if we could ever get industry wide collaboration on it, but it would facilitate world-wide Autodesk users all using the same "language" so to speak.   

 

Maybe this is a pipe dream...  just my thoughts. 

Can't find what you're looking for? Ask the community or share your knowledge.

Submit Idea  

Autodesk Design & Make Report