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.