I read about a couple items in a thread at RFO that could affect creating a Local File in addition to to what I've mentioned in the past.
Revit appends our username to the local file it creates for us. That addition could cause a local file's name to exceed the maximum number of characters, which is 260 (file name and path). That's 256 plus the four characters associated with the drive letter, for example C:\ (space/null after the back slash).
The other possibility mentioned is having Auto Off-line Access enabled.
Gosh computers and software are fussy buggers!
Welcome to Steve Stafford's Blog ~ Revit OpEd = OPinion EDitorial ~ My view of things Revit, both real and imagined.
Saturday, February 28, 2015
Friday, February 27, 2015
Shared Parameters are Shared Definitions
We tend to think of Shared Parameters as a thing, equal to Family and Project parameters. I've even described them as such in past posts on the subject. If I'm very picky and technical they are not a thing, they are a device, a parameter definition, shared to either create a family parameter or project parameter or both.
Yes, they help us create a Family or Project parameter, but on their own they are nothing, they only exist in a text file. That text file only defines their name and data type, nothing else. Okay technically the file has a little more data in it than that but it's only used internally by Revit. It doesn't mean they have standing or truly exist on their own. We have to apply them to Family/Project parameters for them to mean something, be something, be useful.
Written another way, a family parameter (either component or system) can be created from a shared parameter and a project parameter likewise but there are no shared parameters that aren't one or the other.
This is why I regard them as a definition stored in a dictionary, the Shared Parameter file.
Yes, they help us create a Family or Project parameter, but on their own they are nothing, they only exist in a text file. That text file only defines their name and data type, nothing else. Okay technically the file has a little more data in it than that but it's only used internally by Revit. It doesn't mean they have standing or truly exist on their own. We have to apply them to Family/Project parameters for them to mean something, be something, be useful.
Written another way, a family parameter (either component or system) can be created from a shared parameter and a project parameter likewise but there are no shared parameters that aren't one or the other.
This is why I regard them as a definition stored in a dictionary, the Shared Parameter file.
Thursday, February 26, 2015
Toposurface from a Text File
I responded to a thread at the Autodesk Community Revit Forums back in May. They described having a survey file and a points file that could be used to create a toposurface. My initial reply focused on resolving this warning, "Imported Toposurface Points are located a large distance from the model and might not display properly. Points will be centered on the model instead".
I offered this advice.
Then another member asked about doing something similar but wanted to report a project elevation of 100'-0" instead of 0'-0". I replied with the following.
In order to show the Project Elevation as 100'-0" you'll need to model your building at that project elevation instead of 0'-0". Then when you establish shared coordinates you can show the true elevation. If I was tackling this I'd create a building model at 100' and a separate "site" model.
I'd import the site data in the site model and create a toposurface. It should be at the real elevation and report the relevant coordinates you expect. Then I'd import the building into the site model, move it into position X/Y, rotate it if necessary into alignment with the site conditions and finally move it up to the intended ground floor elevation. Then I'd use Publish Coordinates to pass the building position information out to the building file.
When you open the building model you can edit the Level parameter Elevation Base to use Survey Point (versus Project Base Point) and it will show the True site elevation values instead.
Just a couple days in the life of a thread at an online user forum (spanning nine months).
I offered this advice.
- Import the survey (a DWG file) first using Auto - Center to Center
- Move it so the relevant portion of the site is roughly centered on the Project Base Point/Survey Point
- Select the Survey Point and Unclip it (this prevents it from moving to the 0,0,0 location of the DWG file in the next step, which is far away)
- Acquire Coordinates from the DWG survey file
- Add a new set of point coordinates to your text file at 0,0,0, on the first line.
- Use this version of the points file to create the surface.
- Unclip the Survey Point > Enter E/W: 0' and N/S: 0'
- The Survey Point should jump to the 0,0,0 location of the survey file, far from the project origin.
- Make sure your View Range is set high enough to see all the points of the surface
- Now create your toposurface
- When the points are visible you'll see one point at 0,0,0 but it will be at the Internal Origin (>R2020, Project Base Point in older versions)
- Select all the (toposurface) points > move using the Internal Origin/Project Base Point location as your first pick and the Survey Point as your second pick (see image below).
- This will move all the points down so the toposurface is located properly relative to the survey
- Before finishing the surface > Delete the one toposurface point at 0,0,0
- Finish Surface
Then another member asked about doing something similar but wanted to report a project elevation of 100'-0" instead of 0'-0". I replied with the following.
In order to show the Project Elevation as 100'-0" you'll need to model your building at that project elevation instead of 0'-0". Then when you establish shared coordinates you can show the true elevation. If I was tackling this I'd create a building model at 100' and a separate "site" model.
I'd import the site data in the site model and create a toposurface. It should be at the real elevation and report the relevant coordinates you expect. Then I'd import the building into the site model, move it into position X/Y, rotate it if necessary into alignment with the site conditions and finally move it up to the intended ground floor elevation. Then I'd use Publish Coordinates to pass the building position information out to the building file.
When you open the building model you can edit the Level parameter Elevation Base to use Survey Point (versus Project Base Point) and it will show the True site elevation values instead.
Just a couple days in the life of a thread at an online user forum (spanning nine months).
Wednesday, February 25, 2015
Need a Ceiling Tool
Revit Workflows and Auto Floors Builder are two 3rd party applications that tackle the task of creating floors more efficiently. Revit Workflows is focused on finish floors and Auto Floors Builder has a more structural focus. While I think Autodesk ought to tackle this sort of refinement directly it is great that there are some options.
Where are equivalent tools for creating ceilings? Is the API holding development back or are they just still on the drawing board? My inquiring mind is curious...
Where are equivalent tools for creating ceilings? Is the API holding development back or are they just still on the drawing board? My inquiring mind is curious...
Tuesday, February 24, 2015
View Range Help Doc Image
I was pointing out the View Range help documentation earlier and noticed that the plan view seems to have Thin Lines on, no particular difference in the lineweights depicted. At the very least it is a bit anemic looking. I think it would be a little more helpful to be more obvious which lines are affected by the Cut Plane by showing the Cut lineweight, like for the walls.
Fwiw, I think View Depth should be moved above the Primary Range when the View Range dialog is opened for Ceiling Plan Views...and maybe called View Upth? :)
Fwiw, I think View Depth should be moved above the Primary Range when the View Range dialog is opened for Ceiling Plan Views...and maybe called View Upth? :)
Monday, February 23, 2015
Revit MEP - Electrical Wire Size
Revit mEp is very American because it is hard-wired to do its calculations based on the AWG based wire sizes that are defined in the templates Autodesk provides to us. When you need to reference metric sizes/standards instead there is no place to change this bias and if you attempt to change wire sizes to metric equivalent (CSA or Sq. mm) values you'll find calculations, like Voltage Drop, either cease to work or you get strange results.
Working through this issue with a client recently they decided (or at least hoped) it would be acceptable to provide a chart that allowed the reader to cross reference the AWG size against the locally relevant size. This firm is based here in the USA but working on a project outside the USA. Perhaps in that context this could be forgiven by the client. I don't know how well that approach will work for firms that are working at home, outside the USA.
Fwiw, Autodesk IS aware of this bias. Providing more flexibility is among the many things they have to find time to include in future releases.
Working through this issue with a client recently they decided (or at least hoped) it would be acceptable to provide a chart that allowed the reader to cross reference the AWG size against the locally relevant size. This firm is based here in the USA but working on a project outside the USA. Perhaps in that context this could be forgiven by the client. I don't know how well that approach will work for firms that are working at home, outside the USA.
Fwiw, Autodesk IS aware of this bias. Providing more flexibility is among the many things they have to find time to include in future releases.
Sunday, February 22, 2015
Importing CAD Files and Invert Colors
Autodesk help documentation offers this explanation for what happens when we use the Invert option for interpreting the colors in a CAD file when we import/link them (my emphasis added).
The following image is a small sample of what occurs. The top row of lines, imported using Preserve, have been assigned to the basic color palette and a couple extended colors, such as Red, Yellow, Blue and #10 (red) and #30 (amber). The bottom row of lines, imported using Invert, are how they are changed from the colors assigned in the CAD file once they are represented in Revit.
Looking closely, red becomes cyan. If you examine #10, a red also, you'll see that the Inverted color is also cyan or at least cyanish. Shades of red will be converted to shades of cyan. Compare the others and you'll see similar logic.
I don't use Invert, or recommend doing so, because the results are rarely meaningful or useful. You don't know why something is assigned to a given color. The simplistic goal is to just reverse (invert) the intensity of the color once it is imported, to make it easier to see on a white background or balance their appearance in this way.
If we really want to retain or use the color in some way then I believe it is better to keep (preserve) the colors we may already be familiar with, at least if we are responsible for creating that data too. That's my two pence worth.
Inverts the colors of all line and text objects from the imported file to Revit-specific colors. Dark colors become lighter, and light colors become darker. This can improve readability when the file is in Revit. This option is set by default.
The following image is a small sample of what occurs. The top row of lines, imported using Preserve, have been assigned to the basic color palette and a couple extended colors, such as Red, Yellow, Blue and #10 (red) and #30 (amber). The bottom row of lines, imported using Invert, are how they are changed from the colors assigned in the CAD file once they are represented in Revit.
Looking closely, red becomes cyan. If you examine #10, a red also, you'll see that the Inverted color is also cyan or at least cyanish. Shades of red will be converted to shades of cyan. Compare the others and you'll see similar logic.
I don't use Invert, or recommend doing so, because the results are rarely meaningful or useful. You don't know why something is assigned to a given color. The simplistic goal is to just reverse (invert) the intensity of the color once it is imported, to make it easier to see on a white background or balance their appearance in this way.
If we really want to retain or use the color in some way then I believe it is better to keep (preserve) the colors we may already be familiar with, at least if we are responsible for creating that data too. That's my two pence worth.
Saturday, February 21, 2015
Comments Deleted - Oops
Tonight I deleted three comments by mistake. I selected them to publish but when I moved my cursor to do so my sleeve caught and I clicked over the Delete button instead. Moving too clickly... very sorry. If you don't see your comment please feel free to do so again, if you feel motivated to do it, sorry.
Import CAD - Orient to View
This is what the Autodesk Help documentation says about this feature at the moment.
It also does something important or relevant when importing into elevation or section views. When people draw sections and elevations in CAD they are often doing so in the plan orientation of the file. It isn't all that common to see people reorienting their view in AutoCAD and then drawing those views oriented to Front or Back etc.
When we select this option and import such a file into a Revit elevation or section view it will rotate the plan of the CAD file into alignment with the section or elevation view. If not then the imported CAD file is aligned with the plan orientation of plan views and we only see the edge of the files lines in the elevation or section view.
If the option Current View Only is chosen then this On by default
Orient to View - This option is useful if True North and Project North are not aligned in your Revit project. If True North and Project North are defined identically in the project, then this option will not affect the way the import/link is oriented. The World Coordinate System (WCS) is used to orient the CAD file in the view.
If the current view is set to True North and True North is rotated away from Project North, then clear this option to align the CAD file with True North. If you select this option, the CAD file will align with Project North regardless of the view orientation. Note: CAD files are always imported into the current view from the top view direction. The CAD file is brought into the view assuming that the current view is a top view.
It also does something important or relevant when importing into elevation or section views. When people draw sections and elevations in CAD they are often doing so in the plan orientation of the file. It isn't all that common to see people reorienting their view in AutoCAD and then drawing those views oriented to Front or Back etc.
When we select this option and import such a file into a Revit elevation or section view it will rotate the plan of the CAD file into alignment with the section or elevation view. If not then the imported CAD file is aligned with the plan orientation of plan views and we only see the edge of the files lines in the elevation or section view.
If the option Current View Only is chosen then this On by default
Labels:
Importing Data,
Options,
Orientation,
Settings,
Tips,
Views
Friday, February 20, 2015
Video Settings and DPI
Be aware that Revit does not support increasing a computer's DPI (dot per square inch) video/graphics settings beyond 150%, assuming your computer permits it all. There are numerous cases where doing so causes either instability (crashing) or just poor graphic display quality.
Thursday, February 19, 2015
Copy Monitor - What Elements are in a Relationship?
A friend recently asked if there is an easy way to find out what elements are currently involved in a Copy/Monitor relationship. Good question! No easy button exists for this that I'm aware of. Sure we can select all grids and looks for C/M monitoring icons. That's not too hard for levels and grids. It's much less fun for walls, columns, floors or any of the MEP related categories that can be involved.
It might be an interesting question/problem for enterprising Dynamo aficionados or API programmers?
It would be nice to generate a report of the elements in a relationship and with which model and elements their relationship is based upon. I think it is just another example of the kind of refinement that Revit's collaboration tools ought to have.
It might be an interesting question/problem for enterprising Dynamo aficionados or API programmers?
It would be nice to generate a report of the elements in a relationship and with which model and elements their relationship is based upon. I think it is just another example of the kind of refinement that Revit's collaboration tools ought to have.
Wednesday, February 18, 2015
Starting View
I was reviewing old posts for something I thought I wrote about Starting Views. I was befuddled when I didn't find anything. I guess that's to be expected when I write things here and on several other webs sites like AUGI, RevitForum, and Autodesk Newsgroups. Enough about my confusion. Since I don't seem to have one already, here's one now.
Revit developers observed that users were creating simple drafting views that contained some project information and then encouraging or insisting users remember to open this particular view when they saved and closed their projects. This way when someone opened a project for the first time they'd always be greeted by this special view. It also takes Revit less time to open a simple view with no model representation involved. In response they introduced the Starting View as a feature. This special view can be assigned to any view including a sheet view.
Initially people were pleased and just referenced the view they were already using. Then some began experimenting with other view types. The Sheet View is particularly useful because it can use a custom title block family to provide the framework we might want for our Starting View, imagine the office bulletin board with a variety of important and often timely info about office parties and upcoming events. In the context of a project that means we can reference actual project information through labels/parameters instead of having people type some of this same information into text. This connection to live data is a natural progression, even expectation.
More recently Andre Carvalho shared (at RevitForum, see link below) how he uses a linked project file to manage project notes that need to be visible to projects that have several or many models or even expand beyond one project to all projects in the office. He can update the master project file and since all the related projects have this file linked into them the information is updated automatically for him each time any project file is opened. Pretty clever stuff, working within the confines of the tools we've got. If you'd like to read more CHECK IT OUT.
If you aren't taking advantage of Starting Views, let me encourage you to consider doing so.
Revit developers observed that users were creating simple drafting views that contained some project information and then encouraging or insisting users remember to open this particular view when they saved and closed their projects. This way when someone opened a project for the first time they'd always be greeted by this special view. It also takes Revit less time to open a simple view with no model representation involved. In response they introduced the Starting View as a feature. This special view can be assigned to any view including a sheet view.
Initially people were pleased and just referenced the view they were already using. Then some began experimenting with other view types. The Sheet View is particularly useful because it can use a custom title block family to provide the framework we might want for our Starting View, imagine the office bulletin board with a variety of important and often timely info about office parties and upcoming events. In the context of a project that means we can reference actual project information through labels/parameters instead of having people type some of this same information into text. This connection to live data is a natural progression, even expectation.
More recently Andre Carvalho shared (at RevitForum, see link below) how he uses a linked project file to manage project notes that need to be visible to projects that have several or many models or even expand beyond one project to all projects in the office. He can update the master project file and since all the related projects have this file linked into them the information is updated automatically for him each time any project file is opened. Pretty clever stuff, working within the confines of the tools we've got. If you'd like to read more CHECK IT OUT.
If you aren't taking advantage of Starting Views, let me encourage you to consider doing so.
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.
Monday, February 16, 2015
Reload From with Images
Luke mentioned the Reload From button in the Manage Images dialog in his post the other day.
While preparing for my What's New in Revit 2015 session at the Revit Technology Conference in Melbourne last year (image above is from the session's handout) I found that it didn't work well. The Reload From button didn't replace the image when it is referenced in system and component families. It only seemed to affect images placed on their own within the project. It only seemed reliable when I used the browse button for the image through the image parameters in the properties palette (or schedule).
After reading Luke's post I went back to test it again, since we've had six web updates since then, and I was pleased to find that Reload From and Reload worked as I'd expect it to!
I then thought it odd that there is no way to just Place an Image, to place another copy of an image somewhere else in the project. By that I mean, the Manage Images dialog offers an Add button to load an image. If we've just or already loaded an image, the Manage Images dialog also indicates when there is more than one instance of an image in use. It would seem useful, to me at least, to have a Place Image button.
We do have Decals but they are really intended for a different purpose. We also manage the related images for them separately from the Manage Images dialog. I suppose it is easy enough to select an existing image and paste another copy elsewhere. If I'm not sure where to find it (which means I may not realize there is one) a Place Image button would be handy though. The available images ought to show up in the Type Selector?
Regardless the Reload and Reload From buttons in the Manage Images dialog makes it easier to revise an image and then show that revised version in our project. It's almost like an external reference. Almost, except for the automatic reloading when a project opens.
While preparing for my What's New in Revit 2015 session at the Revit Technology Conference in Melbourne last year (image above is from the session's handout) I found that it didn't work well. The Reload From button didn't replace the image when it is referenced in system and component families. It only seemed to affect images placed on their own within the project. It only seemed reliable when I used the browse button for the image through the image parameters in the properties palette (or schedule).
After reading Luke's post I went back to test it again, since we've had six web updates since then, and I was pleased to find that Reload From and Reload worked as I'd expect it to!
I then thought it odd that there is no way to just Place an Image, to place another copy of an image somewhere else in the project. By that I mean, the Manage Images dialog offers an Add button to load an image. If we've just or already loaded an image, the Manage Images dialog also indicates when there is more than one instance of an image in use. It would seem useful, to me at least, to have a Place Image button.
We do have Decals but they are really intended for a different purpose. We also manage the related images for them separately from the Manage Images dialog. I suppose it is easy enough to select an existing image and paste another copy elsewhere. If I'm not sure where to find it (which means I may not realize there is one) a Place Image button would be handy though. The available images ought to show up in the Type Selector?
Regardless the Reload and Reload From buttons in the Manage Images dialog makes it easier to revise an image and then show that revised version in our project. It's almost like an external reference. Almost, except for the automatic reloading when a project opens.
Sunday, February 15, 2015
Schedule Text and Width Factor Fidelity
Schedules in Revit 2015 are able to use any of the text styles defined for a project. Text styles have supported the use of a Width Factor for several years. In schedules however this width factor is not observed so there is a loss of fidelity when comparing text elements and text that appears in schedules. The text above and below the schedule lines are using a width factor of 0.75 but the schedule rows do not look that same despite using the same text style.
Log this under Fit and Finish?
Log this under Fit and Finish?
Saturday, February 14, 2015
Text Formatting with Bold and Underline
Text is a common source of frustration in Revit. Replacing, improving the text editor remains a top rated wishlist item. Jean-Marc wrote to me the other day to mention something that I can assign to the Dept. of Subtle. If you use Bold and Underline on a portion of text and then transition to normal but still underlined Revit text doesn't deal with the underline transition well. Here's a comparison between what happens in Revit and Word.
I don't often use text but when I do I'm always wishing for that new text editor.
I don't often use text but when I do I'm always wishing for that new text editor.
Friday, February 13, 2015
Revising Keynote Data
When you use keynotes and realize you need to revise existing keynote information it easy to change what the keynote text value is. We just need to edit the existing information and reload the keynote file.
It's a little different situation when you decide you need to change the numbering that is already in play. It's no problem if you are just shuffling note information around so you get the numbering sequence you prefer. As long as the keynote value remains in the list Revit will find it. You just need to make sure that any elements that are supposed to carry a certain keynote value still do after you shuffle them.
However, if you revise things and introduce a new numbering scheme and reload the file you'll find the keynotes will get confused. They stop displaying the correct information. For example let's say the keynote that was number 1 is now the letter A. There isn't a separate GUID that is guiding this alignment of data, Revit is relying on the information in the text file entirely. So Revit doesn't find the number 1 anymore and can't pair up the keynote value and keynote text anymore. The tag just reports 1 since that's what was stored to begin with.
The best place to check and revise the keynote assignment after revising numbers is in the keynote legend. You'll be able to review each keynote and activate the keynote table via the Keynote Value parameter, the little browse button that appears when you click on the value in the schedule.
You can select each confused keynote and map it to the correct keynote value. Once you've revisited all of the affected keynotes in the legend you'll find that the keynote tags throughout the documentation will show the correct information again.
It's a little different situation when you decide you need to change the numbering that is already in play. It's no problem if you are just shuffling note information around so you get the numbering sequence you prefer. As long as the keynote value remains in the list Revit will find it. You just need to make sure that any elements that are supposed to carry a certain keynote value still do after you shuffle them.
However, if you revise things and introduce a new numbering scheme and reload the file you'll find the keynotes will get confused. They stop displaying the correct information. For example let's say the keynote that was number 1 is now the letter A. There isn't a separate GUID that is guiding this alignment of data, Revit is relying on the information in the text file entirely. So Revit doesn't find the number 1 anymore and can't pair up the keynote value and keynote text anymore. The tag just reports 1 since that's what was stored to begin with.
The best place to check and revise the keynote assignment after revising numbers is in the keynote legend. You'll be able to review each keynote and activate the keynote table via the Keynote Value parameter, the little browse button that appears when you click on the value in the schedule.
You can select each confused keynote and map it to the correct keynote value. Once you've revisited all of the affected keynotes in the legend you'll find that the keynote tags throughout the documentation will show the correct information again.
Thursday, February 12, 2015
Visibility of Floors and their Parts
Floors are unique in that Revit will show them even if they are below the view range settings of the view (floor plan). They'll be visible until they exceed 4' (1200mm) below the level. Parts that are created from floors won't. In fact parts created from a floor that is at the level of the view (in other words, normal) won't show up either.
It is necessary to adjust the View Range to permit the parts to be visible. It would be more consistent with floors if their parts assumed the same quirk capability.
It is necessary to adjust the View Range to permit the parts to be visible. It would be more consistent with floors if their parts assumed the same quirk capability.
Labels:
Floors,
Parts,
Troubleshooting,
View Range,
Visibility
Wednesday, February 11, 2015
Sorting Parameters - Shared Parameters and Projects
With 2015 it became possible to move parameters into more desirable positions within the properties of the family. In the family editor we see a Move Up and Move Down button to make this possible.
In projects however there are circumstances where taking the trouble to do this in the family doesn't have the same result in a project. A thread started at Autodesk's Revit Newsgroups where a product support specialist (Alaaeldin_Alsahil) responded with the following:
He then added:
He suggested a workaround of creating a brand new shared parameter definition (new parameter in the shared parameter file), so that the definition in the project can be redefined. That's not always possible, in fact more than likely not acceptable either. For this project we'll have to live with the sorting condition as is. He did mention that loading content into project template files don't seem to suffer the same fate. That's good at least from a template standpoint.
In projects however there are circumstances where taking the trouble to do this in the family doesn't have the same result in a project. A thread started at Autodesk's Revit Newsgroups where a product support specialist (Alaaeldin_Alsahil) responded with the following:
Shared parameters are shared between families in the project. The first family to load a shared parameter definition into the project defines the behavior of the parameter (in other words when loading a family into the project the description stored in the document is the one that is used). In this case, there was probably a family that was loaded with these parameters defined as "Other than the one from the family".
He then added:
The biggest problem is the shared parameter definition in the document cannot be edited (or deleted!) from the project. Purge unused also does not clear these definitions. There is no way for the customer to fix their file.
He suggested a workaround of creating a brand new shared parameter definition (new parameter in the shared parameter file), so that the definition in the project can be redefined. That's not always possible, in fact more than likely not acceptable either. For this project we'll have to live with the sorting condition as is. He did mention that loading content into project template files don't seem to suffer the same fate. That's good at least from a template standpoint.
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.
Labels:
Annotation,
Bug,
Callout,
Dept. of Quirky,
Detailing,
Details,
Electrical,
MEP,
Views
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.
Labels:
Annotation,
Parameters,
Tags
Sunday, February 08, 2015
Leaders and Tags
A frequent source of frustration is how leaders relate to the information in tags. The more complicated a tag family is the harder it becomes to ensure the tag's leader(s) will align with the graphics or text it has. A leader connects to the midpoint along the overall extents of a tag's graphics and labels. Imagine a rectangle that surrounds all of the graphics in your tag (see and unseen), the overall extent of that information. The leader connects to the midpoint on this rectangle on each of its four sides as you drag the leader around the tag.
It is possible to play tricks with invisible lines to increase or decrease the perceived size of the tag so this elusive midpoint leader connection point can be controlled. It takes some experimentation and only one little circumstance we didn't anticipate to mess things up. This is just a simple example, using the stock room tag family, that illustrates how the leaders are too arbitrary.
They work okay for a couple instances but for others they don't. In this case Volume isn't getting calculated at the moment so the information displayed is too long and it messes up the leader location. In a big enough room the calculated volume value could easily be long enough to do the same thing to the tag.
We want/need a definitive way to tell Revit where a leader should connect to the tag information. I recently ran across a suggestion that I'd love to see happen. You probably already know that Revit MEP content uses connectors to define where pipe/duct/electrical relationships start or connect. What if we had a Leader connector element we could add to our tag families? Something like this perhaps?
I've added numbers to define the priority for the leader connectors, like adaptive point families have for example. As I drag a leader around a tag Revit should adjust the leader shoulder to connect to the next numbered connector. For those that are close to one another (in the same quadrant) the TAB key should cycle, or just cycle through all the possible connectors.
The information supplied to the parameters displayed in a tag could still mess up the leader location but no solution will be perfect. At least with a specific location we can concentrate on designing a tag that will work nearly perfectly. If we can't control the length of the data in the labels then we just need a way to adjust the connector's location relative to the information. This means we'd need to be able to add dimensions and constrain the connector locations with parameters too.
I'd also love to be able to use a parameter to control the length of a label in a tag. This would allow us to increase the overall length of the data that shows up before wrapping to a new line. Combining that with parameters to control the location of leader connectors would provide considerable control of the tag and its leader(s).
It is possible to play tricks with invisible lines to increase or decrease the perceived size of the tag so this elusive midpoint leader connection point can be controlled. It takes some experimentation and only one little circumstance we didn't anticipate to mess things up. This is just a simple example, using the stock room tag family, that illustrates how the leaders are too arbitrary.
They work okay for a couple instances but for others they don't. In this case Volume isn't getting calculated at the moment so the information displayed is too long and it messes up the leader location. In a big enough room the calculated volume value could easily be long enough to do the same thing to the tag.
We want/need a definitive way to tell Revit where a leader should connect to the tag information. I recently ran across a suggestion that I'd love to see happen. You probably already know that Revit MEP content uses connectors to define where pipe/duct/electrical relationships start or connect. What if we had a Leader connector element we could add to our tag families? Something like this perhaps?
I've added numbers to define the priority for the leader connectors, like adaptive point families have for example. As I drag a leader around a tag Revit should adjust the leader shoulder to connect to the next numbered connector. For those that are close to one another (in the same quadrant) the TAB key should cycle, or just cycle through all the possible connectors.
The information supplied to the parameters displayed in a tag could still mess up the leader location but no solution will be perfect. At least with a specific location we can concentrate on designing a tag that will work nearly perfectly. If we can't control the length of the data in the labels then we just need a way to adjust the connector's location relative to the information. This means we'd need to be able to add dimensions and constrain the connector locations with parameters too.
I'd also love to be able to use a parameter to control the length of a label in a tag. This would allow us to increase the overall length of the data that shows up before wrapping to a new line. Combining that with parameters to control the location of leader connectors would provide considerable control of the tag and its leader(s).
Labels:
Dept. of Wishes,
Leaders,
Tags,
Wishlist
Saturday, February 07, 2015
Revit 2015 MEP - Calculations and Performance
When Revit 2015 Update Release 3 became available a new MEP setting became available for Pipe and Duct Systems called Performance Mode. If you examine the Type Properties of a Piping system (or Duct) you'll find this additional setting.
The help documentation (link below) offers up this table to break down which system classification calculations are made available to us and which are able to take advantage of this new Performance choice.
This is intended to improve performance when working/editing large MEP system networks. For each system type we choose to assign this Performance setting to, Revit's system propagation is disabled on every system assigned to that system type. The Calculations parameter can be included in schedules, which can make it easier to toggle on and off. Keep in mind, if the file is opened in a previous build (not Update Release 3 or newer) then the parameter may/will not display correctly.
At first glance it doesn't seem much different from choosing None because to restore system propagation we have to change the setting back to use a calculation method, other than Performance or None. My initial expectation was that None would shut down calculations entirely and Performance would permit some calculations but do so in a way that would improve my experience or perception of performance, Revit's responsiveness as I work.
As I've learned from the developers, despite carrying a name that suggests to me otherwise, under the hood, using None does NOT tell Revit to completely ignore everything related to the connected network. This new Performance setting DOES allow Revit to completely ignore any system (as far as calculation propagation is concerned) that is assigned to the Performance setting.
As I understand them, the two choices are a trade off between accepting slower performance for each and every model (our) interaction (by choosing None) or having a quicker response (from Revit) for each model interaction, choosing instead to endure a longer wait after turning back on calculations (using Performance). Perhaps in a future release we'll just see None eliminated or replaced by Performance? At the very least I think the naming is a bit misleading.
A side effect of using this setting is that duct/pipe sizing and the System Inspector will not work on systems that are assigned to it either.
You can READ the Help Documentation HERE.
The help documentation (link below) offers up this table to break down which system classification calculations are made available to us and which are able to take advantage of this new Performance choice.
This is intended to improve performance when working/editing large MEP system networks. For each system type we choose to assign this Performance setting to, Revit's system propagation is disabled on every system assigned to that system type. The Calculations parameter can be included in schedules, which can make it easier to toggle on and off. Keep in mind, if the file is opened in a previous build (not Update Release 3 or newer) then the parameter may/will not display correctly.
At first glance it doesn't seem much different from choosing None because to restore system propagation we have to change the setting back to use a calculation method, other than Performance or None. My initial expectation was that None would shut down calculations entirely and Performance would permit some calculations but do so in a way that would improve my experience or perception of performance, Revit's responsiveness as I work.
As I've learned from the developers, despite carrying a name that suggests to me otherwise, under the hood, using None does NOT tell Revit to completely ignore everything related to the connected network. This new Performance setting DOES allow Revit to completely ignore any system (as far as calculation propagation is concerned) that is assigned to the Performance setting.
As I understand them, the two choices are a trade off between accepting slower performance for each and every model (our) interaction (by choosing None) or having a quicker response (from Revit) for each model interaction, choosing instead to endure a longer wait after turning back on calculations (using Performance). Perhaps in a future release we'll just see None eliminated or replaced by Performance? At the very least I think the naming is a bit misleading.
A side effect of using this setting is that duct/pipe sizing and the System Inspector will not work on systems that are assigned to it either.
You can READ the Help Documentation HERE.
Friday, February 06, 2015
Grid Bubble at Second End
Occasionally I get this question, "Why does the grid bubble always show up at the second point? I wish it was at the first point. I'd like to start at the bubble and draw from there." The answer is you can! It's just a setting, a simple one at that. This is the Type Properties dialog for a grid type.
Notice the highlighted parameters? End 1 is the Start (first pick point) and End 2 is the End (second pick point). If you want to sketch grids starting with the Bubble just switch the check marks. End 1 should be checked and End 2 should not. Make this adjustment in your project template and you'll not have to worry about it again, hopefully.
Same thing is true for Levels by the way.
Notice the highlighted parameters? End 1 is the Start (first pick point) and End 2 is the End (second pick point). If you want to sketch grids starting with the Bubble just switch the check marks. End 1 should be checked and End 2 should not. Make this adjustment in your project template and you'll not have to worry about it again, hopefully.
Same thing is true for Levels by the way.
Labels:
Customization,
Graphics,
Grids,
Templates,
Tips
Thursday, February 05, 2015
Gaps in Grids
Some people do not like grids that extend entirely through a model. I usually hear about this in building elevations. They want the grids to stop just above the model. That is easy to do when we toggle from 3D to 2D. We can drag the 2D extent of the grid above the building. If we turn on the crop boundary of the view and make sure it intersects the grids we can drag them all together faster than doing it one at time.
Some want similar behavior in plan views too. We can do the same thing unless they also want the grids to appear on both sides of the model. In this case we can use the Center Segment parameter that is part of grid types. The stock Revit templates provide three grid types: 1/4" Bubble, 1/4" Bubble Custom Gap, and 1/4" Bubble Gap. They look like this.
If we want to stop the grid from traveling all the way through a model we can use the 1/4" Bubble Gap type. The gap is created with the Center Segment parameter by using None instead of Continuous or Custom. Choosing Custom enables (turns on) three new parameters: Center Segment Weight, Center Segment Color and Center Segment Pattern (a Line Pattern).
People also ask to be able to adjust this gap differently in different plan views. At first it doesn't seem possible because adjusting one does affect other views, until you toggle the 3D status to 2D. Once the grid is using the 2D mode we can alter the gap differently in that view when compared with other views. This gap does affect elevations and sections. This means you'll have to adjust the extents of the gap in those views too, especially if you don't want the gap to show up in those views at all.
It's like Spiderman's Uncle said, "...with great power comes great responsibility". The more subtle features we engage the more work it is to manage them.
By the way, this isn't possible with Levels. There is no Center Segment parameter. There are occasions where it would be helpful if we could do this for Levels too.
Some want similar behavior in plan views too. We can do the same thing unless they also want the grids to appear on both sides of the model. In this case we can use the Center Segment parameter that is part of grid types. The stock Revit templates provide three grid types: 1/4" Bubble, 1/4" Bubble Custom Gap, and 1/4" Bubble Gap. They look like this.
If we want to stop the grid from traveling all the way through a model we can use the 1/4" Bubble Gap type. The gap is created with the Center Segment parameter by using None instead of Continuous or Custom. Choosing Custom enables (turns on) three new parameters: Center Segment Weight, Center Segment Color and Center Segment Pattern (a Line Pattern).
People also ask to be able to adjust this gap differently in different plan views. At first it doesn't seem possible because adjusting one does affect other views, until you toggle the 3D status to 2D. Once the grid is using the 2D mode we can alter the gap differently in that view when compared with other views. This gap does affect elevations and sections. This means you'll have to adjust the extents of the gap in those views too, especially if you don't want the gap to show up in those views at all.
It's like Spiderman's Uncle said, "...with great power comes great responsibility". The more subtle features we engage the more work it is to manage them.
By the way, this isn't possible with Levels. There is no Center Segment parameter. There are occasions where it would be helpful if we could do this for Levels too.
Wednesday, February 04, 2015
Using Shared Coordinates - Do Not Remove the Link
I hear and read quite often these days that people will use Acquire Coordinates on an imported file and then remove the link. They import the source file again but use Positioning: Auto by Shared Coordinates. The reason offered is usually that they are doing it because they want to prove to themselves that the file IS sharing coordinates.
It is NOT a necessary step. Don't bother to do it. It won't harm your project if you do, it's just pointless.
It is NOT a necessary step. Don't bother to do it. It won't harm your project if you do, it's just pointless.
Tuesday, February 03, 2015
Revit MEP - Conduit Run Schedule is Biased
I think it is a Reviteristic (read quirky or bizarre) that a Conduit Run Schedule will only see types that are created based on Conduit without Fittings. I'm pretty sure we'd all like schedules to include runs that use Conduit WITH fittings too. I understand that the fittings make it harder to provide a summary of a run but that's kind of the point isn't it, to do the things that are hard for us?
If we follow the help documentation advice to add a shared parameter to conduit and conduit fittings we can create a schedule that summarizes runs via a Multi-Category schedule. Unfortunately the very desirable and important Length parameter dies to us in that context, no joy there.
If we follow the help documentation advice to add a shared parameter to conduit and conduit fittings we can create a schedule that summarizes runs via a Multi-Category schedule. Unfortunately the very desirable and important Length parameter dies to us in that context, no joy there.
Monday, February 02, 2015
Revit MEP - Piping Offset from other Elements
When we sketch a wall we can provide an offset value on the Options Bar and then use the Space Bar to flip the side of the reference points we provide during sketching.
That flows pretty well (pun intended). It's not so fluid when using the Duct and Pipe tools. The Offset feature is hiding in the Justification Settings dialog AND the Space Bar concept doesn't work. We have to provide a negative value or be careful to start sketching in a specific direction to get the opposite offset.
This makes sketching pipe with a specific offset value relative to walls and other elements tedious. I think it is very likely (even much more so) to want to create pipe and duct taking into account adjacent elements like walls and structure AND provide an offset while doing so...it would be a lot more fun if there wasn't this extra little dialog hassle to do so.
That flows pretty well (pun intended). It's not so fluid when using the Duct and Pipe tools. The Offset feature is hiding in the Justification Settings dialog AND the Space Bar concept doesn't work. We have to provide a negative value or be careful to start sketching in a specific direction to get the opposite offset.
This makes sketching pipe with a specific offset value relative to walls and other elements tedious. I think it is very likely (even much more so) to want to create pipe and duct taking into account adjacent elements like walls and structure AND provide an offset while doing so...it would be a lot more fun if there wasn't this extra little dialog hassle to do so.
Sunday, February 01, 2015
Revit 2015 Update Release 6 is Available
Luke at What Revit Wants must have bugs hiding at Autodesk. They don't even seem to know at Autodesk's own site, but he does.
Regardless, Luke knows and I've downloaded and installed it already. Thanks!
CLICK ME to read his blog post!
Regardless, Luke knows and I've downloaded and installed it already. Thanks!
CLICK ME to read his blog post!
Labels:
News,
Release Update,
Revit 2015
Phases and Phase Filters Follow Up
I received a comment from a reader asking how to show all the elements in a view after having done the demolition work. The Phase Filter Show All should provide this however in this case they were attempting to show everything from a later phase. In this scenario there are three phases: Phase 1 (existing), Phase 2 (new work) and Phase 3 (the view they want to see things from).
That poses a problem because the earlier work (demolition and temporary) will not be displayed anymore because it is "gone" when you move forward in time to a view assigned to phase 3. This image is of a 3D view that is assigned to Phase 2 using Phase Filter Show All.
In Phase 3 items that were created in Phase 1 and 2 are both regarded as existing now, as long as they were not also demolished since they were created. Once they are demolished they no longer "exist" as far as that View and Phase Filters are concerned. This is what we see in Phase 3 with Phase Filter Show All.
To show all the proposed work together, Phase 1 (existing) and Phase 2 (new work) should be sufficient. In a view assign it to Phase 2 and use Show All Phase Filter. It is important to understand that elements always belong to a particular phase but their appearance (controlled by Phase Graphic Overrides) is affected by the Phase settings of the view they are seen in and that changes from view to view.
We really can only see all elements, including those that have been demolished or are temporary from a view assigned to "now" and one phase further in the past. Any further in the past than one phase and those demolished and temporary items are no longer part of our virtual world.
That poses a problem because the earlier work (demolition and temporary) will not be displayed anymore because it is "gone" when you move forward in time to a view assigned to phase 3. This image is of a 3D view that is assigned to Phase 2 using Phase Filter Show All.
In Phase 3 items that were created in Phase 1 and 2 are both regarded as existing now, as long as they were not also demolished since they were created. Once they are demolished they no longer "exist" as far as that View and Phase Filters are concerned. This is what we see in Phase 3 with Phase Filter Show All.
To show all the proposed work together, Phase 1 (existing) and Phase 2 (new work) should be sufficient. In a view assign it to Phase 2 and use Show All Phase Filter. It is important to understand that elements always belong to a particular phase but their appearance (controlled by Phase Graphic Overrides) is affected by the Phase settings of the view they are seen in and that changes from view to view.
We really can only see all elements, including those that have been demolished or are temporary from a view assigned to "now" and one phase further in the past. Any further in the past than one phase and those demolished and temporary items are no longer part of our virtual world.
Subscribe to:
Posts (Atom)