April 20, 2016

Autodesk Answer Day

The next Autodesk® Answer Day will be on May 18, 2016, from 6:00 am to 6:00 pm U.S. Pacific Time. Unlike previous Answer Days, this one will not apply to just one featured software; Autodesk team members will be scouring the AutoCAD, AutoCAD Civil 3D, Revit, Inventor, Vault, Maya and 3ds Max forums.

Read more about the event here and mark your calendar.

April 08, 2016

ACA 2017: CReate type Command Option

Another new feature that some may find of use is the addition of a new command line option, CReate type when adding Walls, Curtain Walls, Railings, Slabs, Roof Slabs and Roofs.

Selecting the CReate type option results in a new command line prompt. The default action is to create a Rectangle shape (by picking the opposite corners of the rectangle). Other shape options are Circle, POlygon and PLine.
Command prompts for those options follow those of the AutoCAD object commands of the same name. While you may not have many occasions for wanting to draw Walls along the lines of a regular polygon, do check out the PLine option, particularly for the object types that do not offer Arc as a command line option (Railings, Slabs, Roof Slabs and Roofs) in the "regular" Add command. For Walls and Curtain Walls, the PLine option makes it much easier to create arc segments that are tangent to the previous segment. And an added bonus when creating Slabs and Roof Slabs, you do not have to explicitly close your shape, as you do when drawing segments under the "regular" Add command. Finally, when using the PLine option when creating a Roof object, you can use object snap tracking to align the next vertex with previous vertices, which you cannot do in the "regular" Add command. This makes it easier (possible) to align your last vertex with the starting vertex on initial placement, rather than having to edit it afterwards.

April 03, 2016

ACA 2017: Grip Editing of a Roof Object Outline

It is that time of year again, when the new releases of Autodesk software come out. One of the new features you can look forward to in AutoCAD® Architecture is the ability to grip edit a Roof Object's outline, allowing you to modify it after the original placement.

As you can see in the image above, in 2016, all of the grips on a Roof are single-function square stretch grips. In 2017, the grips on the Roof outline are enhanced, multi-function grips. Hover over the round vertex grips or the rectangular mid-segment grips to get a pop-up menu offering several grip-edit options.

Vertex Options
For a vertex grip, the Move option is the equivalent to the grip behavior in 2016 and prior. Moving the corner grip moves just the corner point; the other vertices remain in place.

The Remove option does just that, it deletes the vertex.
Of the two roof edges that are deleted, the resulting roof edge will assume the properties of the lowered numbered edge. To see what those properties are, on the Roof contextual ribbon tab, on the Modify panel, select the Edit Edges tool and select the edges on either side of the vertex you plan to remove. The properties in the top row (edge "0") will be applied to the resulting roof edge when you remove that vertex.

The Offset Edges option also allows you to move the vertex, but, unlike the Move option, when you use the Offset Egdes option, the two adjacent edges will remain parallel to their original orientation, and the vertices at the far ends will move as required to allow that.

Mid-segment Options
The Offset option offers the equivalent of the 2016 and prior stretch grip. Selecting this option will allow you to move the entire edge, which will remain parallel to its original orientation. The vertices at either end will move as needed, maintaining the line of the adjacent edges.

To add a new vertex to the Roof, choose the Add Vertex option. The two new Roof edges will inherit the edge properties of the edge they replace.

The Convert to Arc option will convert that roof edge to an arc, and the arc edge of the Roof will be approximated by six straignt segments with the segment endpoints on that arc. (You will not get a conical Roof.)
The arc segment will continue to be treated as one Roof edge; if you desire a different number of segments on the arc, on the Roof contextual ribbon tab, on the Modify panel, select the Edit Edges tool and select the arc edge. In the Roof Edges and Faces dialog, change the value in the Segements column to the desired number of edges.

As with other enhanced grips, in addition to selecting an option from the pop-up menus as noted above, you can select the grip and then, before selecting a new point, tap the CTRL key to cycle through the available options. Preview graphics will show the effects of the currently active option, and, for the mid-segment grip, with ORTHO or POLAR active, if you stop moving the cursor, you will get a tool tip with directions for the current option and a listing of the other options. (For POLAR, a tracking vector must be active for the tooltip to show.)

The brief Screencast below shows the various Roof Object outline grip options in action.

March 28, 2016

Dynamo: Active View Walls at Plan View Level

We use several line-based Detail Items to show fire and smoke ratings on Walls, based on NFPA standard symbols (filled diamonds, one for each hour of fire-resistance rating, with an "S"appended if the wall is also a smoke barrier; unrated smoke partitions get just the "S"). Placing these in plan views is tedious, at best, and it seemed to me that since the fire/smoke rating information is already attached to the Walls in a parameter, and the endpoints of the Wall and the endpoints of the line-based Detail Item are one and the same, that a Dynamo graph ought to be able place the correct family on each Wall. NOTE: This graph was developed using Dynamo 0.8.2.

For the purposes of my proof-of-concept first pass, I chose to focus just on straight Walls. Several early experiments revealed that simply grabbing all of the Walls in the active view would not work if there were Walls within the current View whose Base Constraint was not at the same level as the level associated with the View, as the node that creates the Detail Items would crash if passed a Wall whose Base Constraint was at a different level. I assume that is because the node was trying to create a Detail Item (annoation) at a level other than the current level. Some of these Walls were Walls at a lower level, not seen because they were hidden by the Floor, but due to the View range Bottom being set below the associated level. We would not want to have the line-based family drawn for these. Others could be multi-story Walls, with a Base Constraint at a lower level, where we would want to show the fire/smoke family. For the first pass, these Walls will still need to be done manually; I do not expect there will be many of these in a project.

So my first task was to be able to get a list of all Walls in the current View whose base constraint matched that of the currently active View. I ended up creating a custom node that takes no input, and has three outputs: in [Walls in the active View whose Base Constraints match the associated level of the active View], out [all other Walls in the active View] and level [for plan views, a text string indicating the name of the associated level; for all other views, a text string indicating "Not a Plan View"]. The in output is the one on which the main graph will operate; the other two are there for diagnostic purposes. If the main graph is not behaving as expected, it can be useful to see whether Walls that you expect to receive a Detail Item are in the out list. If all of the Walls end up in the out list, checking the level output to see if there is an unexpected value or that the graph was mistakenly run in a non-plan view can also be helpful in troubleshooting.

There are a number of nodes inside the custom node. One group extracts the level name of the currently active View, by using the Document.Current, Document.ActiveView and Element.GetParameterValueByName nodes, along with a Code Block to provide the name of the parameter of interest, which is "Associated Level". For plan Views, this will be the name of the level with which the View is associated. Non-plan Views (such as elevations or section) will return an empty text string, as they do not have this parameter.

Another group generates a list of all of the Walls in the active View, starting with the All Elements in Active View node. This list is winnowed down to just the Walls by using a RemoveIfNot node, with the type set to "Wall".

A list of names of the level to which each Wall's Base Constraint is associated is derived using two Element.GetParameterValueByName nodes. The first gets the value of the Base Constraint parameter of each Wall; the second gets the name of each Base Constraint.

The level name with which the active View is associated is then compared to the list of level names of the Base Constraints of the Walls using an == (x equal to y) node. This creates a list of true or false values, indicating whether or not the corresponding Wall's Base Constraint level is the same as the active View's level (true means they are the same, false means they are different). This list is used as the mask by a List.FilterByBoolMask node, which splits the list of Walls in the active View into two lists: the "in" list, for Walls where the Base Constraint level matches the level of the active View, and the "out" list, where the levels do not match.

The outputs of the List.FilterByBoolMask node are the "in" and "out" outputs of the custom node. The "level" output is generated by an If node. The test for the If node is an == node, which compares the name of the active View's Associated Level to an empty string. If the level name is equal to an empty string (active View is not a plan view), then the If node result is the text in the Code Block node, "Not a Plan View" (true input). If the active View's Associated Level is not an empty string, then the name of the active View's Associated Level is the result (false input). The If node result is the "level" output of the custom node.

The entire graph of the custom node, which includes a few Watch nodes that were not shown above and which were useful during development but which could be deleted from the custom node, is shown in the image below.

February 26, 2016

Dynamo: Exporting All Schedules in a Revit Model

Autodesk® Revit® allows you to export the contents of a single Schedule View to a tab-delimited text file which can then be opened in a spreadsheet program, such as Microsoft® Excel® [Application Menu > Export > Reports > Schedule]. Handy enough, but what if you have multiple Schedule Views that need to be exported multiple times during the life of a project, as part of a defined information exchange? Individually exporting each Schedule View could quickly become tedious.

Let Dynamo deal with the tedium. A fairly simple graph will export all of the Schedule Views in a project.
This graph is set up to be run manually, as the user will need to use the Directory Path node to specify the folder into which the exported Schedule Views will be placed. The Element Types and All Elements of Type nodes gather all of the Schedule Views [ViewSchedule objects] in the project. The Element.Name and Code Block nodes create the file name for each exported Schedule View by concatenating the ViewSchedule Name with a ".txt" file extension. The Python Script node does the heavy lifting, taking a list of ViewSchedule objects, the directory path and a corresponding list of file names, generates the exported files, and returns a list indicating whether or not each item was exported.

Credit for the Python Script belongs to Dimitar Venkov, who posted a script for exporting a single ViewSchedule in this thread in the Dynamo forum. I modified that script to work with a list of ViewSchedules and a corresponding list of exported file names. A for loop processes each ViewSchedule in turn, and a list of the results is gathered and set as the node output.

Variations on this can be done to export a selected number of ViewSchedules. A simple version is shown below, in which the user has to set up a series of Views nodes, one for each desired ViewSchedule, and then generate a list by passing each one to an input of a List.Create node. A little labor intensive, but if you need to do this multiple times for a given project, you could save a copy with the needed ViewSchedules set up and then run it when new exports are needed

Antony McPhee posted examples using a string filter to export all of the ViewSchedules with a Name starting with a specified string to that same Dynamo forum thread.

February 10, 2016

Revit: Which Update Corresponds to Which Build Number?

This Autodesk Knowledge Network Article lists the Build Number for Autodesk® Revit® versions from 2012 through 2016, Update 1 for R2. I expect the article will be updated with any future updates/service packs for 2016 (and beyond).

The Build Number can be determined by selecting the About Autodesk Revit 20xx item on the Help drop-down list found at the upper right corner of the Revit window. Select the right portion of the Help split button (with the down arrow icon) to deploy the drop-down list.

The Build Number is located in the upper right corner of the About Autodesk Revit 20xx dialog.

(Click on any image to see a full-size version.)

January 27, 2016

ACA: Ceiling Grid Boundary Selection and Resource Manager Error

That is a pretty scary warning dialog. It makes me think that, at the very least, my AecGuiBase70 file has some form of corruption. If you receive this error dialog while adding a Ceiling Grid and using the Set boundary command option to select a Polyline as the ceiling boundary, your AecGuiBase70 is just fine. The problem is that the Polyline you selected is not a closed Polyline.

"But wait!" you exclaim. "That Polyline looks closed to me." It may very well looked closed, but when drawing the Polyline, merely snapping the last point to the first point does not a closed Polyline make. Next time, stifle the urge to add one more point on top of the first point, and use the Close command option, by selecting it on the Command Line, or by typing C and then pressing the ENTER key.
Fix the already drawn Polyline by using the Close command option of the PEDIT command or by selecting the Polyline and, on the Properties palette, on the Design tab, under the Misc category, set the Closed property to Yes.

BONUS TIP: You can double-click that Polyline to initiate the PEDIT command on that Polyline. Personally, I would get rid of that last vertex and then close the Polyline, but that is not necessary for the Polyline to be a valid Ceiling Grid boundary.

Curiously, the Set boundary option of the CEILINGGRIDCLIP command provides an informative message at the Command line, rather than the non-informative Error dialog the CEILINGGRIDADD command gives, when selecting an open Polyline as the boundary.
The CEILINGGRIDCLIP command is used to add a clipping boundary to an already-placed Ceiling Grid, and can be accessed by selecting the Ceiling Grid and then, on the Ceiling Grid contextual ribbon tab, on the Clipping panel, by selecting the Set Boundary tool.

January 26, 2016

ACA: CREATEHLR Command Precision

The CREATEHLR command in AutoCAD® Architecture can be useful in generating a 2D view, with hidden lines removed, of 3D geometry. (Generating a 2D Elevation is another way; each has its uses.) I spent some time today searching the internet for the system variable that will increase the accuracy of hiding (and shading), as my memory failed to call up the information, and I am posting this to make it easier for me to find in the future.

The HIDEPRECISION System Variable controls whether hiding is calculated using single-precision numbers (when set to 0) or double-precision numbers (when set to 1). Double-precision calculations are more accurate, but require more memory, which can have a significant performance hit, particularly if 3D solids are involved in the hide. The value of HIDEPRECISION is not saved, and is initially set to 0 at the beginning of each AutoCAD session.

January 24, 2016

ACA: AEC Modify Tools, Part 6, AEC Merge

First post in series [AecLineworkExtend]
Previous post in series [AecLineworkObscure]

The AecLineworkMerge command can be found on the Home ribbon tab, on the Modify panel flyout, by selecting the Merge tool from the Merge/Subtract flyout. If the Merge tool is not displayed on the Merge/Subtract flyout, select the right side of the split button (down arrow icon) to deploy the flyout and choose the Merge tool. Or, with no command active, you can right click in the drawing window, and choose AEC Modify Tools > Merge from the context menu.

The AecLineworkMerge command is used to modify the extents of closed Polylines, Circles, Hatches, AEC Polygons, Mass Element Extrusions that have an embedded profile and Spaces, as well as Block References which contain any of these objects by "merging" the original object with one or more other objects that define the change to the perimeter. In lieu of selecting one or more objects to merge into the initially selected object(s), you can also specify a rectangular area by selecting its opposite corners, and that rectangular area will be merged into the the intially selected object(s). You will be given the option to erase the object(s) to merge (the object or objects selected at the second prompt for the object(s) that define the changed perimeter); the default is No, which leaves the object(s) to merge in the drawing file.

If you select multiple objects at the first prompt, the AecLineworkMerge command is applied to each of those independently, using the objects selected at the second prompt on each of those selected at the first prompt. Here are some additional notes regarding the AecLineworkMerge command:
  • Open linework cannot be used as the linework to add to (first prompt), neither can MText, Text, Ellipses nor Ellipse Arcs. The command will allow you to select an open Polyline as the linework to add, but will not make any change to it.
  • MText, Text, Ellipses and Ellipse Arcs can be selected as (part of) the objects to merge. For MText and Text, the bounding box of the text is used as a rectangle to be merged.
  • The type of the initial object selected will determine the type of the merged object. Allowed AEC objects will result in an AEC object of that same type, as do Hatches. Closed Polylines and Circles will result in closed Polylines.
  • Mass Elements with a shape other than "Extrusion" and Mass Element Extrusions that have an external Profile can be selected as linework to add to, but will not affected by the AecLineworkMerge command. These types of Mass Elements can be selected as an object to merge.
  • If a Block Reference is selected as linework to add to, only those nested objects within the block on which the AecLineworkMerge command works will be affected.
  • Attributes within a Block Reference will not be affected by the AecLineworkMerge command.
  • If a Block Reference is selected as linework to add to, it has nested elements that can be affected by the AecLineworkMerge command and it is the only instance of that Block Reference in the drawing, then the original block definition will be redefined to include the effects of the merge. If at least one instance of the Block Reference remains unaffected by the merge, then the original block definition will remain unchanged and the affected instance(s) will become instance(s) of new, anonymous block definition(s).
  • If a Block Reference is selected as linework to add to and it has multiple nested elements which can be affected by the AecLineworkMerge command, the merge will be applied to each of those elements independently.
  • Multi-View Blocks can be selected as linework to add to, but will not be affected by the command.
  • If the active View Block of a Multi-View Block contains linework that forms a closed boundary or contributes to a closed boundary, it can selected as an item to merge.
  • Selecting an associative Hatch as linework to add to will result in a non-associative Hatch, regardless of whether or not the boundary of the Hatch is also selected as linework to add in the same AecLineworkMerge command.
  • Associative Spaces, Walls, Doors, Windows and Door/Window Assemblies can be selected as linework to add to, but will not be affected by the command. These objects can be used as object to merge. Non-associative Spaces can be modified by the AecLineworkMerge command when selected as linework to add to.
  • The object(s) to merge do not have to form a closed loop. If multiple objects are selected, they do not have to meet endpoint to endpoint, although the results may be unexpected if there is overlap.
  • The object(s) to merge do not necessarily have to intersect the linework to add to object(s). If the linework to add to objects support it (), a single object with two disconnected parts will be formed (Hatches, AEC Polygons, Mass Element Extrusions that have an embedded profile and Spaces). Closed Polylines and Circles will generate a closed polyline around the object(s) to merge or indicated rectangle, but will remain separate from original objects. (If a Circle is the linework to add to, and the object(s) to merge do not intersect it, it will remain a Circle.) If a Block References is selected as the linework to add to, and the object(s) to merge do not intersect it, there will be no change (unless you delete the object(s) to merge, in which case that object/those objects will be deleted).

There are object types and combinations of objects within a Block Reference that I did not test. When using the AecLineworkMerge command in a situation that you have not previously encountered, you may want to use the Mark option of the UNDO command, so that you can easily UNDO Back to the point before the command was used if you get unexpected results.

January 21, 2016

AutoLISP: Running TXT2MTXT Separately on Multiple TEXT Objects

Of the Express Tools that have not been incorporated into the main program, the TXT2MTXT command, for converting AutoCAD® TEXT objects to MTEXT objects is one of my most-used. I had a drawing with more than 50 TEXT objects that needed to be converted to individual MTEXT objects. The TXT2MTXT command will allow you to select multiple TEXT objects, but it will convert them all into a single MTEXT object. I could have just run the command once for each TEXT object, but I decided that writing a simple AutoLISP® routine would probably take about the same amount of time as this one use, and then I would have it to speed future, similar uses. Here is the function I devised:
(defun C:MLTPL_TXT2MTXT (  ; No arguments.
    / ;_ Local variables:
    acmde  ; Command echo mode.
    ename  ; Entity name of TEXT object being processed.
    icount  ; Loop counter.
    ss1  ; Selection set of TEXT objects on which to operate.
   ) ;_ End arguments and local variables.
  (setq acmde (getvar "CMDECHO")) ; Command echo mode.
  (setvar "CMDECHO" 0)   ; Turn off command echo.
  (prompt "\nSelect TEXT objects to be converted to MTEXT. ")
  (setq ss1    (ssget '((0 . "TEXT")))
 icount 0   ; Initialize loop counter.
  ) ;_ End setq.
  (cond     ; cond A.
    (ss1    ; If TEXT objects selected, do the following:
     (while (setq ename (ssname ss1 icount))
       ;; While unprocessed TEXT objects remain:
       (command "TXT2MTXT" ename "") ; Process text.
       (setq icount (1+ icount)) ; Increment counter.
     ) ;_ End while.
     (prompt "\nAll selected TEXT has been converted to individual MTEXT objects. ")
    ) ;_ End condition A.1.
    (T
     (prompt
       "\nNo TEXT objects selected.  C:MLTPL_TXT2MTXT terminated. "
     ) ;_ End prompt.
    ) ;_ End condition A.2.
  ) ;_ End cond A.
  (setvar "CMDECHO" acmde)  ; Restore previous command echo mode.
  (prin1)    ; Exit quietly.
) ;_ End C:MLTPL_TXT2MTXT.