This is an update to a much earlier post after getting a couple comments on that thread. These are three companies I'm familiar with that are providing solutions that contend with sharing details between projects and multiple model projects.
Revolution Design - Revit Workflow
26 Degrees Software - ViewAQC
Parallax Team - Parallax Linked Details
Check them out!
Showing posts with label Annotation. Show all posts
Showing posts with label Annotation. Show all posts
Monday, May 06, 2019
Tuesday, August 21, 2018
Section Line Annotation Alignment
No, not the 2019.1 feature that allows us to use the Align tool on sections...
If you find yourself wondering why you don't the get the telltale dashed lines to help you line up section heads or tails check Visibility/Graphics for the view and make sure Lines are checked (visible). If the category is turned off, so too are they. These...
Check this...
If you find yourself wondering why you don't the get the telltale dashed lines to help you line up section heads or tails check Visibility/Graphics for the view and make sure Lines are checked (visible). If the category is turned off, so too are they. These...
Check this...
Sunday, May 01, 2016
Revit 2017 - Calculated Values in Tags
This addition permits us to do the same thing to tags that we've been using in schedules. For example, in a tag I'd like to show the difference between the client required area and the actual area of a room. That wasn't possible without some export/import or Dynamo shenanigans. Now it is possible, right in a tag.
This starts in the Edit Label dialog via a new button, then it is the same as the dialog we've seen in Schedules.
Since these can be used in schedules and tags, and it has to be done separately for each use, it probably makes sense to document all of the formulas we use so they are easily harvested for another project. Build them into a template and there is less need to do that at all. Regardless it wouldn't hurt to have a Drafting View set aside with the text versions of all the formulas we use stored there. That way a simple Copy/Paste operation can harvest a formula to use in a tag or a schedule or both.
This starts in the Edit Label dialog via a new button, then it is the same as the dialog we've seen in Schedules.
Since these can be used in schedules and tags, and it has to be done separately for each use, it probably makes sense to document all of the formulas we use so they are easily harvested for another project. Build them into a template and there is less need to do that at all. Regardless it wouldn't hurt to have a Drafting View set aside with the text versions of all the formulas we use stored there. That way a simple Copy/Paste operation can harvest a formula to use in a tag or a schedule or both.
Friday, April 08, 2016
Smaller Grid Bubbles
I wrote about one way to achieve using smaller grid bubbles in different views HERE. That written I can't help but wonder how much smaller is appropriate. A user recently complained they need a smaller grid bubble in a 1:1000 (metric) view. My gut reaction was "really?...maybe the grid bubble is just too big to begin with?" For example, this is what 1:100 and 1:1000 scale views look like side by side for a tiny footprint of grids using a stock grid family (6.5 mm radius/4.5 mm text).
That image is captured after using Zoom to Fit. How effective are grid bubbles at that scale to begin with? In imperial units that's equivalent to a view scale of 1"=120'-0". Keeping in mind that Revit's bias is to maintain the printed size of annotation, how much smaller does the bubble and text need to be to be better but still useful? This next image is the same sheet with grids bubbles that are half as big, text half as high (3.25 mm radius circle and 2.25 mm text).
I could argue that if the 1:1000 scale size is acceptable it might as well be the standard for all the views? This is how it (the smaller size grid bubbles) looks if I use Zoom Sheet Size and pan the view to show the grids side by side. This is more representative of what it will look like on the printed page.
Having the ability to turn off the bubble graphics only leaving the Grid name's text only might be a nice option. It seems to me that decreasing the size of the text means it is likely to no longer be legible. That's never good for documentation. For example, quite a few standards dictate a minimum text size of 1/8" which is larger than the 2.25 mm text I've shown in the images above.
Using a smaller font than what is shown above is going to start being too small to read on half-size prints; which is what I see getting printed more often these days. Fwiw, it's my understanding that 1/8" text as a requirement was decided upon because half size documents are printed so often and the resulting 1/16" text is at the brink of no longer being legible so standards set it accordingly.
Regardless, it's a frequent enough request that the development team ought to see what they can come up with. Something that is easy to implement and provides more flexibility for documentation.
That image is captured after using Zoom to Fit. How effective are grid bubbles at that scale to begin with? In imperial units that's equivalent to a view scale of 1"=120'-0". Keeping in mind that Revit's bias is to maintain the printed size of annotation, how much smaller does the bubble and text need to be to be better but still useful? This next image is the same sheet with grids bubbles that are half as big, text half as high (3.25 mm radius circle and 2.25 mm text).
I could argue that if the 1:1000 scale size is acceptable it might as well be the standard for all the views? This is how it (the smaller size grid bubbles) looks if I use Zoom Sheet Size and pan the view to show the grids side by side. This is more representative of what it will look like on the printed page.
Having the ability to turn off the bubble graphics only leaving the Grid name's text only might be a nice option. It seems to me that decreasing the size of the text means it is likely to no longer be legible. That's never good for documentation. For example, quite a few standards dictate a minimum text size of 1/8" which is larger than the 2.25 mm text I've shown in the images above.
Using a smaller font than what is shown above is going to start being too small to read on half-size prints; which is what I see getting printed more often these days. Fwiw, it's my understanding that 1/8" text as a requirement was decided upon because half size documents are printed so often and the resulting 1/16" text is at the brink of no longer being legible so standards set it accordingly.
Regardless, it's a frequent enough request that the development team ought to see what they can come up with. Something that is easy to implement and provides more flexibility for documentation.
Tuesday, August 18, 2015
KeyNotes - You Keep Using that Word...
A recent exchange went a little like this:
In Revit there are three ways we can apply keynotes to drawings. First we have a formal tool called, not surprisingly, Keynote. Second we have an older slightly less formal technique using a Noteblock Schedule based on a Generic Annotation family. Third we have the old school approach where we use a Generic Annotation symbol and then separate Annotation (lines) and Text elements to provide the appearance of a formal schedule we are familiar with.
I've often referred to the Keynote feature as the rich man's keynotes because it requires ongoing rigor and advance planning/effort.
We have to manage an external keynote file (TXT) and use specific annotation tags that work with this external data. Our families can each store a keynote parameter value (which a tag reports) and we can create ad hoc User Keynotes too. Keynote Schedules can (a Filter option) display only those that appear in the views that are on each sheet, a distinct advantage over the other techniques.
In the image below I'm using a cool tool called Keynote Manager to review keynotes. We have to organize the information that we want to be available for keynoting ahead of time or at least be prepared to stop and start when we realize we are missing something. The external data and process is more formal and rigorous. That's why I've observed it is also poorly adopted.
When we combine this process with Keynote Legends on sheets we have a consistent and predictable structure for keynoting activity.
In contrast the Noteblock approach, which I've often called the poor man's keynotes, depends on data stored in specific Annotation Symbol families.
It does require some rigor but not quite as much as the formal Keynotes tool and there is no external TXT file that keeps the data consistent. When we create a Noteblock Schedule we have to choose the correct Annotation Family to base it on. Then the schedule reports how many instances of that annotation family (symbol) we place in views, that are then placed on sheets. These are much harder to filter so we only show those that relate to specific views on sheets, there is no built in feature to filter them.
The third approach is not really any different than how I've seen it done for many years with CAD and hand drafting before that.
We place symbols, change the number/letter and then later create a legend on the sheet that provides a summary of the keynote symbols we've placed in the drawing. We examine the drawing and make an entry for each symbol we observe on the drawing. It isn't hard to do but it isn't fun and very error prone, especially as the project progresses and changes occur.
Referring back to the exchange at the beginning of the post, it turns out that the technique that was being used was the last one, symbols, lines and text. It helps a lot to figure out which technique is being used before launching into helpful responses that assume either of the other two possibilities are in play.
Them: "Steve! I need some help with my keynotes!" Me: "Okay, how are you doing them?" Them: "Huh? I just drag this family from the Project Browser and place it in the view. When I look at my keynote schedule I don't see the keynote being added."When software uses the same word we routinely use to describe something we do it is supposed to make it easier to understand and use. Sometimes the opposite happens, as in this situation the word Keynote or the practice of key noting (keynoting). A good many of us in the AEC business are familiar with the concept of using keynotes on drawings.
I find it interesting that I didn't find a definition readily available on the interwebs for what we do with and call keynotes. There were lots of trade specific sites but not the traditional dictionary or wiki version. Most refer to being the keynote speaker at an event or related to music.Regardless, for us it is a system to reduce clutter on drawings by placing symbols that either carry numbers or letters or both to identify different conditions that we should look to a separate place (key, like a map key to symbols) to read more information. Ideally it means we get drawings that are cleaner looking instead of the clutter of long descriptions nestled among the graphics that describes the building itself. It's also a way to help reduce the chances of making spelling errors or stating things differently because more than one person is usually involved in the process of completing drawings.
In Revit there are three ways we can apply keynotes to drawings. First we have a formal tool called, not surprisingly, Keynote. Second we have an older slightly less formal technique using a Noteblock Schedule based on a Generic Annotation family. Third we have the old school approach where we use a Generic Annotation symbol and then separate Annotation (lines) and Text elements to provide the appearance of a formal schedule we are familiar with.
I've often referred to the Keynote feature as the rich man's keynotes because it requires ongoing rigor and advance planning/effort.
We have to manage an external keynote file (TXT) and use specific annotation tags that work with this external data. Our families can each store a keynote parameter value (which a tag reports) and we can create ad hoc User Keynotes too. Keynote Schedules can (a Filter option) display only those that appear in the views that are on each sheet, a distinct advantage over the other techniques.
In the image below I'm using a cool tool called Keynote Manager to review keynotes. We have to organize the information that we want to be available for keynoting ahead of time or at least be prepared to stop and start when we realize we are missing something. The external data and process is more formal and rigorous. That's why I've observed it is also poorly adopted.
When we combine this process with Keynote Legends on sheets we have a consistent and predictable structure for keynoting activity.
In contrast the Noteblock approach, which I've often called the poor man's keynotes, depends on data stored in specific Annotation Symbol families.
It does require some rigor but not quite as much as the formal Keynotes tool and there is no external TXT file that keeps the data consistent. When we create a Noteblock Schedule we have to choose the correct Annotation Family to base it on. Then the schedule reports how many instances of that annotation family (symbol) we place in views, that are then placed on sheets. These are much harder to filter so we only show those that relate to specific views on sheets, there is no built in feature to filter them.
The third approach is not really any different than how I've seen it done for many years with CAD and hand drafting before that.
We place symbols, change the number/letter and then later create a legend on the sheet that provides a summary of the keynote symbols we've placed in the drawing. We examine the drawing and make an entry for each symbol we observe on the drawing. It isn't hard to do but it isn't fun and very error prone, especially as the project progresses and changes occur.
Referring back to the exchange at the beginning of the post, it turns out that the technique that was being used was the last one, symbols, lines and text. It helps a lot to figure out which technique is being used before launching into helpful responses that assume either of the other two possibilities are in play.
Friday, March 13, 2015
View Reference Example
Related to a past POST or TWO...or THREE.
Here's a quick example of a poorly crafted Plan View reference that can be used to indicate what sheet a plan view is from a Section or Elevation view.
Want to reverse engineer it? Download the View Reference family.
Here's a quick example of a poorly crafted Plan View reference that can be used to indicate what sheet a plan view is from a Section or Elevation view.
Want to reverse engineer it? Download the View Reference family.
Tuesday, February 17, 2015
Dimension Style Type
That parameter name seems a bit like the Department of Redundancy Department. It lets us choose between three kinds of dimension behaviors: Continuous, Baseline and Ordinate. We are all pretty familiar with Continuous. I've spent time doing mechanical drafting (aka shop drawings) in the past and it wasn't uncommon to use some form of the other two types of dimensions. This is what the three of them look like together.
The Baseline dimension you see in the image is a single element, the entire collection of dimension lines you see. Each dimension line is offset from the others by the Dimension Line Snap Distance parameter's value.
The Baseline dimension you see in the image is a single element, the entire collection of dimension lines you see. Each dimension line is offset from the others by the Dimension Line Snap Distance parameter's value.
Tuesday, February 10, 2015
Revit MEP - Detail Callout Bias or Gotcha
Many of Revit mEp families use a nested annotation symbol to provide the standard graphics we are used to seeing in electrical documentation. Here's a little example of a few of these families.
If you created a Callout view and these symbols vanish my bet is that you've used a Detail Callout. Here's what a Detail Callout view of the same families looks like.
It's definitely a quirky thing, but these nested annotations in outlets don't show up in Detail Callout view. Feel free to start trying adjustments to Visibility/Graphics, Detail Level, Discipline and more...I've been down the road already. I'm pretty sure we're looking at a bug, or at least a conundrum brought about by the way these nested annotations work.
This view type is also fussy about creating other elements, like a room/space for example. As such I understand that this view type is intended as the last stop or end of the road with regard to drafting up a detail, for detailing not modeling with. It's just odd that these annotation elements won't appear in the view.
If you want an enlarged plan to show these annotation then avoid the Detail Callout, use the Floor Plan type instead.
If you created a Callout view and these symbols vanish my bet is that you've used a Detail Callout. Here's what a Detail Callout view of the same families looks like.
It's definitely a quirky thing, but these nested annotations in outlets don't show up in Detail Callout view. Feel free to start trying adjustments to Visibility/Graphics, Detail Level, Discipline and more...I've been down the road already. I'm pretty sure we're looking at a bug, or at least a conundrum brought about by the way these nested annotations work.
This view type is also fussy about creating other elements, like a room/space for example. As such I understand that this view type is intended as the last stop or end of the road with regard to drafting up a detail, for detailing not modeling with. It's just odd that these annotation elements won't appear in the view.
If you want an enlarged plan to show these annotation then avoid the Detail Callout, use the Floor Plan type instead.
Monday, February 09, 2015
Tags and Instance Parameters
I was thinking it would be nice to be able to create an instance parameter to turn on/off graphics in a given tag. Create one tag, place many and toggle on and off various parts. Revit says, "No, sorry Steve you can't do that."
Tags require us to create Types. The yes/no parameters turned on/off in each type as required. Then place a tag type that shows what you want to see or switch to a different type.
Making it possible to use instance parameters is a pretty common request, even reasonable perhaps. However, doing so would mean we couldn't trust that a given tag and type would be displaying all the information it is supposed to show without visiting each and every tag to verify.
Thus far that risk seems to have justified locking it down to only type based tag behavior.
Tags require us to create Types. The yes/no parameters turned on/off in each type as required. Then place a tag type that shows what you want to see or switch to a different type.
Making it possible to use instance parameters is a pretty common request, even reasonable perhaps. However, doing so would mean we couldn't trust that a given tag and type would be displaying all the information it is supposed to show without visiting each and every tag to verify.
Thus far that risk seems to have justified locking it down to only type based tag behavior.
Tuesday, August 05, 2014
Tagging Elements
It is pretty common to have quite a few different kinds of tags for the elements we need to tag in views. Some equipment might get an oval shaped tag while others have a hexagon. When we need to switch between tags Revit isn't quite fine tuned for this yet. Here's three approaches we can take.
When you tag elements you can tell Revit which tag should be used by default via the Loaded Tags dialog. The tag that appears next to a category is the tag that will be used when you use Tag by Category. If you work systematically you can set which tag you intend to use for awhile and then the correct tag will be offered by default.
Another way to do it is Right Click > Create Similar (you can select one and click the Create Similar button on the ribbon too) over a tag that is the kind you want to place, assuming one is already in the view. This way Revit will start tagging with that tag.
Yet another approach is to select everything you want to tag and then use Tag All, choosing the tag type you'd like to use. When you select elements first this dialog changes Revit's focus to tag selected elements instead of everything that isn't already tagged. This gives you a bit more control over which tag should be used on which elements.
A tagging quirk is that Revit won't let us put more than one tag on the same element. For example I like to use a pipe tag to identify CW (cold water) or HW (hot water) pipes. I can put one tag on a pipe but Revit won't recognize the pipe as available unless I tag a different pipe first. My work around is to bounce back a forth between pipes. It seems a little silly not to let me put another tag on a pipe if I want too.
When you tag elements you can tell Revit which tag should be used by default via the Loaded Tags dialog. The tag that appears next to a category is the tag that will be used when you use Tag by Category. If you work systematically you can set which tag you intend to use for awhile and then the correct tag will be offered by default.
Another way to do it is Right Click > Create Similar (you can select one and click the Create Similar button on the ribbon too) over a tag that is the kind you want to place, assuming one is already in the view. This way Revit will start tagging with that tag.
Yet another approach is to select everything you want to tag and then use Tag All, choosing the tag type you'd like to use. When you select elements first this dialog changes Revit's focus to tag selected elements instead of everything that isn't already tagged. This gives you a bit more control over which tag should be used on which elements.
A tagging quirk is that Revit won't let us put more than one tag on the same element. For example I like to use a pipe tag to identify CW (cold water) or HW (hot water) pipes. I can put one tag on a pipe but Revit won't recognize the pipe as available unless I tag a different pipe first. My work around is to bounce back a forth between pipes. It seems a little silly not to let me put another tag on a pipe if I want too.
Monday, March 17, 2014
Revit MEP Annotation Scale
In the settings dialog for duct, pipe, conduit and cable tray Revit provides a parameter called Use Annot. Scale for Single Line Fittings. There is also a second related parameter called "XXX Fitting Annotation Size" where "XXX" is the element involved. As the parameter names suggest they are related to single line views, where the detail level is either assigned to Coarse or Medium for their category (duct/pipe/conduit/cable tray).
When the first parameter (previous image) is checked Revit will check (turn on) the parameter that each fitting or accessory has, called Use Annotation Scale, each time they are placed in your project.
The purpose of these related settings is to provide a consistent symbol size regardless of view scale (in single line views). This way the symbols don't suddenly become much larger or smaller in different scale views than the symbols we show on our legends. When you see this occur you'll need to double check the settings and the individual parameter values for each affected family.
If the option is off in the Settings dialog then every fitting or accessory you place has its own Use Annotation Scale setting unchecked (off). It's a global on/off switch to enable the feature. You can still interact with each fitting or accessory's own parameter to enable the annotation scaling feature or vice versa. When you change the view's scale you'll find that the annotation symbol graphics will not remain the same printed size.
The following image shows one ball valve accessory that has had its Use Annotation Scale turned off. It's larger than the other fittings and accessories in the view, they adjust their symbol size so they are the same size when the views are printed on a sheet. The lower plan view is using 1/4"=1'-0" scale and the upper one is assigned to 1/8"=1'-0" scale instead.
This image is both views placed on a sheet for comparison.
Each of these MEP element has its own settings; Duct, Pipe, Conduit and Cable Tray. I think the most appropriate setting for each is checked (on). The second parameter XXX Fitting Annotation Size is usually 1/8" ( or 3.0 mm) (stock setting in templates) and that's probably a good starting point. You may find it necessary to adjust it slightly by increasing or decreasing the size to get the ideal symbol graphics.
The other thing to keep in mind is that the single line graphics in these families are defined by Model Lines that are set to be visible in Coarse and Medium Detail Level but to not be visible in Fine Detail Level. This makes it possible to generate the single line diagrams in 3D views too, otherwise there would be nothing to see. It also makes it a bit trickier to get the same graphic size when comparing one fitting or accessory with another.
This is quite different from electrical families by comparison because those primarily use nested annotation symbol families for their symbolic graphics. Those already conform to Revit's annotation behavior of maintaining their printed size. It also explains why, for electrical components, 3D views (and elevations/sections) do not show the plan graphic symbols we are accustomed to seeing.
When the first parameter (previous image) is checked Revit will check (turn on) the parameter that each fitting or accessory has, called Use Annotation Scale, each time they are placed in your project.
The purpose of these related settings is to provide a consistent symbol size regardless of view scale (in single line views). This way the symbols don't suddenly become much larger or smaller in different scale views than the symbols we show on our legends. When you see this occur you'll need to double check the settings and the individual parameter values for each affected family.
If the option is off in the Settings dialog then every fitting or accessory you place has its own Use Annotation Scale setting unchecked (off). It's a global on/off switch to enable the feature. You can still interact with each fitting or accessory's own parameter to enable the annotation scaling feature or vice versa. When you change the view's scale you'll find that the annotation symbol graphics will not remain the same printed size.
The following image shows one ball valve accessory that has had its Use Annotation Scale turned off. It's larger than the other fittings and accessories in the view, they adjust their symbol size so they are the same size when the views are printed on a sheet. The lower plan view is using 1/4"=1'-0" scale and the upper one is assigned to 1/8"=1'-0" scale instead.
This image is both views placed on a sheet for comparison.
Each of these MEP element has its own settings; Duct, Pipe, Conduit and Cable Tray. I think the most appropriate setting for each is checked (on). The second parameter XXX Fitting Annotation Size is usually 1/8" ( or 3.0 mm) (stock setting in templates) and that's probably a good starting point. You may find it necessary to adjust it slightly by increasing or decreasing the size to get the ideal symbol graphics.
The other thing to keep in mind is that the single line graphics in these families are defined by Model Lines that are set to be visible in Coarse and Medium Detail Level but to not be visible in Fine Detail Level. This makes it possible to generate the single line diagrams in 3D views too, otherwise there would be nothing to see. It also makes it a bit trickier to get the same graphic size when comparing one fitting or accessory with another.
This is quite different from electrical families by comparison because those primarily use nested annotation symbol families for their symbolic graphics. Those already conform to Revit's annotation behavior of maintaining their printed size. It also explains why, for electrical components, 3D views (and elevations/sections) do not show the plan graphic symbols we are accustomed to seeing.
Wednesday, May 29, 2013
Tag Slope of a Ramp
We can apply the Spot Slope annotation to a ramp but it isn't very useful because, while Revit does acknowledge the ramp element, when you attempt to tag it you see [no slope] (image using 2014).
Alfredo replied to my previous post with a tip in his comment:
In this image I've dragged a slope annotation from a floor element over to a ramp element and it recognizes the ramp's slope!
Definitely quirky and subtle but at least it is possible after all. A word of caution, it will probably be necessary to check the slope value before printing, for example if Revit regenerates information because the ramp is altered. The tag could could start to report [no slope] again. Fwiw, in my casual testing so far it hasn't broken the slope value even after altering a ramp's parameters. Your mileage may vary...
Alfredo replied to my previous post with a tip in his comment:
- If you first place the spot slope tool on a floor and then move the slope annotation to a ramp, it works!
In this image I've dragged a slope annotation from a floor element over to a ramp element and it recognizes the ramp's slope!
Definitely quirky and subtle but at least it is possible after all. A word of caution, it will probably be necessary to check the slope value before printing, for example if Revit regenerates information because the ramp is altered. The tag could could start to report [no slope] again. Fwiw, in my casual testing so far it hasn't broken the slope value even after altering a ramp's parameters. Your mileage may vary...
Tuesday, November 06, 2012
Insert 2D from File
I read another post this morning that prompted me to mention "another door", another way to get where we want to go. In this case James mentions using the Display Model setting for a view to only show the annotation (2D stuff) that's been added. The intention being to then copy/paste that useful stuff to another project. It's a harvesting exercise and one the developers created a specific tool for, "Insert 2D Elements from File".
This tool allows you to browse to another project, select from the views of that project and choose those that have 2D information that you'd like to use in this project. If you've ever thought, "I know there is a great detailing in a wall section in XYZ Project, I wish I could just grab it", you can!
It's brother (or sister) Insert Views from File allows us to harvest drafting views, schedules and sheets that contain either.
This tool allows you to browse to another project, select from the views of that project and choose those that have 2D information that you'd like to use in this project. If you've ever thought, "I know there is a great detailing in a wall section in XYZ Project, I wish I could just grab it", you can!
It's brother (or sister) Insert Views from File allows us to harvest drafting views, schedules and sheets that contain either.
Friday, February 03, 2012
Oh Where Art Thou Camera?
I wrote a post in March 2008 about this, still waiting. It would be excellent if in plan we could document where a camera is placed. Sure we can create a family to document where they are but that doesn't provide the automatic view reference that other view annotation enjoys. Seems kind of un-Revity to me, you?
If you decide to create a camera annotation how do you know exactly where it is after you place the camera? Good old "right click" will help, just select the view in the Project Browser, Right Click and choose Show Camera. Make a note of where it is and drop your annotation there.
If you decide to create a camera annotation how do you know exactly where it is after you place the camera? Good old "right click" will help, just select the view in the Project Browser, Right Click and choose Show Camera. Make a note of where it is and drop your annotation there.
Thursday, August 18, 2011
Dept. of Subtle - Load Type Properties - Linear Force Scale
The Autodesk Wikihelp says that this is for graphic display only yet the Type Properties dialog offers a value to change using a structural unit instead of integer or number data type. It does affect the height of the annotation as suggested by help but the value you enter seems a little odd?
From Wikihelp:
...snip Force Scale The display size parameter; this value visually changes the display of the force symbol. Scale is for display only....snip
Same thing for Moment Scale.
From Wikihelp:
...snip Force Scale The display size parameter; this value visually changes the display of the force symbol. Scale is for display only....snip
Same thing for Moment Scale.
Tuesday, January 25, 2011
Annotation Symbol as Schedule
Sometimes you just need a way to store/present some information that may/may not be obtained from the model itself. You could create additional parameters (project parameters) and create a schedule to report the information if you assign them to a category you may not be likely to use in your normal scope, something that you won't use and won't likely have a schedule stumble on that same category if there are linked files.
Years ago I made the following family and I just stumbled across it again after getting asked about this situation and doing a search at AUGI (I posted it originally at Zoog Design and it migrated with the merge to AUGI).
It's pretty simple: lines, text and labels using instance parameters for each "XXXX" value I want to enter. When I put it in a project, it is "full size" for printing and I can put it anywhere I need it, view or a sheet view. I can select it and click on "X's" to fill out the form. A few years ago Jake Boen (at Autodesk University 2006) presented more clever examples that include calculations to do all sorts of things that we'd normally reach for a spreadsheet to do. Put your thinking cap on and I'm sure you can find a nice way to use the concept.
If you'd like to download the family
Years ago I made the following family and I just stumbled across it again after getting asked about this situation and doing a search at AUGI (I posted it originally at Zoog Design and it migrated with the merge to AUGI).
It's pretty simple: lines, text and labels using instance parameters for each "XXXX" value I want to enter. When I put it in a project, it is "full size" for printing and I can put it anywhere I need it, view or a sheet view. I can select it and click on "X's" to fill out the form. A few years ago Jake Boen (at Autodesk University 2006) presented more clever examples that include calculations to do all sorts of things that we'd normally reach for a spreadsheet to do. Put your thinking cap on and I'm sure you can find a nice way to use the concept.
If you'd like to download the family
Wednesday, August 26, 2009
Family Editor - Annotation
This is a quick reminder. When you first open a Revit template or any family for that matter, what you see depends on the way the previous user left it. If they turned off categories or altered a view in some other way that's what you see.
The reminder therefore is, when you open a template be sure to check Visibility/Graphics and the Annotations tab. Some or all of the categories listed here are quite often turned off. Particularly true of finished content because this improves the thumbnail we see while loading content. This is also why most stock content is using a 3D view oriented to a side view so that annotation is automatically removed.
The reminder therefore is, when you open a template be sure to check Visibility/Graphics and the Annotations tab. Some or all of the categories listed here are quite often turned off. Particularly true of finished content because this improves the thumbnail we see while loading content. This is also why most stock content is using a 3D view oriented to a side view so that annotation is automatically removed.
Wednesday, October 22, 2008
Hiding Un-Wanted View Annotation
This is about hiding view annotation like Sections, Elevations and Callouts.
You can hide individual annotation by selecting one or more, Right Click > Hide in View > Elements.
This will hide just those selected in this view only. If you have many and many views to do this in it can get a bit tedious. To restore these Hidden Elements you need to use the Reveal Hidden Elements feature found on the View Control Shortcuts Bar.
This mode will display those things that have been hidden and allow you to UnHide them.
Two other methods are possible, one easy and one a bit more involved but also "easy" depending on your definition of easy.
For "easiest", when you print you can choose the Print Setup Option: Hide unreferenced view tags.
This means that for any views that are not currently on a sheet view Revit will not print their corresponding annotation. They are still visible and yes you have to remember to choose this setting but it is "easy" and more or less automatic.
A more involved approach requires a couple things; a view and the use of the "Hide at Scales Coarser Than" parameter, part of each view's instance parameters and found here.
The first step is to create a view, like a floor plan using a ridiculous scale like full size or maybe 6"=1'-0". This view will never fit on paper. Now you can name this view something like: "Ridiculous Scale View to Hide Annotation" (RSVTHA) or maybe something more discreet?
Now you add all your working sections or elevations that you don't want to clutter your document set. When you place these views on your "RSVTHA" view you need to make sure they are using the same value for the "Hide as Scales Coarser Than" parameter. This will prevent the annotation from showing up in any view that uses a coarser scale than 6"=1'-0". If you have some views using this scale then pick the next scale "up" or coarser.
When you are navigating your sections or manipulating where they cut the model you just use the "RSVTHA" and you never have to worry about them showing up where they aren't wanted.
You can hide individual annotation by selecting one or more, Right Click > Hide in View > Elements.
This will hide just those selected in this view only. If you have many and many views to do this in it can get a bit tedious. To restore these Hidden Elements you need to use the Reveal Hidden Elements feature found on the View Control Shortcuts Bar.
This mode will display those things that have been hidden and allow you to UnHide them.Two other methods are possible, one easy and one a bit more involved but also "easy" depending on your definition of easy.
For "easiest", when you print you can choose the Print Setup Option: Hide unreferenced view tags.
This means that for any views that are not currently on a sheet view Revit will not print their corresponding annotation. They are still visible and yes you have to remember to choose this setting but it is "easy" and more or less automatic.A more involved approach requires a couple things; a view and the use of the "Hide at Scales Coarser Than" parameter, part of each view's instance parameters and found here.
The first step is to create a view, like a floor plan using a ridiculous scale like full size or maybe 6"=1'-0". This view will never fit on paper. Now you can name this view something like: "Ridiculous Scale View to Hide Annotation" (RSVTHA) or maybe something more discreet?
Now you add all your working sections or elevations that you don't want to clutter your document set. When you place these views on your "RSVTHA" view you need to make sure they are using the same value for the "Hide as Scales Coarser Than" parameter. This will prevent the annotation from showing up in any view that uses a coarser scale than 6"=1'-0". If you have some views using this scale then pick the next scale "up" or coarser.
When you are navigating your sections or manipulating where they cut the model you just use the "RSVTHA" and you never have to worry about them showing up where they aren't wanted.
Thursday, March 27, 2008
Proposal - Camera View Annotation
When a Camera view is created there is no built-in intentional way to show our readers where the camera is located. With Revit (and 3D design in general) more and more camera views are used to explain/document our work.
I believe there should be something like we have for sections,elevations & call-outs. and I know I'm not alone. Camera views should have annotation generated in the same way that other views in Revit do. They should appear in plan views in my opinion but an argument could be made for them showing up in elevation and section views too.
In the meantime we CAN continue to create an Annotation Symbol family that we can place and then enter detail and sheet location information...yeah, "old school"...
It could be sooo much better...
I believe there should be something like we have for sections,elevations & call-outs. and I know I'm not alone. Camera views should have annotation generated in the same way that other views in Revit do. They should appear in plan views in my opinion but an argument could be made for them showing up in elevation and section views too.
In the meantime we CAN continue to create an Annotation Symbol family that we can place and then enter detail and sheet location information...yeah, "old school"...
It could be sooo much better...
Wednesday, September 26, 2007
Project Font - A Family and Project Variable
Anyone who has implemented Revit knows that the process to change the standard font style, office and project(s) wide, is not as simple as just changing a single setting. Unfortunately every form of annotation has its own setting for font data. That makes it incredibly flexible but it also makes it incredibly annoying and such a mundane task to change.
In the past I've suggested (others have as well in one forum or another) that Revit needs a notion of a Project Font. A single setting in a project that defines the font that SHALL be used. Okay fine for the project but what about families. That's where the hard part is anyway, opening up all those families and changing one parameter...close...repeat.
I suggest that in addition to the list of fonts offered us, while we create annotation content, that Revit provide a "font" choice that tells the family to use the project's Project Font assignment instead of being an individual going its own way. This way nearly all annotation content would simply be assigned the project font and whatever project file it was used in would display accordingly. No extra work for us.
If we need to use a specific font, to spite the project font, we just pick one instead and that's what the annotation uses in the project environment, thumbing its nose at the project font setting, radical upstart that it is.
In projects text and dimensions would also offer this option so a single change to Project Font applies internally as well as to external content loaded for use.
Sure sounds good when I write and read it...let's hope I'm right and they listen to me taking advantage of my little bully pulpit.
In the past I've suggested (others have as well in one forum or another) that Revit needs a notion of a Project Font. A single setting in a project that defines the font that SHALL be used. Okay fine for the project but what about families. That's where the hard part is anyway, opening up all those families and changing one parameter...close...repeat.
I suggest that in addition to the list of fonts offered us, while we create annotation content, that Revit provide a
If we need to use a specific font, to spite the project font, we just pick one instead and that's what the annotation uses in the project environment, thumbing its nose at the project font setting, radical upstart that it is.
In projects text and dimensions would also offer this option so a single change to Project Font applies internally as well as to external content loaded for use.
Sure sounds good when I write and read it...let's hope I'm right and they listen to me taking advantage of my little bully pulpit.
Subscribe to:
Posts (Atom)