The Building Coder

Formatting unit strings

What methods can I use to create a properly formatted unit string according to the project units?

If the value you are formatting resides in a Revit parameter, the answer is simple and a complete solution immediately provided by the Revit API. On one hand, the Parameter class provides the following public methods to read and write its parameter value:

• AsDouble: Provides access to the double precision number within the parameter.
• AsElementId: Provides access to the element id stored within the parameter.
• AsInteger: Provides access to the integer number within the parameter.
• AsString: Provides access to the string contents of the parameter.
• Set: Defines a new value for the parameter.

On the other hand, you can ask the parameter to return its current value as a preformatted string using the current unit settings:

• AsValueString: Get the parameter value as a string with unit.

It also provides access to set the value making use of such a formatted string with units:

• SetValueString: Set the parameter value according to the input string.

If the value you wish to format does not reside in a parameter, you do not have access to these methods. In that case, you might be able to temporarily hijack some existing parameter on an existing element and use that for your formatting task.

Unfortunately, you cannot simply create an own parameter for temporary use as a formatting helper, because the constructor is for internal use only. This is due to the fact that a parameter cannot live on its own; it is linked to a definition and needs to be hooked up properly in the Revit database system to work.

If you wish to avoid the hijacking, you could create an own shared parameter for an element category that occurs only once in the project and use that. How to do this is discussed the post on adding a shared parameter to a DWG file, and the Revit API introduction labs provide samples for creating and analysing parameters in Revit.

Finally, for full control over the formatting details, you can query Revit for the current unit settings using the ProjectUnit class and use that information to do the formatting yourself as you see fit. Querying the unit settings is demonstrated by the ProjectUnit SDK sample.

Running AutoCAD inside Revit

The preceding post on RealDWG and object enablers discussed one potential method for making use of AcDb functionality to read and write AutoCAD DWG files inside of Revit. Assuming that you have a license for a full version of AutoCAD in addition to your Revit one, there is another easy method to achieve this which has been implemented and tested.

It is possible to run AutoCAD as a full-blown process in the background inside Revit. This functionality is new in AutoCAD 2009, and the code we present is based on a demo by Kean Walmsley on embedding AutoCAD 2009 in a standalone dialog. Obviously this requires a full version of AutoCAD to be installed on the machine. Among other things, Kean's code defines a MainForm class, which can be used to load and run AutoCAD and access its API functionality.

Markus Hannweber of SOFiSTiK AG has made use of this within a Revit plug-in. Here are some examples of what is possible:

MainForm mainform = new MainForm();
AxACCTRLLib.AxAcCtrl c = mainform.axAcCtrl1;
c.Src = "d:\\demo\\embed.dwg";
c.PostCommand("(setvar \"cmddia\" 0) ");
c.PostCommand("(arxload\"sofibldarx\") ");
c.PostCommand("(load\"blist\") ");
c.PostCommand("SOF_BLIST ");
c.PostCommand("(S:ENDACAD) ");
c.Src = null;

The individual lines do the following:

• Instantiate Kean's MainForm class and open AutoCAD in the background.
• Initialise a variable 'c' to address the AutoCAD control. It also helps keep the source code line length under control.
• Load a drawing, object enablers are automatically loaded with it, if set up to do so.
• Suppress AutoCAD command line output.
• Load an ARX application into AutoCAD.
• Load an AutoLISP application into AutoCAD.
• Start any application command, whether defined in Lisp or ARX.
• Run a command to reset the 'drawing dirty' flag, so the next command can quit AutoCAD without user interaction.
• Close AutoCAD.

Obviously, the actions you trigger in your background AutoCAD process must not require any user interaction, or, if they do, you must feed them the appropriate command line user input through something like mainform.axAcCtrl1.PostCommand(...).

RealDWG and Object Enablers

Revit uses the RealDWG toolkit to implement the DWG file export and import functionality. A frequent question is whether there is any way to hook into this functionality, and how this relates to custom objects and DBX object enablers, like for instance: Is there a way to load a DBX application into Revit as a RealDWG extension? It would be handy to be able to reuse the functionality of some custom ObjectDBX classes.

First of all, let us clarify some terms required in this context:

• ObjectARX: The AutoCAD Runtime Extension, originally just ARX.
• ObjectDBX: The AutoCAD-independent subset of ObjectARX that deals only with the AutoCAD database, the DWG file.
• RealDWG: An AutoCAD-independent library for reading and writing DWG files using ObjectDBX in a stand-alone application. Requires a separate license.
• Custom object: An instance of a C++ class that can be stored in an AutoCAD database, implemented by an ObjectARX or ObjectDBX plug-in.
• Custom entity: An custom object that defines graphics and can reside in the block table of an AutoCAD database.
• Object enabler: An AutoCAD-independent plug-in module, i.e. an ObjectDBX plug-in, that defines the properties and behaviour of a custom object or entity.
• Proxy graphics: Hard-coded graphics data stored in a DWG file and used to render a custom object in the absence of its object enabler.

ObjectARX supports extending AutoCAD during runtime with plug-in modules implemented in C++. An ObjectDBX plug-in makes use of only an AutoCAD independent subset of ObjectARX. It can therefore be loaded both inside of AutoCAD, and outside into other non-AutoCAD host applications such as TrueView.

More details about RealDWG are provided in the RealDWG Developer Center. Thanks to Adam Nagy from our DevTech team in Europe, we also have a DevTV recording explaining how to make use of this API, available for download (97.5 MB) or for online viewing. Kean Walmsley provides a list of more DevTV recordings on various Autodesk APIs.

RealDWG itself does include a full ObjectARX runtime kernel which provides the ability to load an object enabler. It needs it to manage the ARX class relationships, and it includes the acrxLoadModule API call to load a DBX module. It obviously cannot load an ARX module, i.e. a module that depends on AutoCAD, because it is not AutoCAD.

On the other hand, RealDWG within Revit is a different story. In that context, no object enablers are loaded. Revit only uses RealDWG to display the graphics of the primitive entities within the DWG file, without bothering to load object enablers for custom classes. It does not load object enablers, even though RealDWG itself is theoretically capable of doing so.

For export, Revit uses RealDWG to generate DWG files with primitive built-in ObjectARX entities. For importing DWG files, it uses it to read and display entities and other data from the DWG file. It does not use any additional classes or do anything to manage the object hierarchy, so it does not load object enablers. All it uses is primitives already available in the RealDWG system. All custom objects just render their proxy graphics.

When you call an ObjectARX entity's worldDraw function and its object enabler is not loaded, it just returns its proxy graphics. If the enabler is loaded, the real entity calculates and returns its proper live graphics. This functionality is automatically handled by worldDraw.

Revit does not register itself as a RealDWG application, and so the object enabler installers do not see it and do not set up any object enabler autoloading.

The result is that you cannot use the RealDWG functionality built in to Revit to load an object enabler or make use of ObjectDBX functionality.

You may be able to implement your own .NET based RealDWG application inside a Revit plug-in. This combination has not been tested, however, and is not explicitly supported. You may run into problems where the RealDWG licensing mechanism interferes with the Revit plug-in security features.

If this combination works, it would enable you to make use of the AcGe library within your Revit application. It would also give you access to the acrxLoadModule, thus providing the complete required kernel functionality in able to load a DBX object enabler or handle custom objects in DWG files. If anybody has succesfully made use of this combination, it would be interesting to hear from you and discuss further details. However, there is another easy way to achieve the same result ...

A related topic is the possibility to run AutoCAD as a hidden process and make full use of all its API functionality from within Revit, which we will look at next.

Defining a New Parameter

Here are some frequent questions regarding the creation of new parameters:

I want to store a new parameter in a Revit document.

• Is there a way to do this without binding it to a specific category?
• Is it always necessary to create a shared parameter file in order to store new parameters?
• Do I need such a shared parameter file for each Revit file in which I want to store this new parameter?
• How can I store one single instance of a parameter in a Revit file?

We already discussed some aspects of shared parameters in the previous posts on adding a shared parameter to a DWG file and exploring element parameters. Those posts also mentions the Revit SDK FireRating sample and the Revit API introduction labs, especially the suite 4-3-1, 4-3-2, 4-3-3 and 4-4-1, which is relevant in this context.

New parameters can only be created as shared parameters, and they are always associated with one or more specific categories. You can create a shared parameter without explicitly setting up or reading or writing to an associated parameter file, but a valid file path still needs to be specified by the application SharedParametersFilename property, and Revit will write information about the newly created parameter into that file. This is demonstrated by the examples mentioned above.

To store one single instance of a parameter in a Revit model, you can choose to attach it to an object of a category that also only allows one instance in the database. An object that exists once and once only in every Revit model is the project information element of the category BuiltInCategory.OST_ProjectInformation. Using this to store a visible and an invisible per-document parameter is demonstrated by the Lab4_4_1_PerDocParams command.

Exploring Element Parameters

Most non-geometrical element data in Revit is stored in element parameters, so this is obviously an important topic, and one that we have not explored much yet. We did touch on it when discussing adding a shared parameter to a DWG file, and now we will recapitulate some basics and discuss the built-in parameter checker, which is a useful tool for exploring element parameters.

First some brief basic facts of life on parameters. They are discussed in more detail by the DevTV recording available for online viewing or download and the Revit API introduction labs, especially the sample commands in Labs4.cs.

Every Revit element has parameters attached to it, and the 'official' collection of parameters can be accessed through the Element Parameters property. If you are looking for a specific parameter, you can also use one of the direct access methods to retrieve a parameter from an element:

• Parameter( BuiltInParameter ): given a built-in parameter enumeration id.
• Parameter( Definition ): given a parameter definition.
• Parameter( Guid ): given a GUID for a shared parameter.
• Parameter( String ): given a localised parameter name.

A parameter has a value and a definition associated with it. The definition manages data such as the user visible parameter name and the interpretation of the parameter data. Shared parameters also have a GUID associated with them. All four methods above can be used to retrieve an individual parameter. Using the localised parameter name should be avoided, though, since it will cause the application to be language dependent. The build-in parameter enumeration is a hard-coded list of several hundred different parameters and provides a language independent method to identify most parameters.

Sometimes an element will have other parameters attached to it as well, which are not listed in the 'official' collection returned by the Parameters property. To explore all parameters attached to an element, one can make use of the built-in parameter checker.

This useful tool is included with the labs. It iterates over all the built-in parameter enumeration values and attempts to read a parameter for each one. Each one successfully retrieved is listed with all of its data, including the enumeration value, the localised name, the value, the string representation, and its read-write status. If the value is an element id, the id is evaluated and the type and name of referenced element is listed.

This tool can be used in conjunction with another tool also provided by the labs, the element lister implemented in Lab2_1_Elements, to discover information about elements that are not easy to access otherwise. As an example, let us analyse the data associated with Revit filters in the database, starting with the following question:

How can I access the filters stored in a Revit document?

We can explore this issue in the following manner: First, create an empty Revit model. In that, list all the elements in the document into a text file RevitElementsBeforeFilter.txt. Then, create a filter and list the elements again in RevitElementsAfterFilter.txt. Now we can determine the properties of the filter element that was added:

C:\tmp\ > diff RevitElementsBeforeFilter.txt RevitElementsAfterFilter.txt
2159a2160
> Id=127147; Class=Symbol; Category=?; Name=Filter 1

As you can see, one single element was added to the database, the filter element. Its System.Type is Symbol. It does not have a category associated with it, so we cannot use that to identify it. Its element name is "Filter 1". Next, we can explore its parameters and see whether they might be used to help identify filter elements. Entering the element id in the Revit menu entry Tools > Element Ids > Select by ID, select the filter into the current Revit selection set and list its parameters using the built-in parameter checker:

Symbol 'Filter 1' 127147 Instance Built-in Parameters

ELEM_CATEGORY_PARAM_MT              Category              ElementId  read-only   -1
ELEM_CATEGORY_PARAM                 Category              ElementId  read-only   -1
DESIGN_OPTION_ID                    Design Option         ElementId  read-only   -1
PHASE_DEMOLISHED                    Phase Demolished      ElementId  read-write  -1
PHASE_CREATED                       Phase Created         ElementId  read-write  -1
ELEMENT_LOCKED_PARAM                Locked                Integer    read-write  0
ELEM_DELETABLE_IN_FAMILY            Deletable             Integer    read-write  1
UNIFORMAT_DESCRIPTION               Assembly Description  String     read-only
UNIFORMAT_CODE                      Assembly Code         String     read-write
ID_PARAM                            Id                    ElementId  read-only   Symbol 'Filter 1' 127147
EDITED_BY                           Edited by             String     read-only
ELEM_PARTITION_PARAM                Workset               Integer    read-write  0
ELEM_FAMILY_AND_TYPE_PARAM          Family and Type       ElementId  read-only   -1
ELEM_FAMILY_PARAM                   Family                ElementId  read-only   -1
ELEM_TYPE_PARAM                     Type                  ElementId  read-only   -1
SYMBOL_FAMILY_AND_TYPE_NAMES_PARAM  Family and Type       String     read-only   Filters: Filter 1
SYMBOL_FAMILY_NAME_PARAM            Family Name           String     read-only   Filters
SYMBOL_FAMILY_NAME_PARAM            Family Name           String     read-only   Filters
SYMBOL_NAME_PARAM                   Type Name             String     read-only   Filter 1
SYMBOL_NAME_PARAM                   Type Name             String     read-only   Filter 1
SYMBOL_ID_PARAM                     Type Id               ElementId  read-only   -1

Please excuse the overly long lines ... you can see them in full by copying them to a text file. This shows all the information accessible through the API for the filter element. This information may be enough to identify the filters in the document. For instance, it might be possible to use combinations of these built-in parameters to construct a Revit API filter to extract all database elements of interest.

Addendum: For an improved version of the built-in parameter checker for Revit 2012, please refer to the BipChecker.

Another Revit API Blog

My friend Monika just pointed out Matt Mason's blog to me, mainly due to his nice praise for The Building Coder. Thank you, Matt! And thanks to Monika for pointing it out.

Matt covers a variety of CAD application development topics, with the main focus on Revit, judging from the current tags:

• AutoCAD 1
• Autodesk 2
• DotNet 2
• DWF 2
• Events 4
• Google Earth 1
• Intent 1
• Inventor 4
• Revit 32
• Vault 1

He is Director of Software Development at Avatech Solutions and will be presenting a class on Advanced Revit API at Autodesk University.

I'm looking forward to seeing you there soon, both you Matt and you dear reader!

Visual Studio 2008

Can I use Visual Studio 2008 to develop Revit API applications for Revit 2009?

The Revit API is .NET based, which insulates you from certain low-level details and enhances portability and interoperability compared to a more directly linked API such as C++. Kean Walmsley just published a little note on obtaining and using Visual Studio 2008 in his blog on the AutoCAD.NET API.

The notes about developing .NET applications for AutoCAD apply to Revit development as well. Officially, as stated in "Getting Started Revit API 2009.doc", the only supported Revit application development environment is Microsoft Visual Studio 2005 or the Microsoft Visual Studio 2005 Express Edition. Due to the interoperability between versions you can use 2008 anyway. You may have to avoid making use of certain features, though, such as new C# 3.0 constructs or newly added libraries, since the Revit API requires the Microsoft .NET Framework version 2.0.

Wall Elevation Profile

In this post, we explore how to determine the wall elevation boundary polygons, similarly to the floor boundary polygon algorithm. This functionality is frequently requested, last but not least in a comment by Art.

The approach is similar to the one for the floor boundary polygons, with some small additional twists. To determine the floor boundary, we simply searched for one of its two horizontal faces and queried it for its edge loops. For a wall, it is slightly more complicated to decide which face we want to query, since we cannot expect it to be aligned with any of the cardinal coordinate axes. What we can expect, however, for simple walls, is that the normal vector of the face we are interested in is perpendicular to both the wall location line and the Z axis. Then, we just have to decide whether we are interested in the face on the interior or exterior wall side. The preceding post on the wall layers discussed some analysis concerning the wall location line and its Flipped property to help determine which face is interior and exterior.

The implementation is similar to the floor boundary one and has the following main steps:

• Select wall elements to process.
• Query each wall for its location curve and solid.
• From these, determine its exterior face.
• Query the face for its edge loops and collect the polygon data from them.
• Draw model lines representing the boundary loops, offset from the wall by one foot.

Here is an example of running this algorithm on a couple of walls, showing the original walls and the resulting model lines representing the boundary loops, offset by one foot outwards from their exterior faces, and including the interior hole loops:

Determining the exterior face from the solid and assembling the polygon data from its edge loops is performed by the GetProfile helper method. It also includes some debugging sanity checks to ensure that the loops obtained are in fact closed loops, i.e. that subsequent edges join and the last vertex equals the first:

const double _offset = 1.0;

bool GetProfile(
  List<List<XYZ>> polygons,
  Solid solid,
  XYZ v,
  XYZ w )
{
  double d, dmax = 0;
  PlanarFace outermost = null;
  FaceArray faces = solid.Faces;
  foreach( Face f in faces )
  {
    PlanarFace pf = f as PlanarFace;
    if( null != pf
      && Util.IsVertical( pf )
      && Util.IsZero( v.Dot( pf.Normal ) ) )
    {
      d = pf.Origin.Dot( w );
      if( ( null == outermost )
        || ( dmax < d ) )
      {
        outermost = pf;
        dmax = d;
      }
    }
  }

  if( null != outermost )
  {
    XYZ voffset = _offset * w;
    XYZ p, q = XYZ.Zero;
    bool first;
    int i, n;
    EdgeArrayArray loops = outermost.EdgeLoops;
    foreach( EdgeArray loop in loops )
    {
      List<XYZ> vertices = new List<XYZ>();
      first = true;
      foreach( Edge e in loop )
      {
        XYZArray points = e.Tessellate();
        p = points.get_Item( 0 );
        if( !first )
        {
          Debug.Assert( p.AlmostEqual( q ),
            "expected subsequent start point"
            + " to equal previous end point" );
        }
        n = points.Size;
        q = points.get_Item( n - 1 );
        for( i = 0; i < n - 1; ++i )
        {
          XYZ a = points.get_Item( i );
          a += voffset;
          vertices.Add( a );
        }
      }
      q += voffset;
      Debug.Assert( q.AlmostEqual( vertices[0] ),
        "expected last end point to equal"
        + " first start point" );
      polygons.Add( vertices );
    }
  }
  return null != outermost;
}

Here is the CmdWallProfile mainline source code, making the call to GetProfile:

public CmdResult Execute(
  ExternalCommandData commandData,
  ref string message,
  ElementSet elements )
{
  Application app = commandData.Application;
  Document doc = app.ActiveDocument;
 
  List<RvtElement> walls = new List<RvtElement>();
  if( !Util.GetSelectedElementsOrAll(
    walls, doc, typeof( Wall ) ) )
  {
    Selection sel = doc.Selection;
    message = ( 0 < sel.Elements.Size )
      ? "Please select some wall elements."
      : "No wall elements found.";
    return CmdResult.Failed;
  }
 
  XYZ p, q, v, w;
  List<List<XYZ>> polygons = new List<List<XYZ>>();
  Options opt = app.Create.NewGeometryOptions();
 
  foreach( Wall wall in walls )
  {
    string desc = Util.ElementDescription( wall );
 
    LocationCurve curve
      = wall.Location as LocationCurve;
 
    if( null == curve )
    {
      message = desc + ": No wall curve found.";
      return CmdResult.Failed;
    }
    p = curve.Curve.get_EndPoint( 0 );
    q = curve.Curve.get_EndPoint( 1 );
    v = q - p;
    v = v.Normalized;
    w = XYZ.BasisZ.Cross( v ).Normalized;
    if( wall.Flipped ) { w = -w; }
 
    GeoElement geo = wall.get_Geometry( opt );
    GeometryObjectArray objects = geo.Objects;
    foreach( GeometryObject obj in objects )
    {
      Solid solid = obj as Solid;
      if( solid != null )
      {
        GetProfile( polygons, solid, v, w );
      }
    }
  }
 
  int n = polygons.Count;
 
  Debug.WriteLine( string.Format(
    "{0} boundary loop{1} found.",
    n, Util.PluralSuffix( n ) ) );
 
  Creator creator = new Creator( app );
  creator.DrawPolygons( polygons );
 
  return CmdResult.Succeeded;
}

Here is an updated version 1.0.0.13 of the complete Visual Studio solution, including the new CmdWallProfile and all other commands discussed so far.

Wall Compound Layers

We have examined floor and slab geometry in some detail now, and would like to have a look at walls as well. One important aspect of walls is their internal layering, defined by the compound layer structure. In this post, we examine the layer geometry, i.e. how to determine the exact location of the different layers within the wall structure. Many thanks to Harry Mattison for providing lots of support developing this code and explaining both the API and the user interface issues involved.

We have the following sources of input:

• Wall location curve and total wall thickness:

  LocationCurve curve = wall.Location as LocationCurve;
  double thickness = wall.WallType.Width;
  

• Compound structure layers and their individual thicknesses:

  CompoundStructure structure = wall.WallType.CompoundStructure;
  CompoundStructureLayerArray layers = structure.Layers;
  

How can these be used to determine the exact positions of the individual wall layers and the wall itself?

The most important bit of information in this context is that the wall centre line is always given by the wall location curve, and that is not affected by any other settings.

There are some additional wall parameters that we first thought might influence these positions:

• Location Line WALL_KEY_REF_PARAM
• Location Line Offset WALL_LOCATION_LINE_OFFSET_PARAM

WALL_KEY_REF_PARAM describes the setting of the wall's Location Line property. However, wall.Location is always the centre of the wall, not the position of the 'Location Line' visible in the user interface:

So this property will not affect the computation of the wall layer locations.

WALL_LOCATION_LINE_OFFSET_PARAM only affects walls that are used as panels in a curtain wall. It offsets the wall panel from the face of the curtain wall. Again, this parameter will not affect the wall layer analysis, because wall.Location will be the centre of the wall panel, regardless of any offset.

So now we have clarified the different inputs available, how can these be combined to determine the exact location of each layer?

From the wall and its location line, we can obtain the wall thickness and the wall centre line start and end point. Assuming a horizontal wall base line and vertical sides, we can calculate the vectors v, pointing along the location line from its start to its end point, and w, pointing perpendicularly to the location line and the Z axis towards the exterior edge of the wall. Both of these are normalised, i.e. one foot long, since the Revit database always uses feet as units for length measurements. If we multiply them by the wall length and half the wall thickness and draw them starting from the location line start point, they look like this:

We use the location line start and end points, the wall thickness, and these two vectors to construct various model lines: the first simply displays the wall location line, extended by two feet in both directions beyond the end of the wall. We draw a second model line representing w multiplied by half the wall thickness at the starting point of the first, perpendicular to it. Then, we draw model lines deliminating the different wall layers. We lengthen the layer delimination lines by one foot in both directions beyond the end of the wall.

Here is an example of a set of compound walls at various angles:

Here is the result of running the wall layers command on that set, adding the model lines representing the wall location line, extending two feet beyond the end of each wall, its half thickness and exterior side, and the wall layer delimination lines extending one foot beyond the wall end:

We do need to pay attention to the wall Flipped property. If Flipped is true, the interior and exterior sides of the wall are swapped, so the layering is reversed. We can account for this reversal by negating w if Flipped is true.

Here is a more detailed view of one of the compound walls in its original state:

Running the wall layers command adds the model lines described above:

Flipping the wall swaps it interior and exterior faces and reverses the layering:

Checking the Flipped property and negating the vector w pointing to the exterior face reverses the order of the layer delimitation lines as well:

While iterating over the wall layers, the command prints some data to the Visual Studio debug output window, listing the wall description, thickness, number of layers, and the function and thickness of each layer:

Walls <128581 Jeremy Compound> with thickness 300 mm has 4 layers:
  Layer 1: function Finish1, thickness 25 mm
  Layer 2: function ThermalOrAir, thickness 50 mm
  Layer 3: function Structure, thickness 200 mm
  Layer 4: function Finish2, thickness 25 mm

While preparing the snapshots above, I also had to deal with a completely different question, a simple user interface issue not related to the API: how can I display the detailed wall compound structure on the graphics screen and ensure that hatch patterns for the different layers are displayed? There are a few steps required: first, change the view property from Coarse to Fine. At that point, I see the lines dividing the layers, but no hatches. For the hatching, make sure the wall layers are defined to use materials that have a cut pattern. Also ensure that you are zoomed in enough in the view so the pattern does not overscale, i.e. turn to gray fill, because the lines are too close to each other.

Here is the CmdWallLayers source code:

public CmdResult Execute(
  ExternalCommandData commandData,
  ref string message,
  ElementSet elements )
{
  Application app = commandData.Application;
  Document doc = app.ActiveDocument;

  List<RvtElement> walls = new List<RvtElement>();
  if( !Util.GetSelectedElementsOrAll(
    walls, doc, typeof( Wall ) ) )
  {
    Selection sel = doc.Selection;
    message = ( 0 < sel.Elements.Size )
      ? "Please select some wall elements."
      : "No wall elements found.";
    return CmdResult.Failed;
  }
 
  int i, n;
  double halfThickness, layerOffset;
  Creator creator = new Creator( app );
  XYZ lcstart, lcend, v, w, p, q;
 
  foreach( Wall wall in walls )
  {
    string desc = Util.ElementDescription( wall );
 
    LocationCurve curve
      = wall.Location as LocationCurve;
 
    if( null == curve )
    {
      message = desc + ": No wall curve found.";
      return CmdResult.Failed;
    }

    //
    // wall centre line and thickness:
    //
    lcstart = curve.Curve.get_EndPoint( 0 );
    lcend = curve.Curve.get_EndPoint( 1 );
    halfThickness = 0.5 * wall.WallType.Width;
    v = lcend - lcstart;
    v = v.Normalized; // one foot long
    w = XYZ.BasisZ.Cross( v ).Normalized;
    if( wall.Flipped ) { w = -w; }
 
    p = lcstart - 2 * v;
    q = lcend + 2 * v;
    creator.CreateModelLine( p, q );
 
    q = p + halfThickness * w;
    creator.CreateModelLine( p, q );
 
    // exterior edge
    p = lcstart - v + halfThickness * w;
    q = lcend + v + halfThickness * w;
    creator.CreateModelLine( p, q );
 
    CompoundStructure structure
      = wall.WallType.CompoundStructure;
 
    CompoundStructureLayerArray layers
      = structure.Layers;
 
    i = 0;
    n = layers.Size;
    Debug.WriteLine( string.Format(
      "{0} with thickness {1} mm"
      + " has {2} layer{3}{4}",
      desc,
      Util.FootToMm( 2 * halfThickness ),
      n, Util.PluralSuffix( n ),
      Util.DotOrColon( n ) ) );
 
    if( 0 == n )
    {
      // interior edge
      p = lcstart - v - halfThickness * w;
      q = lcend + v - halfThickness * w;
      creator.CreateModelLine( p, q );
    }
    else
    {
      layerOffset = halfThickness;
      foreach( CompoundStructureLayer layer
        in layers )
      {
        Debug.WriteLine( string.Format(
          "  Layer {0}: function {1}, "
          + "thickness {2} mm",
          ++i, layer.Function,
          Util.FootToMm( layer.Thickness ) ) );
 
        layerOffset -= layer.Thickness;
        p = lcstart - v + layerOffset * w;
        q = lcend + v + layerOffset * w;
        creator.CreateModelLine( p, q );
      }
    }
  }
  return CmdResult.Succeeded;
}

I am adding version 1.0.0.13 of the complete Visual Studio solution here, including the new CmdWallLayers and all other commands discussed so far. In fact, it even includes another command that we have not discussed yet, and will address in the next post.

Editing a floor profile

A question that recently came up was how to edit an existing floor profile. This also leads to the question of whether one can access the existing sketch lines through the API and modify them.

In the user interface, one can enter the Floor Edit mode and modify the sketch lines of a floor. In the API, this is not possible. However, it is possible to simply recreate the floor with a new curve array.

The next question that pops up is how to determine the sketch lines of the existing floor, as a starting point for recreating a new floor with a slightly modified set of sketch lines.

To recreate a floor from the existing one, one can determine the topmost horizontal face of the floor solid, using an algorithm very similar to the one we looked at for determining the slab boundary. We can extract the top face edges, create line elements from them to assemble the floor profile, and generate the new floor from that. In case the existing floor has holes in it, the face will have several loops. The largest loop is the outer perimeter. In my tests so far, this was also the first loop in the EdgeArrayArray, but that may not always be true.

Here is a helper method to extract the topmost face from the solid:

PlanarFace GetTopFace( Solid solid )
{
  PlanarFace topFace = null;
  FaceArray faces = solid.Faces;
  foreach( Face f in faces )
  {
    PlanarFace pf = f as PlanarFace;
    if( null != pf
      && Util.IsHorizontal( pf ) )
    {
      if( (null == topFace)
        || (topFace.Origin.Z < pf.Origin.Z) )
      {
        topFace = pf;
      }
    }
  }
  return topFace;
}

Here is the code for the rest of the command:

public CmdResult Execute(
  ExternalCommandData commandData,
  ref string message,
  ElementSet elements )
{
  Application app = commandData.Application;
  Document doc = app.ActiveDocument;

  List<RvtElement> floors = new List<RvtElement>();
  if( !Util.GetSelectedElementsOrAll(
    floors, doc, typeof( Floor ) ) )
  {
    Selection sel = doc.Selection;
    message = ( 0 < sel.Elements.Size )
      ? "Please select some floor elements."
      : "No floor elements found.";
    return CmdResult.Failed;
  }

  int nNullFaces = 0;
  List<Face> topFaces = new List<Face>();
  Options opt = app.Create.NewGeometryOptions();
 
  foreach( Floor floor in floors )
  {
    GeoElement geo = floor.get_Geometry( opt );
    GeometryObjectArray objects = geo.Objects;
    foreach( GeometryObject obj in objects )
    {
      Solid solid = obj as Solid;
      if( solid != null )
      {
        PlanarFace f = GetTopFace( solid );
        if( null == f )
        {
          Debug.WriteLine(
            Util.ElementDescription( floor )
            + " has no top face." );
          ++nNullFaces;
        }
        topFaces.Add( f );
      }
    }
  }

  Autodesk.Revit.Creation.Application creApp = app.Create;
  Autodesk.Revit.Creation.Document creDoc = doc.Create;
 
  int i = 0;
  int n = topFaces.Count - nNullFaces;
 
  Debug.WriteLine( string.Format(
    "{0} top face{1} found.",
    n, Util.PluralSuffix( n ) ) );
 
  foreach( Face f in topFaces )
  {
    if( null != f )
    {
      CurveArray profile = new CurveArray();
      EdgeArrayArray eaa = f.EdgeLoops;

      EdgeArray ea = eaa.get_Item( 0 );
      foreach( Edge e in ea )
      {
        XYZArray pts = e.Tessellate();
        int m = pts.Size;
        XYZ p = pts.get_Item( 0 );
        XYZ q = pts.get_Item( m - 1 );
        Line line = creApp.NewLineBound( p, q );
        profile.Append( line );
      }
      Floor floor = floors[i++] as Floor;
      floor = creDoc.NewFloor( profile, floor.FloorType, floor.Level, true );
      doc.Move( floor, new XYZ( 5, 5, 0 ) );
    }
  }
  return CmdResult.Succeeded;
}

The first section retrieves selected floors from the current selection set, or all floors from the database, if nothing has been preselected. Then the top face of each selected floor is determined by retrieving each floor's solid and calling GetTopFace on it. Even if no top face was found, we still store the null result, so that the list of floors and faces match up. Finally we go through the array of top faces and create new floors from them. Before creating the new floor, we would obviously apply whatever modifications are required to the new floor profile. In this case, we have no modifications to apply, so the new floor will be identical to the existing one. To differentiate it, we move it away from the original location, five feet up and to the right. In case the original floor had some non-linear edges, these will be replaced by straight ones. All holes will also be lost. From the EdgeArrayArray instance returned by the face EdgeLoops property, we only make use of the first element, which seems to be the outer perimeter, i.e. boundary. Holes seem to be listed later in this array. If this assumption is not true, we would have to iterate over the array and analyse each loop to find the maximum size, which would ensure that is the outer boundary and not an inner hole loop.

Here is a sample floor element before running the command:

Here is the original floor and the newly created copy offset from it and lacking holes after running the command:

I am adding a new version 1.0.0.11 of the complete Visual Studio solution here, including the new CmdEditFloor and all other commands discussed so far.