Welcome to Steve Stafford's Blog ~ Revit OpEd = OPinion EDitorial ~ My view of things Revit, both real and imagined.
Friday, October 31, 2014
Confirm Acquire Coordinates
I'd like Revit to display a confirmation when I successfully acquire coordinates. It would also be nice if it displayed the coordinate "shift" that occurred in the dialog too. If I failed to select a source then it would be nice if Revit let me know I failed, try try again.
Tuesday, October 28, 2014
Occupancy Calculations and JavaScript
The other day I read a post at Revit Add-ons about integrating Java Scripts into Revit. I was intrigued by an example it described which provides a connection between a java script calculation (formula) and assigns it to a parameter. A very common request among Revit users is to be able to associate with a formula with a Shared Parameter, and in this case occupancy calculations. Timing is a funny thing because an email came in the same day asking for advice doing these calculations.
The application is called LazJS and is currently offering a beta version 1.0. Fwiw, I created an Occupancy Calculation sample project years ago which you can download HERE. I thought I'd open that project and try LazJS out on it. Since we can't put a calculated value in a tag the example uses a schedule so we can transfer values manually. With the advent of the API there are more options but for anyone who is leery of programming it's still a bit intimidating.
I found it was really easy to get this installed and configure LazJS to fill in the values for me automatically and keep them updated if I make any changes. This is the dialog that appears for their ParamJS tool. I started by choosing the Rooms category. Then I chose the parameter that is in my room tag. Then I dragged the parameter whose value I wanted to be in the tag up to the code editor window. Once the code was present I clicked Run, seeing values in the results window I clicked Save.
Now whenever I add a room and assign a occupancy type its tag fills in the appropriate Occupancy Factor for me (the script does). Same for any editing I do of existing rooms.
Worth a closer look if only for this piece of their whole application.
The application is called LazJS and is currently offering a beta version 1.0. Fwiw, I created an Occupancy Calculation sample project years ago which you can download HERE. I thought I'd open that project and try LazJS out on it. Since we can't put a calculated value in a tag the example uses a schedule so we can transfer values manually. With the advent of the API there are more options but for anyone who is leery of programming it's still a bit intimidating.
I found it was really easy to get this installed and configure LazJS to fill in the values for me automatically and keep them updated if I make any changes. This is the dialog that appears for their ParamJS tool. I started by choosing the Rooms category. Then I chose the parameter that is in my room tag. Then I dragged the parameter whose value I wanted to be in the tag up to the code editor window. Once the code was present I clicked Run, seeing values in the results window I clicked Save.
Now whenever I add a room and assign a occupancy type its tag fills in the appropriate Occupancy Factor for me (the script does). Same for any editing I do of existing rooms.
Worth a closer look if only for this piece of their whole application.
Labels:
3rd Party Apps,
Add-ons,
Java,
Occupancy,
Programming,
Scripts,
Tips,
Tools
Monday, October 27, 2014
Visible Parameter and Associate Family Parameter
When we work with Forms, Symbolic and Model lines and nested families they each have a parameter called Visible and we can use Associate Family Parameter to control their visibility.
If you decide to remove this relationship Revit applies the current state of the parameter that was controlling it to the Visible parameter. If it was checked (visible on) then removing the parameter relationship leaves it checked. If the reverse is true (visible off) then the opposite happens.
It's subtle and can cause a few minutes of confusion when you reload a family and find it isn't visible.
If you decide to remove this relationship Revit applies the current state of the parameter that was controlling it to the Visible parameter. If it was checked (visible on) then removing the parameter relationship leaves it checked. If the reverse is true (visible off) then the opposite happens.
It's subtle and can cause a few minutes of confusion when you reload a family and find it isn't visible.
Friday, October 24, 2014
Including a Sheet File Name and Path
Ever since we started using computers to generate architectural and engineering drawings we've been inclined to provide a place on a title block to help people find the file. Sometimes it is just the file name and other times it is necessary to have both the file name and path to the folder it is in.
The path is useful to the team working on the files but if those files are passed along to someone else it may be meaningless to them, or confusing at the very least. The file name is useful to anyone who happens to be looking at the drawings as long as they are in a position to access the digital version of the file too.
In a Revit model, which usually contains all the sheets for a project, the file name doesn't have the same usefulness when compared to a file based system like AutoCAD. That's true unless you are printing multiple layouts from a single DWG file, then it's not all that different than Revit. When someone is looking at a printed sheet and sees the file name and path it doesn't help them find the digital version, like a PDF file for Sheet A100 for example, because the file name is the Revit model, not the resulting PDF export.
As such Revit misses the mark in helping us carrying on that tradition. Since there are a number of ways our sheets can end up as individual files it is hard for Revit to anticipate or provide a suitable way to plug in a unique value until the data is exported outside of Revit. I'm sure there are some things that they could do to help us with this but it hasn't happened yet.
Revit's API could be used to capture the sheet information and store a contrived file name in a parameter for each sheet. When we print or export we might end up with the correct file names matching the resulting files or bearing a slight difference. I don't recall an existing application that deals with this specifically but one might exist, like Xrev Tools for example.
If we forget limitations within Revit for the moment, since the output format of a set of documents is where the appropriate file data is really needed it might make sense to consider focusing on how we handle the output files instead, at least for now. For example, the company Bluebeam offers software to process, review, and markup PDF documents. It includes the ability to add custom headers and footers, which can be the file name (among other things). It can also Batch Process files to include the file name. The file path is another available choice to put in a header or footer so we can combine them if we want to include both.
If it is necessary to provide the specific file name (and path) for exports to DWG it is probably best to add it those files after exporting, this way they'll point to an actual file instead of the Revit project file. Again some customization could add the necessary fields pretty effectively.
It seems like post processing this information is probably as effective as trying to come up with a way to deal with it internally in Revit.
The path is useful to the team working on the files but if those files are passed along to someone else it may be meaningless to them, or confusing at the very least. The file name is useful to anyone who happens to be looking at the drawings as long as they are in a position to access the digital version of the file too.
In a Revit model, which usually contains all the sheets for a project, the file name doesn't have the same usefulness when compared to a file based system like AutoCAD. That's true unless you are printing multiple layouts from a single DWG file, then it's not all that different than Revit. When someone is looking at a printed sheet and sees the file name and path it doesn't help them find the digital version, like a PDF file for Sheet A100 for example, because the file name is the Revit model, not the resulting PDF export.
As such Revit misses the mark in helping us carrying on that tradition. Since there are a number of ways our sheets can end up as individual files it is hard for Revit to anticipate or provide a suitable way to plug in a unique value until the data is exported outside of Revit. I'm sure there are some things that they could do to help us with this but it hasn't happened yet.
Revit's API could be used to capture the sheet information and store a contrived file name in a parameter for each sheet. When we print or export we might end up with the correct file names matching the resulting files or bearing a slight difference. I don't recall an existing application that deals with this specifically but one might exist, like Xrev Tools for example.
If we forget limitations within Revit for the moment, since the output format of a set of documents is where the appropriate file data is really needed it might make sense to consider focusing on how we handle the output files instead, at least for now. For example, the company Bluebeam offers software to process, review, and markup PDF documents. It includes the ability to add custom headers and footers, which can be the file name (among other things). It can also Batch Process files to include the file name. The file path is another available choice to put in a header or footer so we can combine them if we want to include both.
If it is necessary to provide the specific file name (and path) for exports to DWG it is probably best to add it those files after exporting, this way they'll point to an actual file instead of the Revit project file. Again some customization could add the necessary fields pretty effectively.
It seems like post processing this information is probably as effective as trying to come up with a way to deal with it internally in Revit.
Thursday, October 23, 2014
Filter Filtering Gotcha
When you create or edit a view Filter we can apply a Filter to the list of categories based on discipline.
Filtering the list of categories has a direct impact on the Filter Rules > Filter by: list too. If you tell Revit to only show you Architecture categories then you'll find the available parameters listed in the Filter by: criteria drop down will not include parameters that are related to other disciplines. For example, if you were hoping to use the filter to alter the way MEP elements look when they are linked into your model then you might be confused until you realize that earlier you told Revit to only show you Architectural stuff.
Remember the Filter's Filter. Same thing can happen in the View Templates, Visibility/Graphics dialog and Object Styles dialogs.
Filtering the list of categories has a direct impact on the Filter Rules > Filter by: list too. If you tell Revit to only show you Architecture categories then you'll find the available parameters listed in the Filter by: criteria drop down will not include parameters that are related to other disciplines. For example, if you were hoping to use the filter to alter the way MEP elements look when they are linked into your model then you might be confused until you realize that earlier you told Revit to only show you Architectural stuff.
Remember the Filter's Filter. Same thing can happen in the View Templates, Visibility/Graphics dialog and Object Styles dialogs.
Wednesday, October 22, 2014
Local File Error on Open
Have you run into this error message before?
One possible reason is that the folder you are storing local files is running out of allowable space. A folder can have restrictions placed on it. If so Revit can't properly create the local file in a folder that has hit its quota.
When we create a new local file we can often avoid this if we use the option to Overwrite the existing local file versus the Append Timestamp option. Chances are there are just a great many older local files hanging around in the folder.
One possible reason is that the folder you are storing local files is running out of allowable space. A folder can have restrictions placed on it. If so Revit can't properly create the local file in a folder that has hit its quota.
When we create a new local file we can often avoid this if we use the option to Overwrite the existing local file versus the Append Timestamp option. Chances are there are just a great many older local files hanging around in the folder.
Tuesday, October 21, 2014
Revit MEP Pipe Appearance in Sections
I met Freddie at the BIM Workshop in Anaheim recently. We chatted for awhile about Revit (shock I know) and then a little about music. It was great to meet someone who wasn't necessarily required to know Revit but decided he wanted to learn Revit and has become quite good at it. The company he works for (TJP Engineering) specializes in water treatment systems for aquatic attractions.
He passed along a graphic that Chris Aquino (Autodesk support specialist) marked up for him when he was trying to sort out piping graphics in section views. Sometimes writing this blog only requires sharing what other people tell me, thanks Freddie!
Here's the image which has markups that explain the various conditions they discussed.
Quick Summary of Issues:
Btw, my Uncle Ben called me Freddie when I was a kid. I. Don't. Know. Why... :)
He passed along a graphic that Chris Aquino (Autodesk support specialist) marked up for him when he was trying to sort out piping graphics in section views. Sometimes writing this blog only requires sharing what other people tell me, thanks Freddie!
Here's the image which has markups that explain the various conditions they discussed.
Quick Summary of Issues:
- No rise/drop symbol? Most likely the pipe is sloping "through" the section.
- If you see a "crosshair" or "target" it is probably the pipe beyond the fitting but within the Far Clip Plane of the view.
Btw, my Uncle Ben called me Freddie when I was a kid. I. Don't. Know. Why... :)
Monday, October 20, 2014
Revit 2015 - Closing a Workset and Linked File Ownership Conflict
This post describes an awkward issue with Revit 2015 when using a specific workset(s) to manage a linked file(s).
Project File A has a separate workset for Project File B and that file is assigned to it. Both the linked file's instance and type parameters are assigned to the same workset. User A is the Owner of Project File B's workset. Now User B is working in their own local file and decides to close the Project File B workset (instead of using the Manage Links > Unload method). User B gets a warning that User A owns the element.
When we expand the warning we see that the file is the issue.
User B clicks Cancel and the workset closes, the link is no longer visible (the desired result despite the message). If User B Opens the workset, no error. The error only occurs when the workset is closed.
Closing a workset that has a linked file associated with it now is equivalent to using Manage Links > Unload, because using unload generates this error message now too.
This error dialog is very confusing because it claims that we can't do something, without creating an Editing Request, that clicking Cancel does let us do. We now have a normal error message that we have to tell users they can ignore, click cancel please. That's just ridiculous.
Demand loading and unloading worksets is fundamental and critical for large projects. Large projects have many people contributing so now we'll have many people getting a pointless message.
Project File A has a separate workset for Project File B and that file is assigned to it. Both the linked file's instance and type parameters are assigned to the same workset. User A is the Owner of Project File B's workset. Now User B is working in their own local file and decides to close the Project File B workset (instead of using the Manage Links > Unload method). User B gets a warning that User A owns the element.
When we expand the warning we see that the file is the issue.
User B clicks Cancel and the workset closes, the link is no longer visible (the desired result despite the message). If User B Opens the workset, no error. The error only occurs when the workset is closed.
Closing a workset that has a linked file associated with it now is equivalent to using Manage Links > Unload, because using unload generates this error message now too.
This error dialog is very confusing because it claims that we can't do something, without creating an Editing Request, that clicking Cancel does let us do. We now have a normal error message that we have to tell users they can ignore, click cancel please. That's just ridiculous.
Demand loading and unloading worksets is fundamental and critical for large projects. Large projects have many people contributing so now we'll have many people getting a pointless message.
Thursday, October 16, 2014
Parameters with Math Characters
Kudos to GMcDowellJr at RevitForum.org for paying attention. I missed it entirely. We've been careful to warn people not to include math characters in their parameters names for so long that I just don't ever try to do it.
At some point in the recent past (my testing shows beginning with Revit 2014) Revit started reconciling the issue for us with these brackets [ ]. Just wrap your rogue parameter name using math characters with those brackets and Revit won't mind anymore.
Revit will even add them (the brackets) for us if we rename a parameter to include math symbol(s). For example, in the following image these parameters and the formula are fine.
Then I changed my parameter name and Revit put the brackets in the formula for me.
When I try this in Revit 2013 it doesn't mind changing a parameter name to include a math symbol if it didn't have one originally. If I try to create a new parameter with a math character and use it in a formula then I get the familiar warning. If I add the brackets myself, no difference. In 2014 and 2015 the brackets start working and get added to a formula for us, when necessary.
I don't recall The Factory ever taking credit for this change, a nice subtle compensation for parameter naming.
At some point in the recent past (my testing shows beginning with Revit 2014) Revit started reconciling the issue for us with these brackets [ ]. Just wrap your rogue parameter name using math characters with those brackets and Revit won't mind anymore.
Revit will even add them (the brackets) for us if we rename a parameter to include math symbol(s). For example, in the following image these parameters and the formula are fine.
Then I changed my parameter name and Revit put the brackets in the formula for me.
When I try this in Revit 2013 it doesn't mind changing a parameter name to include a math symbol if it didn't have one originally. If I try to create a new parameter with a math character and use it in a formula then I get the familiar warning. If I add the brackets myself, no difference. In 2014 and 2015 the brackets start working and get added to a formula for us, when necessary.
I don't recall The Factory ever taking credit for this change, a nice subtle compensation for parameter naming.
Wednesday, October 15, 2014
Stage Curtains
Back in January of 2004, about eleven months before I started blogging and a couple months before moving to California, I shared a couple stage curtain families at AUGI. They were made using Revit 6.0. I recently got a message thanking me for them which made me curious how well they'd upgrade to Revit 2015. I downloaded them from AUGI too since I'd lost track of the files since then. They upgraded fine. Well, without a warning message but they didn't retain all their parametric behavior unfortunately.
If you're like me, you can't help but second guess the things you did when you get to take another look at something you did in the past. This is no different. I didn't like my choice of parameter names and the logic I used to allow for them to be reconfigured. So I spent some time re-working them in Revit 2015.
Here's what they look like in play now, the main setting is a burgundy color, the olio setting is a lighter shade and the cyclorama legs, borders and rear traveler are just black (though they look gray). If you aren't familiar with theater terminology, the olio setting is traditionally fancy or at least a different color. It is typically used (closed in front of the stage set) as the background for the opening act of a show, comedian, magician etc., far enough forward to leave most of the stage for the primary production (hidden from view), close behind the main curtain setting but leaving some stage space for the intro act.
And in plan view
And in Section
If you'd like to download them here you go:
2015 Stage Curtain Border
2015 Stage Curtain Traveler
If you need them in an earlier version than 2015 these are the Revit 6.0 files. You'll probably have to tweak them a bit to retain their parametric relationships, such as changing the height of the curtain or length of the batten etc.
Revit 6.0 Border Curtain
Revit 6.0 Traveler Curtain
I'll close with a rendered view using some stage lighting fixtures that Andrew K shared at RevitForum.org (works with ARCAT) and a couple saxophones that Michael Anonuevo shared with me back when he was working on his family editor book.
I did consider rebuilding these using the new Adaptive Point divide and repeat concept. Perhaps another day. It would be interesting to compare the performance of that technique against these. These do put a bit of a drag on a model because of the blend array that makes the curtain.
Okay, now I'm just having fun...
If you're like me, you can't help but second guess the things you did when you get to take another look at something you did in the past. This is no different. I didn't like my choice of parameter names and the logic I used to allow for them to be reconfigured. So I spent some time re-working them in Revit 2015.
Here's what they look like in play now, the main setting is a burgundy color, the olio setting is a lighter shade and the cyclorama legs, borders and rear traveler are just black (though they look gray). If you aren't familiar with theater terminology, the olio setting is traditionally fancy or at least a different color. It is typically used (closed in front of the stage set) as the background for the opening act of a show, comedian, magician etc., far enough forward to leave most of the stage for the primary production (hidden from view), close behind the main curtain setting but leaving some stage space for the intro act.
And in plan view
And in Section
If you'd like to download them here you go:
2015 Stage Curtain Border
2015 Stage Curtain Traveler
If you need them in an earlier version than 2015 these are the Revit 6.0 files. You'll probably have to tweak them a bit to retain their parametric relationships, such as changing the height of the curtain or length of the batten etc.
Revit 6.0 Border Curtain
Revit 6.0 Traveler Curtain
I'll close with a rendered view using some stage lighting fixtures that Andrew K shared at RevitForum.org (works with ARCAT) and a couple saxophones that Michael Anonuevo shared with me back when he was working on his family editor book.
I did consider rebuilding these using the new Adaptive Point divide and repeat concept. Perhaps another day. It would be interesting to compare the performance of that technique against these. These do put a bit of a drag on a model because of the blend array that makes the curtain.
Okay, now I'm just having fun...
Tuesday, October 14, 2014
Revit 2015 R2 - Background Color
Continuing in the theme of filling long standing wishes, it is now possible to choose your own background color instead just using Invert Background to use a black background. Years ago I did attempt to live with a black background but found that I preferred the white background after a short transition. I find trying to use a black background quite disorienting now.
Regardless lots of users have a preference for something other than white. In particular, for some people, staring at a white screen all day bothers their eyes. Adjusting their monitor's brightness and contrast only goes so far to mitigate their discomfort. Now they/we can choose nearly any color we'd like to use instead of white, via the Graphics page of the Options dialog.
It is a bit quirky depending on what is visible in the view. You'll have to experiment some to find both a color you really like and can live with how information is presented in different views with it in play. Here's what I call Word Perfect background with some rooms using a color fill (well I remember a blue background in Word Perfect).
And this is casual attempt to mimic "butter" tracing paper background.
I'm probably going to stick with a white background but I'm sure there are many users who will enjoying having a little more control over what they stare at for 8+ hours a day.
Regardless lots of users have a preference for something other than white. In particular, for some people, staring at a white screen all day bothers their eyes. Adjusting their monitor's brightness and contrast only goes so far to mitigate their discomfort. Now they/we can choose nearly any color we'd like to use instead of white, via the Graphics page of the Options dialog.
It is a bit quirky depending on what is visible in the view. You'll have to experiment some to find both a color you really like and can live with how information is presented in different views with it in play. Here's what I call Word Perfect background with some rooms using a color fill (well I remember a blue background in Word Perfect).
And this is casual attempt to mimic "butter" tracing paper background.
I'm probably going to stick with a white background but I'm sure there are many users who will enjoying having a little more control over what they stare at for 8+ hours a day.
Monday, October 13, 2014
Revit 2015 R2 - Default Setting for Import Positioning
This is a welcome change, one many users have been asking for a long time.
The default positioning setting is now Auto - Origin to Origin, pause for the sound of applause (and comments like "finally") in offices around the globe...
If you change the default setting, the option you select for Positioning becomes the default instead for your current Revit session. Revit will also remember a different setting for Revit models and CAD files. For example, this will make it easier to use Auto-Origin to Origin for Revit models and Auto - Center to Center for CAD files.
Glad to see this subtle but heavily wished for change.
The default positioning setting is now Auto - Origin to Origin, pause for the sound of applause (and comments like "finally") in offices around the globe...
If you change the default setting, the option you select for Positioning becomes the default instead for your current Revit session. Revit will also remember a different setting for Revit models and CAD files. For example, this will make it easier to use Auto-Origin to Origin for Revit models and Auto - Center to Center for CAD files.
Glad to see this subtle but heavily wished for change.
Subscribe to:
Posts (Atom)