How should Fill Patterns, Line Styles, Line Patterns, etc. be named ?
-
Klaus Munkholm
"Do. Or do not. There is no try." -
This is a good question. I would love to hear what people are doing. For example: Spaces or no spaces within the project enviroment? for eg. Some of the OOTB linestyles have spaces in their names.
If not, why?
I have seen it said that it is not recommended within families to use spaces, therefore I would expect that to carry right across all things Revit.
ps. I love this sub-forum, so much useful info...Last edited by Darryl_S; March 8, 2011, 10:29 AM. -
I use spaces when experimenting. But all my content I make for production use uses _ underscores. Helps me track what content is production and whats not.-Alex CunninghamComment
-
<Identifier>_<Category>_<Type>_<Descriptor>_
<Identifier>
#RFO (The "#" to sort on top)
<Category>
Short abbreviation of the category name:
Fill Pattern = FP
Line Style = LS
Line Pattern = LP
etc
<Type>
For Fill Patterns only.
Model Pattern = M
Drafting Pattern = D
<Descriptor>
Pattern/Line Style name
Now, for me I normally also add the SfB-code in the Fill Pattern name (MasterFormat code). This way I have a more detailled list of Fill Patterns so I can assign different Fill Patterns to different Materials. This way I can edit the fill pattern for a specific material without having to worry about changing other materials by accident.Martijn de Riet
Professional Revit Consultant | Revit API Developer
MdR Advies
Planta1 Revit Online ConsultingComment
-
Our naming conventions basically follow everything else weve done, but here is a major sticking point for me. Since i dont want to retype it, a copy of an email i sent recently:
Just a quick thought on Materials, Fill Patterns, and the Family Editor:
My last office in New York adhered fairly strictly to the National CAD Standard, which- as I'm sure you know- is very particular about hatch patterns and line types. Revit handles all of this beautifully (kudos to you). Except: I ended up writing all of the pat files in a new .pat file, and they were named by FUNCTION, not by graphic. Worth mentioning, the office remained 50% ACA and 50% Revit, and we did this new system for both halves, and it was unanimously well received. Line patterns weren't "Dashed" they were "Demolished Items." There wasn't a "Hidden Line" type, there was a "Roof Overhang" linetype.
The same was true for Fill patterns. It wasn't "Diagonal up 1/16"" it was "Brick-Cut." It wasn't "Crosshatch" it was "CMU-cut." Sometimes, yes, that meant two patterns with different names were actually the same pattern definition, but that's a GOOD THING. Things were broken up systemically. It also prevents inconsistencies... "Which cut pattern is CMU block again? Crosshatch or Crosshatch-small?..." So, ive done the same thing in Revit for our materials, fill patterns, and linetypes...
The moment i see the generic Fill patterns, Line Styles, Linetypes, whatever... They get deleted from the content, setting them all back to default.Comment
-
I also like function (the purpose) involved with naming. A text style name like "Arial 3/32 underline and bold" is descriptive but it doesn't tell me whether I should use it or not. Text style names like Notes Headers, Notes Regular or Notes Emphatic start to suggest their purpose like styles in word processing software.
The more obvious it is to someone trying to choose something to use the better the system works. Personally, visiting different firms can be awkward for me to get acclimated. I don't see this strategy in place very often but it sure helps me get my bearing. Think like a user, there are 15 text styles listed, which one am I supposed to use?Comment
-
Yep, me too. My <Descriptor> is always a functional one. I hate it when I get a model with patterns that are named "Diagonal Up". Not only I cannot tell what it's for, I can also not tell where it has been used before. So I end up duplicating it before modifying just to be sure I'm not screwing something else up. Which off course gives me a lot of redundant types...Martijn de Riet
Professional Revit Consultant | Revit API Developer
MdR Advies
Planta1 Revit Online ConsultingComment
Comment