December 19, 2018

Revit 2018: Disabling Addins to Resolve Cloud Render Issue

If you ever have an issue with Revit being unable to upload a model for a cloud rendering, you will likely end up on this Autodesk Knowledge Network article, and may eventually get to the suggestion to disable the addins to see if there is a conflict with one of them, which links through to a second Autodesk Knowledge Network article.

The second article helpfully lists a number of addins that should be left in place if you are using the Collaboration for Revit service. What it does not list is the addin that generates the Render in Cloud tool on the View ribbon tab, on the Presentation panel. It is rather hard to test whether removing the addins allows a cloud render to go through if the tool to initiate a cloud render is gone.

I was able to work out that the RaaSForRevit folder should not be removed from the W:\ProgramFiles\Autodesk\Revit 2018\AddIns folder if you want to have the Render in Cloud tool.

December 18, 2018

No More 32-bit AutoCAD

See this Autodesk Knowledge Network Article for details on the discontinuation of a 32-bit version of AutoCAD, starting with the next release.

December 09, 2018

Dynamo: Export Views and Sheets from Revit - Part 6

First post in this series [Part 1]
Previous post in this series [Part 5]

We now have all of the user input needed to create the export, and we have taken the user-specified ViewSheetSet and generated a list of the View and Sheet objects included in the ViewSheetSet and a corresponding list of names to be used for the exported Views and Sheets. All that remains is to do the actual export. The Python Script 2 node in the Export to DWG group does the export.
There are six inputs to this node:
  • IN[0]: This input takes the folder the user specified as the destination for the exported drawing files (see Part 1).
  • IN[1]: The recombined list of Views and Sheets is sent to this input (see Parts 2 and 3).
  • IN[2]: This input receives the list of generated file names for the exported Views and Sheets (see Part 4).
  • IN[3]: The name of the DWG Export Setup to be used is sent to this input (see Part 5).
  • IN[4]: The user choice of whether to merge the Views on a Sheet into one drawing file (true) or not (false) is received by this input (see Part 5).
  • IN[5]: The user choice of whether to actually export the Views/Sheets (true) or to just run the graph without exporting (false) is sent to this input (see Part 5).

The image below shows the Python code that processes this input. The majority of this code was written by Konrad K Sobon, and posted to this thread in the DynamoBIM forum. It also includes the ability to have exported Sheets to have the Views on the Sheet merged into the View drawing file, rather than exported as separate drawing files that are then externally referenced by the Sheet drawing file. This addition was posted to the DynamoBIM forum by 4bimfercesp in this thread. The ability to specify the name of an existing DWG Export Setup comes from code posted by Andrea_Ghensi in the same thread in which Mr. Sobon posted his code. As I read through the postings and assembled the code shown below, I added some additional comments to solidify my understanding of what the code is doing.

If there are no errors generated in the course of performing the requested export, the Python Script 2 node outputs a string, Success!. This is displayed in the Watch node to the right of the Python Script 2 node. If there is at least one error, then the error report is the output, and is displayed in Watch node to aid in sorting out what went wrong. If the user input in the Group 5 area is false, indicating that the export is not to be done, then the output is a reminder to set the Ready to Export Views and/or Sheets - Boolean node to true to perform an export.

If you need to export the same Views and/or Sheets multiple times as a project makes its way through the design and documentation process, this graph can be a time saver while improving consistency. Customize a copy of it for each project, and use Dynamo Player to be a few clicks away from a new set of export files at any given moment.

December 06, 2018

ACA: Multi-View Blocks and DRAWORDER

A reminder for those who already know about this, and a heads up for those who do not. Multi-View Blocks do not respect any dipslay order modifications made to the nested objects in the AutoCAD block assigned as a view block to the Multi-View Block. So if you use the DRAWORDER command to get things to look the way you want in the AutoCAD block, those changes will not show up when that block is assigned to a Multi-View Block Definition and an instance of that definition is placed in your drawing file.

For example, suppose you have a custom Space Tag that includes a an overall rectangle with a dividing line that separates the Space name from the Space number, as illustrated in the image below.
Further suppose that you often place these tags in areas where there is linework "below" the tag, and you would rather not have that show inside the outer rectangle, so that the name and number can be more easily read. You might decide to add a Wipeout to the view block to accomplish this task. So you place an instance of the view block, edit it in place (or in the Block Editor) and use the WIPEOUT command to add a Wipeout to the Block Definition, using the outer rectangle, which just happens to be a closed Polyline, to do so (without erasing the Polyline). So far, so good. Before saving the changes to the Block Definition, you select the Wipeout, right click and choose Basic Modify Tools > Display Order > Send to Back from the context menu, to execute the DRAWORDER command and send the Wipeout to the back of the draw order. After saving the changes back to the Block Definition (and closing the Block Editor, if you used it), you see that the instance of the view block is working as desired - the Wipeout is hiding linework under the view block instance, while showing all of the other linework in the block definition.

But when you examine your Space Tags, you find that while the tags now hide linework "below" them, the line between the room name and room number is no longer visible. If you select a Space Tag, that line is highlighted, so you know it was not accidentally erased or otherwise removed from the Block Definition, but it does not show. (Attributes seem to be treated differently from other linework, and do still appear on top.) What gives? Multi-View Block instances do not respect changes in draw order, and display the items within the view block definition in the order in which they were added to the Block Definition.

What to do? Do not use the DRAWORDER command to put things in the desired order - draw them in that order. You do not have to recreate the Block Definition for the view block from scratch. You can proceed as mentioned earlier, but after creating the Wipeout, instead of using DRAWORDER to push the Wipeout to the back, select all of the objects other than the Wipeout and use the COPY command, with a Displacement of 0,0, to create a new copy of each item in the same place. Then use the ERASE command, with the Previous command line option, to erase the objects you just copied. Now the Wipeout is the first item drawn in the Block Definition, and you can save the changes and have the desired draw order respected in both the view block and the Multi-View Block.

In the image below, the same Spaces and Tags from the first image are shown. The Space Tags, while appearing identical, are actually instances of two different Multi-View Block Definitions, each with its own view block. The view blocks just happened to have equivalent contents. The Space Tag in Space 101 had a Wipeout added to the view block, pushed to the back using the DRAWORDER command. The Space Tag in Space 102 had a Wipeout added to the view block, and then the other items in the Block Definition were copied in place, and the originals erased. The line between the room name and number is hidden by the Wipeout in 101, but is seen in 102.

November 29, 2018

Dynamo: Export Views and Sheets from Revit - Part 5

First post in this Series [Part 1]
Previous post in this series [Part 4]

So far in this series, we have seen nodes that allow the user to specify a folder to receive exported drawing files, a node for the user to enter the name of a ViewSheetSet which lists the Views/Sheets to be exported, the nodes that generate a list of Views/Sheets that are in that Set, nodes to separate that list into separate lists of just Views and just Sheets, and the nodes that generate file names to be used for the exported Views and Sheets. This post will examine the balance of the user input nodes.


Each of these three input nodes includes a second "Passthrough Value" node, which are renamed Code Blocks and, as the node title suggests, simply pass through the value from the input node. They are not at all necessary, and are only there to make the group each is in wider, so that the rather long group titles will only take up two lines of text.

The Name of DWG Export Setup - String node (Group 3) is a String node into which the user enters the name of the DWG Export Setup to be used for the exports. This can be left blank if the user wants to use Revit Default settings.

The Merge Views on Sheet into one DWG File? - Boolean node (Group 4) is a Boolean node that allows the user to choose whether Views on a Sheet should be exported as one DWG file (True) or if the Views should be exported as separate DWG files that are externally referenced into the exported Sheet (False).

The Ready to Export Views and/or Sheets - Boolean node (Group 5) is a Boolean node. Setting this to False allows the user to enter data in the other nodes and Run the graph to view the results in the Watch nodes, verifying that all is correct before actually exporting any files. When all is ready to go, set this to True and run the graph one more time to export the Views/Sheets.

All three of these input nodes, like the other two, are set to be input nodes (see first post), so that they are available if this graph is run via Dynamo Player. The next and final post will examine the Python Script 2 node and the code inside it, that does the actual exporting.

Next post in this series [Part 6]

October 28, 2018

ACA: Custom Profile for Railing Plan Display Representations

As noted in a previous post about Custom Blocks for Railings, those blocks can only be attached to the Model Display Representation. While the Plan, Plan High Detail, Plan Low Detail and Plan Screened Display Representations do not allow for Custom Blocks, they do allow for Custom Profiles, which may work for showing a base plate at each post, depending upon how fussy you are about the graphics. One might first ask the question, "Do I really need to see base plates in a plan view of a Railing?" At typical plan scales (1:100, 1/8" = 1'-0", 1:50, 1/4" = 1'-0"), one could make a convincing argument that the added graphic will, at best, be a slightly wider blob, with the lineweights causing the plotted linework to merge with the railing and post graphics. For the purposes of this example, lets say that for the High Detail Display Configuration/Plan High Detail Display Representation Set (Top view direction)/Plan High Detail Display Representation for Railings, we do want to show the base plates. This can be done by adding a Custom Profile to the post components.

Before we can add a Custom Profile, we have to define the Profile. To do so, I drew a closed Polyline to show the 5.5" x 2" top view rectangle of the base plate that was created in the previous article, as shown in the image below, taken from a SW Isometric view. The Color 140 diagonal line is a Line on layer G-Anno-Nplt and will not be part of the profile, but is there to make it easy to specify the insertion point of the Profile, by snapping to the midpoint of the Line.

Create a Profile from this Polyline by doing the following:
  • Select the Polyline, and right click. Choose Convert To > Profile Definition from the context menu.
  • At the Insertion point or [Add ring Centroid] command line prompt, select the midpoint of the diagonal Line, using the Midpoint object snap.
  • In the New Profile Definition dialog, enter a name for the Profile, in the New Name edit box. I chose to call the Profile in this example RailingPostBasePlate. Select the OK button.

The Profile for the base plate is now available. If you want, you can open the Style Manager and take a look at it, under Multi-Purpose Objects > Profiles. If you do take a look, close the Style Manager without making any changes.

The newly created Profile can now be added as a Custom Profile to the Posts in the Railing.
  • Edit the Railing Style.
  • On the Display Properties tab, select the Plan High Detail Display Representation. Depending upon what view direction and Display Configuration are current, this may or may not be the Display Representation in bold type.
  • Left click on the toggle in the Style Override column on the Plan High Detail Display Representation line to create a style-level override and open the Display Properties dialog for the overridden Plan High Detail Display Representation.
  • In the Display Properties dialog, select the Other tab.
  • Select the Add button. This will open the Custom Profile dialog.
  • In the Custom Block dialog, select the Select Profile button, and then choose the Profile Definition for the base plate in the Select a Profile dialog.
  • Select OK to ratify the choice of Profile and return to the Custom Profile dialog.
  • Since we want this added to the Posts, in the Component area at the upper right, clear the check mark from the Baluster toggle and add one to both the Fixed Post and Dynamic Post toggles. We only want to add this block to the existing posts, not replace the posts, so leave the Replace toggle unchecked.
  • Verify that none of the toggles in the Scale To Fit or Mirror In areas are checked.
  • Verify that the Insertion Point is set to Center for X and Y. This matches the insertion point of the RailingPostBasePlate Profile that was created.
  • Verify that the Insertion Offset values are all set to 0.
  • Choose an appropriate radio button in the Attach To area. Since I wanted all posts to have the base plate, I chose All in this example.
  • Select OK to ratify the Custom Profile settings, dismiss the Custom Profile dialog and return to the Display Settings dialog.
  • Select the Layer/Color/Linetype tab.
  • Notice that, unlike with Custom Blocks, there is not a new Display Component listed for the Custom Profile. Based on some experimentation with the Color property, it does not appear that the Custom Profile is associated with any of the Display Components shown, either, but behaves as if ByBlock were selected for each property.
  • Select the OK button twice, to accept all the edits made, dismiss the Display Properties and Railing Styles dialogs (or, if you edited the Railing Style with the Style Manager, to dismiss the Display Properties dialog and the Style Manager) and return to the drawing.
In a Top view with a Display Configuration with the Plan High Detail Display Representation for Railings active, the added Custom Profile will be seen at the posts. So far as I know, it is not possible to have any rails that cross over the Custom Profiles hide the Custom Profile linework that passes "under" the rail. Most likely because the rail is just two lines in this Display Representation, not a solid object, and ACA has no way of knowing that the Custom Profile represents a base plate down at the bottom of the post.

Given the lack of display control and the resulting graphics, I doubt that I would use a Custom Profile to represent a railing base plate; certainly not one of this size relative to the size of the railing. I would probably only show this in a detail, with independent linework, rather than as part of the model. One other interesting effect to keep in mind should you decide to go this route, if you add a Custom Profile to all of the posts in a Railing that is anchored to a Stair object, the Custom Profile will display for each post, even those that are not drawn in the view because they are above the cut plane of the Stair. Checking the Replace toggle in the properties of the Custom Profile, so that the Profile replaces the graphics of the posts does not affect the display behavior here. The posts will not be drawn, but all of the base plates will show at the Stair, and they will display with ByBlock display properties, not the display properties assigned to any of the post components.

October 24, 2018

ACA: Custom Block for Railing Model Display Representation

The Model Display Representation of Railings in AutoCAD® Architecture allow for the addition of custom blocks to create additional display components for the Railing. For example, you can add base plates to the Railing Posts. For this example, I started with the out-of-the-box Guardrail - Pipe Railing Style and renamed it to Guardrail - Pipe with Base Plate.

The first step is to create an AutoCAD Block Definition to represent the base plate. I decided that the base plate should be 5.5" long, 2" wide and 1/4" high, and I wanted to be able to use the same Material Definition that is used for the Railing, so I chose to use a Mass Element for the base plate, and created a Mass Element Style, called Stainless Steel, that had the same Material Definition assigned. In the example file, which can be found in this AutoCAD Architecture forum post, I used the out-of-the-box Metals.Metal Handrails and Railings.Stainless Steel.Satin Material Definition. Using the Stainless Steel Mass Element Style, I created a "Box" shaped Mass Element of the desired dimensions.

I then made a Block Definition with the Mass Element as the only included object, with the insertion point at the centroid of the bottom face of the Mass Element.


With the Block Definition created, the next step is to add it to the Railing. This is done in the Railing's Display Properties, in the Model Display Representation. Because I want this block to be added to all instances of this Railing Style, but do not want it to be added to all Railings, this was done as a Style-level Display Override.
  • Edit the Railing Style.
  • On the Display Properties tab, select the Model Display Representation. Depending upon what view direction and Display Configuration are current, this may or may not be the Display Representation in bold type.
  • Left click on the toggle in the Style Override column on the Model Display Representation line to create a style-level override and open the Display Properties dialog for the overridden Model Display Representation.
  • In the Display Properties dialog, select the Other tab.
  • Select the Add button. This will open the Custom Block dialog.
  • In the Custom Block dialog, select the Select Block button, and then choose the Block Definition that contains the base plate in the Select a Block dialog.
  • Select OK to ratify the choice of block and return to the Custom Block dialog.
  • Since we want this added to the Posts, in the Component area at the upper right, clear the check mark from the Baluster toggle and add one to both the Fixed Post and Dynamic Post toggles. We only want to add this block to the existing posts, not replace the posts, so leave the Replace toggle unchecked.
  • Verify that none of the toggles in the Scale To Fit, Mirror In or Rotate areas are checked.
  • Verify that the Insertion Point is set to Center for X and Y and Bottom for Z. This matches the insertion point of the RailingPostBasePlate block that was created.
  • Verify that the Insertion Offset values are all set to 0.
  • Choose an appropriate radio button in the Attach To area. Since I wanted all posts to have the base plate, I chose All in this example.
  • Select OK to ratify the Custom Block settings, dismiss the Custom Block dialog and return to the Display Settings dialog.
  • Select the Layer/Color/Linetype tab.
  • Notice that there is a new Display Component listed, with the same name as the name of the Block Definition selected for the Custom Block. You can make any desired settings here, but since a Mass Element is the only element in the Custom Block, it will follow its own display settings for the Model Display Representation. The out-of-the-box drawing default settings display Mass Elements "By Material" for the Model Display Representation, just like all of the other Railing components. Since the same Material Defintion is assigned to the Railing components and the Mass Element in the Custom Block, they should all display alike. (If you really wanted to control the display properties of the Custom Block on the Layer/Color/Linetype tab of the Railing Display Properties, you could set a Style-level display override on the Mass Element Style for the Model Display Representation, clear the ByMaterial toggle and set all of the properties in the Mass Element Style Override to ByBlock. But that is not the goal in this example, and beyond the scope of this article.)
  • Select the OK button twice, to accept all the edits made, dismiss the Display Properties and Railing Styles dialogs (or, if you edited the Railing Style with the Style Manager, to dismiss the Display Properties dialog and the Style Manager) and return to the drawing.
If you do not already have an instance of the Railing Style in your drawing, add one, and then change to one of the isometric view directions, if you are not in one already. You should see the Custom Block at the bottom of each post.
The baseplate will show whenever the Model Display Representation for Railings is active, which is just about any Display Configuration/View Direction combination where Railings are turned on, except for the Top view direction, where one of the "plan" Display Representations will be used. The Plan Display Representations do not allow for attaching Custom Blocks, but they do allow for adding Custom Profile Displays. An article on how to do that can be found here.

October 15, 2018

Dynamo: Export Views and Sheets from Revit - Part 4

First post in this series [Part 1]
Previous post in this series [Part 3]

This post describes the nodes that generate the file names for the exported drawing files. As you may recall from the previous posts in this series, a list of Views and Sheets was generated from a user-created ViewSheetSet in Revit® by a Python Script node. That list was then separated into two lists, one for Views and one for Sheets, to allow for separate naming conventions for the exported drawing files for each. (Specifically, so that the sheet number can be included in the file name for Sheets.) The nodes that do this are contained in three groups: Generate Names for Exported Views, Generate Names for Exported Sheets and Combine Names....
All three groups make use of out-of-the-box nodes. The first two groups are nearly identical, and can be described simultaneously. The first node in each of those groups is a Code Block node, renamed to Exported DWG File Name Format for Views for the exported Views and Exported DWG File Name Format for Sheets for the exported Sheets. Each of these nodes has one input, view which takes the respective list from the List.FilterByBoolMask node covered in Part 3. A combination of parameter values associated with each View/Sheet and text is used to create the file name for each View/Sheet:
  • For Views: dwgname = view.Name + "_Export" + ".dwg";
  • For Sheets: dwgname = view.SheetNumber + "_" + view.Name + "_Export" + ".dwg";
The drawing name for Views concatenates the view.Name parameter value with "_Export" and the ".dwg" file extension. The drawing name for Sheets is similar, but adds the view.SheetNumber parameter values at the beginning, separating the sheet number from the sheet name with an underscore ("_") character. This is what I set up as a default for use in my office; you can customize this to meet your needs by adding, removing or rearranging the parts.

The lists of Sheet and View names are then run through two String.Replace nodes. The first replaces any asterisks ("*") with underscores ("_") and the second replaces any forward slashes ("/") with hyphens ("-"), as neither of these characters are permitted in a drawing file name, even though they are allowed in a View or Sheet name in Revit. Each resulting list of file names is then passed through a Watch node, so that the contents can be inspected after the graph is run. These two lists are then sent to the Combine Name... group, where a List.Create node and a Flatten node combine them into a single list. An optional Watch node is included here, as well.

So now we have a combined list of View and Sheet objects (from Part 3) and a combined list of file names for the corresponding exported files. The next post will look at the remaining user input nodes.

Next post in this series [Part 5]

September 25, 2018

Revit: 2018.3, Windows 10 and No Material Browser

I discovered today that I was not able to open the Revit® Material Browser (on the Manage ribbon tab, on the Settings panel, selecting the Materials tool). As luck would have it, I am quite a bit behind in reading the Autodesk Revit Architecture Forum, and I just happened to have read a thread about this issue earlier today. In the Materials Dialog Box Doesn't work thread, a post by richard.horner, building off the previous post by stewart.jex, provided the solution that worked for me. I know I will not be able to find that thread when I need it in the future, and since the solution is not at all intuitive (I still cannot figure out why it works), I decided to document it here.

  1. In the Revit session in which you discover that the Material Browser will not open, go to the Application Menu (File "tab"), and choose Options.
  2. In the Options dialog, choose Hardware on the left side.
  3. On the right side, in the Hardware setup area, clear the checkmark from the Use hardware acceleration (Direct3D®) toggle.
  4. Select OK to ratify the change and close the Options dialog, and then close Revit. (Changes to hardware acceleration do not take effect immediately.)
  5. Restart Revit, and open a project file.
  6. On the Manage ribbon tab, on the Settings panel, select the Materials tool. The dialog opens! (Great, but who wants to run Revit without hardware acceleration, right? The next part is the bit that I cannot figure out.)
  7. Close the Material Browser.
  8. Open the Options dialog again, select Hardware and select the Use hardware acceleration (Direct3D®) toggle to re-enable it. There should be a checkmark in the toggle.
  9. Select OK to ratify the change and close the Options dialog, and then close Revit.
  10. Restart Revit, open a project file and then try to open the Material Browser again. It works!

While the analytical part of my brain wants to know why the exact same settings that previously failed now work, the "hey, you found a solution, now lets get on with what you were trying to do originally" part of my brain is declaring victory and moving on. And I will be carefully looking both ways crossing streets on my way home this evening, as I have clearly used my luck for the day.

September 12, 2018

Dynamo: Sorting a List of Lists by a Value in the Sub-List in Python

I had a list that was composed of sub-lists, each sublist contained a Sheet Object and the values of three parameters associated with that Sheet, including the Sheet Number. I wanted to be able to sort the sub-lists in ascending order of the Sheet Number value in each sublist. I found the following Python code does the job:
sortedLists = sorted(listOfLists, key=lambda x: x[index])
where index is the index of the item in the sub-list on which you want to do the sorting.

For example, given a list with four sublists, similar to that in the image below,
where the index of the Sheet Number in each list is 1, the code below
will sort the sub-lists by the item in index 1 of each sub-list, with a result of

This page on the stackoverflow website helped me work this out. Two additional notes:
  • If you want to replace the original list with the sorted list, you can use this syntax:

    listOfLists.sort(key=lambda x: x[index]).

  • If you want to sort in descending order, add reverse=true as a parameter:

    sortedLists = sorted(listOfLists, key=lambda x: x[index], reverse = true)

    or

    listOfLists.sort(key=lambda x: x[index], reverse = true).

September 01, 2018

Dynamo: Export Views and Sheets from Revit - Part 3

First post in this series [Part 1]
Previous post in this series [Part 2]

This post describes the nodes used to separate the Views from the Sheets that were obtained from the ViewSheetSet that the user specified as the source of Views and/or Sheets to be exported. This Dyanmo graph generates file names for the exported Views/Sheets. In order to be able to use the Sheet Number in the file name of exported Sheets, Views and Sheets need to be processed separately when generating the file names as Views do not have a Sheet Number parameter, so that cannot be part of the name generation code for Views. Separating the Views from the Sheets in two separate lists and processing each list separately when generating the file name seemed like the easiest way to handle that.

As noted in Part 2, the Python Script 1 node generates a list of View and Sheet objects, based on those included in the ViewSheetSet specified by the user. In order to separate that list into two separate lists, the List.FilterByBoolMask node is used. That requires a Boolean Mask, which is a list of true and false values. Items in the original list whose index corresponds to a true in the Mask list end up in the "in" output list. Those that correspond to false become part of the "out" list. The nodes in the lower left corner of the image above generate the Boolean Mask:
  • The list of Views/Sheets in the Set are fed into the "element" input of a Element.GetParameterValueByName node.
  • A String node provides the input to the "parameterName" input, with a value of "Category".
  • This creates a list of category objects, representing the category of the items in the View/Sheet list.
  • That list of categories is converted to a list of strings, representing the name of each category by the Element.Name node.
  • This list of strings is then passed to the Equal x to y? operator node (==), as the "x" input.
  • The "y" input is provided by a String node, with the value "Views".
  • The output will be a list of true/false values, based on whether the category name is "Views". Any Views on the original list will have a true value, and any Sheets will have a false value on that list.
Feeding the original list of Views/Sheets into the "list" input of the List.FilterByBoolMask node and the Bool Mask we just created above into the "mask" node will send the Views to the "in" output and the Sheets to the "out" output. These are sent to the respective file name generation nodes, to be covered in the next post in this series.

But before closing, there are two additional nodes in the blue node group in the image above. Eventually, we need to export the Views and/or Sheets, so we need to recombine the separated lists. I chose to put the Views first and the Sheets second, and used a List.Create node to combine the two. The List Create node will generate a list with two sublists, one of the Views and one of the Sheets. I just want a single combined list, which the Flatten node creates.

Note also that it is perfectly acceptable for the ViewSheetSet to have only Views or only Sheets. The nodes above will still generate two separate lists; one will just be empty.

Next post in this series [Part 4]

August 13, 2018

Revit: Design Options in Linked Revit Files Not Respected as Room Boundaries

I was trying to assist on a project in the office today (using Revit® 2018.3), when I ran into this issue, documented by Dave Baldacchino nearly six years ago. I set up a simplified set of files for experimental purposes; the images below demonstrate the problem remains an issue at least through 2018.3.

I created a "link" model, that has one Design Option Set (Exterior Walls) which in turn has two Design Options, Option 1 (primary) and Option 2. Each Design Option has one Wall object, running in the Project North-South direction (up and down on the screen). These are identical, with the exception that the Wall in Option 2 is offset 10 feet in the direction of Project West (left on the screen).

The link model is linked into a "host" model (origin to origin; both files were started with the same template file). In a floor plan view, four additional Walls were drawn, and two Rooms with Room Tags added. In the image below, the link model is showing Option 1 (primary). The link model is selected, and its type properties displayed to show that the link model is set to be room bounding. Interior Fill is turned on for the Rooms, to illustrate their extents.

No surprises there. But change the Visibility Graphics Overrides for the linked model to display Option 2, and the Wall moves 10'-0" to the left, as expected, but the Rooms stubbornly maintain their extents at the face of the Option 1 (primary) Wall location.

The workaround, to make the linked file not be room bounding, and to draw Room Separation lines in the host file, is not going to make anyone on that project team very happy.

August 10, 2018

Dynamo: Export Views and Sheets from Revit - Part 2

First post in this series [Part 1]

This post will cover the part of the graph that gets the list of Views and/or Sheets from a user-selected ViewSheetSet that are to be exported.
As noted in Part 1, the user has to create a View/Sheet Set in Revit® and add all of Views and/or Sheets to be exported to that set. The user enters the name of that set into a string node, labeled ViewSheetSet Name - String in the green-colored group labeled 2. Enter Name of Set to Export. Just above that, the Element Types node is set to the ViewSheetSet type, which is then fed to the All Elements of Type node to get a list of all of the ViewSheetSet objects in the active project. This list of ViewSheetSet objects is passed to the Element.Name node, which generates a list of the names (as strings) of those ViewSheetSets. This list is passed to the IndexOf node, along with the name that the user entered, to determine the index of that name on the list. Finally, the list of ViewSheetSets and the index of the desired ViewSheetSet are passed to the List.GetItemAtIndex node, to get that ViewSheetSet object.

During my initial testing, I passed the ViewSheetSet object to an Element.Parameters node, to see what information could be obtained from the object. The list of Views/Sheets included in that ViewSheetSet was not found there, so this node need not be included in the final graph. It turns out that there is not a node that ships with Dynamo that will generate a list of Views/Sheets that are included in a ViewSheet Set, and I was not able to find one in any of the third-party packages I have installed. I was able to find this thread in the DynamoBim.com Forum, in which Kulkul posted the Python code needed to extract a list of the Sheets/Views. My adaption of that, shown in the image below, is the code behind the Python Script 1 node, which takes the desired ViewSheetSet object as input and generates a list of the included Views and Sheets as output.

That list of Views and Sheets is then sent to several locations. During development, I added an Element.Name node and two Watch nodes to view the list. These do not need to be part of the final graph, but I left them in as a way to visually check that the correct ViewSheetSet was obtained.

In the next installment, I will cover the nodes that separate the list of Views/Sheets into separate lists of Views and Sheets. I wanted to do this so that I could include the Sheet Number value as part of the name of exported Sheets. Since Views do not have a Sheet Number property, they needed have the name of the exported drawing generated separately.

Next post in this series [Part 3]

July 27, 2018

Revit: Sheet Ribbon Tool Inactive

This issue came up today, and I wanted to document the solution for future reference. A user was working on a model, in Revit 2018, and was trying to create a new Sheet. On the View ribbon tab, on the Sheet Composition panel, the Sheet tool was inactive.

She was working on a project that had Design Options, and one of the Design Options was set active. The solution was to use the Active Design Option selector on the Status Bar and set it to Main Model. You can only create new Sheets in the Main Model.

July 18, 2018

Revit: Multi-Line Viewport Titles on Sheets

I was asked about this today, and decided to record the solution in a blog post, for future reference. Viewport Titles in Revit® will wrap onto a second line when the length exceeds what will fit, based on the length of the label in the Title Family, but often the user wants control over where the wrapping occurs. If your office protocols allow for using the Title on Sheet property of a Viewport for the title that is shown on the Sheet (rather than using the View Name), then you can set a line break at the cursor location in the Title on Sheet property edit box in the Project Browser by pressing CTRL+ENTER.
And, no, there is no significance to the contents of the Drafting View that I used as my test case, shown in the image above. They are just some semi-random Detail Lines drawn so that there would be something to see when the Drafting View was placed on a Sheet.

July 10, 2018

Dynamo: Export Views and Sheets from Revit - Part 1

I had a request the other day to streamline the process of updating CAD Exports for an Autodesk Revit® project. Unfortunately, some team members are not working in Revit, so certain Views have to be exported to CAD on a regular basis for use as backgrounds for the non-Revit-using team members. After a bit of trial (and a little tribulation) along with an enormous amount of help from the generous souls who have posted sample code to the Community Forums at dynamobim.org, I came up with the following Dynamo graph. All of the nodes used are "out-of-the-box" nodes available in the 1.3.2 version of Dynamo, but there are two Python Script nodes, the code for which is based on example code posted in the Community Forums. (As always, click on a image to see a full-size version of the image.)

The end user has to do three things prior to using the graph:
  • Create a View/Sheet Set into which all of the Views and/or Sheets to be exported are placed.
  • Get the name of the DWG Export Setup to be used for the export. (Create a new one if required by the project.)
  • Identify the folder (with full path) where the exports are to be sent.
With that information in hand, the user can make a project-specific copy of the Dynamo file, enter those three items in the appropriate nodes, save the file, and then run it whenever updated exports are needed. Dynamo will overwrite any files of the same name in the target folder, so previous versions need to be archived elsewhere if a record of all exports is required. In the next few posts, I will go through the various sections of the graph, and, to the best of my ability, explain how each works, including the two Python Script nodes that do the heavy lifting. Before doing so, I would like to thank the following Community Forum contributors whose helpful responses to others' questions also helped me to complete this project.
  • Konrad K Sobon, for the code in the Python Script 2 node that does the exporting, as well as for the advice given to Andrea_Ghensi in the same thread regarding code to have a specific DWG Export Setup used for the export. See the full thread here.
  • Andrea_Ghensi, for the code in the Python Script 2 node that allows the user to specify an existing DWG Export Setup for the export (as amended by Konran K Sobon). See the same thread as the previous link.
  • 4bimfercesp, for the line in the code in the Python Script 2 node that allows the user to specify whether Views on a Sheet should be merged into the exported sheet or exported as a separate file that is externally referenced into the exported Sheet file. See the full thread here.
  • Kukul, for the code in the Python Script 1 node that extracts a list of the Views/Sheets in a View/Sheet Set. See the full thread here.
The nodes at the left side of the graph that are in green-colored groups are the nodes that require user input. I will conclude this first post with one of the simpler parts of the graph, the Folder for Exported DWGs - Directory Path node.
This is an instance of the out-of-the-box Directory Path node, with a modified node title. The Browse button allows the user to navigate to the folder where the exported drawings are to be placed. The output of this node is fed to the IN[0] input of the Python Script 2 node. One thing to note about this node, and the other user input nodes, is that if you right click on the node, you will see that the Is Input item on the context menu is checked. That means that this node will be available for user input in Dyanmo Player.

I am not certain how many clicks using this graph will save over manually doing the same export (probably a few on subsequent exports if Dynamo Player is used, without making any changes to the inputs), but it certainly will help make the process more consistent.

Next post in this series [Part 2]

May 21, 2018

Autodesk Product Update Site Maintenance

If you were planning to do some software updates this coming weekend (Memorial Day weekend in the United States), get your download early, as the product update section of the Autodesk Account site will be down from 8:00 pm on Friday, May 25, 2018 through 2:59 am on Monday, May 28, 2018. (Those times are US Eastern Daylight Savings time, to the best of my knowledge.) Check out the banner notification at the top of the Autodesk Account Management page for the times in your zone.

April 23, 2018

Return of the Educational Watermark in AutoCAD 2019 and 2019 Vertical Products

The educational watermark has returned in the 2019 versions of AutoCAD® and AutoCAD-based vertical products, like AutoCAD® Architecture and AutoCAD®MEP. More details on the 2019 implementation of the educational watermark can be found in this Autodesk Knowledge Network article.

March 22, 2018

Say Goodbye...

...to AutoCAD® Architecture and AutoCAD® MEP, and say hello to Only One. AutoCAD. with toolsets in the 2019 release. The familiar tools in AutoCAD Architecture and AutoCAD MEP will still be available, as toolsets that can be installed for use in AutoCAD. Most of the other vertical products built on AutoCAD® will also become toolsets.

Current subscribers to a vertical product have the option to stay with the vertical product or migrate to the new offering. Current permanent licenses with active maintenance will only have access to the vertical product, when it is released, but will have the option to move to subscription (and the Only One. AutoCAD. offering) when the maintenance contract is up for renewal. More details on this and other related issues can be found in the Only One AutoCAD FAQ.

March 14, 2018

Civil 3D 2018 to ACA 2013

We have started to get drawings from Civil consultants in the 2018 file format. Thanks to our recent move to the AEC Collection, we now have access to AutoCAD® Civil 3D®. I have no idea how to use that program, beyond the AutoCAD basics, but I installed the 2018 version of it in the hope that I would be able to export the received drawing to "vanilla" AutoCAD®. Similar to AutoCAD® Architecture and AutoCAD® MEP, you can go to the Application Menu > Export > Export Civil 3D Drawing to export a drawing. There is a dialog, where you can choose between AutoCAD DWG and Microstation® DGN, and, for DWG export, the Export Settings allow you to select a file format, such as 2013.

I did all of that, and Civil 3D did its thing, and drawings were generated. (I got more than one because I left the Include sheets toggle checked, so a drawing for each layout was also generated.) I fired up AutoCAD Architecture 2016 and opened the exported "Model" file, only to be greeted by this dialog:
What?! I just exported this file to a previous file format - there should not be ANY AEC objects, let alone future ones. I closed the dialog and tried run the WALLADD command. No dice - "Command not allowed because drawing contains objects from a newer version of this application." appeared at the command line. So this drawing, supposedly exported to the previous file format, can be opened, but is otherwise mostly useless. You can externally reference the file and use AEC commands in the host file, saving it from being totally useless.

Still, I expected to have a "clean" 2013-format file that only has non-AEC AutoCAD objects. I tried a Window selection in Model Space to get all the visible objects and then tried to copy them to the clipboard, hoping that if I pasted them in a new file, the future AEC Objects would not come along for the ride. That did not work, as the copy to clipboard failed.
Then I tried to select the Model Space objects and use the WBLOCK command, again hoping that the future AEC Objects would be left behind. That also failed.
Finally, I opened the file in AutoCAD Architecture 2018 and tried to use the AECEXPORTTOAUTOCAD2013 command, in the somewhat desperate hope that might work. I got the following dialog indicating that an error had occurred during the save.
And then this dialog showed up, to rub salt into the wound. I tried "saving" as AutoCAD-only objects!
This was followed by a second showing of the warning dialog recommending the use of the RECOVER command. Opening this file in AutoCAD Architecture 2016 resulted in the same Open Drawing - New Versions of Objects in Drawing dialog as shown in the first image above.

Finally, I tried starting a new drawing and using the INSERT command to insert the originally exported "Model" drawing file. I received the following dialog:
The small-print statement "Newer AEC objects will be disallowed from participating in this operation" gave me hope, as it was not flat-out refusing to do the insertion, and I did not want the newer objects in the file. That hope was confirmed, as it did insert what appeared to be all of the objects that were visible in the exported file, and I was able to add AEC objects to the file. Upon saving and reopening, there were no dialogs chastising me for having a file with future AEC Objects in it. Success! I still think that the original export should have been AEC-object-free, and object to having to go to the extra step of inserting the exported file into an empty file to get rid of the future objects, but at least I have a workaround for providing a "clean" file in the 2013 format that does not require proxy objects or object enablers.

February 19, 2018

Revit: "Mystery" Names on the Room Name Drop-Down List

Like other text parameters in Revit, as you add Rooms to your project and provide values to the Name parameter, a list of used values is generated and made available for selecting the Name of a newly added Room. This can speed the naming of Rooms, when you have multiple Rooms with the same Name, and also makes it easier to be consistent in how you name them.

So today, I was the only design technology helpdesk staffer, and a question came in regarding the fact that in the project on which this person was working, there was a long list of room names from which to choose, that were NOT Rooms in that project. The problem was there were so many of these "mystery" names that it was slowing down the process of finding the desired name on the list, and the person wanted to be able to delete the ones that did not apply. I opened the project file and set up Room Schedules for each phase in the project, hoping to find that there were unplaced Rooms in one or more of the Phases that were generating these names. This turned out to not be the case.

Perplexed, I created a new project from our template, and found that those same names were on the list there, as well. I searched the help and the internet, trying to figure out what the source of these names was, to no avail. Then it occurred to me that there could be a Color Scheme in the project that was defining these names. I opened the Edit Color Scheme dialog (on the ribbon: Architecture > Room & Area panel flyout > Color Schemes), set the Category to Rooms and found a number of Color Schemes in our template file. Most were based on the Department parameter, but one was based on the Name parameter, and it was the source of the "mystery" names on the Room Name list.

February 15, 2018

Revit: Linked AutoCAD File with MText and Columns

One of the users at my firm was trying to link an AutoCAD file into Revit 2016, to get some formatted text notes into his project. The formatting of the text changed from what shows in AutoCAD when linked into Revit. It turned out he was using the Columns feature of MText to get his notes to wrap into a second column, as the total "height" of the notes was greater than the height of the sheet. Revit ignored the columns formatting and displayed the text as one continuous column, with the width set to match the total width of both columns in AutoCAD.

The solution was to reformat the MText in AutoCAD, removing the columns formatting, setting the overall width to that of one column, and breaking the MText into two separate pieces, one for each of the former columns. Any future edits to the AutoCAD file will have to deal with the separation of the MText into two pieces, but the text does appear as desired when linked into Revit.

One more issue that we will not encounter as often as we start using Revit 2018 on new projects, given the somewhat improved ability to format text in 2018.

January 22, 2018

ExportToAutoCAD and Civil 3D Object Enabler

I have not tested this exhaustively, but I had an issue today where I was trying to export what appeared to be a "vanilla" AutoCAD 2018 format file back to the 2013 file format, using AutoCAD Architecture 2018. On my initial attempts, I got a message saying there was an error and that I should try to RECOVER the exported file. I did so, and no errors were reported, but I got the dreaded future objects warning, and I could not add a Wall in the file. I had previously installed the Civil 3D object enabler on AutoCAD Architecture 2018, and suspected that was the reason why there were still future objects in the exported file. I uninstalled the object enabler, and was able to export to the 2013 file format without any errors, warnings or issues.

I am not certain if having the object enabler installed was adding Civil 3D objects, which the AutoCAD Architecture EXPORTOTAUTOCAD2013 command could not export/explode or if the enabler was causing an error that left future AutoCAD Architecture AEC objects in the file, but removing the enabler appears to have fixed things, for now.