Before you begin, check out our latest plug-in v4.0.0 for Revit with new features and enhanced capability to work with additional Revit geometries.
​

Also, check out the ideal Revit model for cove.tool workflow here. These two articles will be your ultimate guide to modeling in Revit.

In this article, we list 2 types of situations when using the Revit plug-in, problematic and messy. These are terms that are used to describe situations that may cause difficulties when attempting to export geometry to cove.tool or when attempting to accurately calculate results once inside the 3D analysis page. Problematic situations range from incompatible model elements that will generate errors when attempting to export, to instances where elements might be changed once rendered inside cove.tool's 3D page. Problematic situations tend to require timely changes, and in extreme cases, require that certain elements be entirely excluded from a cove.tool analysis. A messy situation is a more manageable occurrence where simple steps can be taken to remedy the situation, and are listed as a heads-up to users exporting to export with the Revit plugin soon.

This describes the custom volumetric forms whose construction method vastly differentiates them from the rest of the Revit categories. These elements are volumetrically constructed (extrude, blend, sweep, void) and thus have a 3-axis make-up. Since the construction method is custom, Revit does not store single-surface mesh data, which is what the plugin reads in order to generate daylight models in the app. Other Revit categories, although they seem volumetric, are all planar with various attributes applied to them (thickness, material, properties, etc). Since the information varies on which construction method is used, the objects may be imported but it is unlikely. Users will need to remodel these elements with compatible methods like generic walls, floors, or mullion families.
One way to check if you'll have any issues while exporting to cove.tool is to see if the generic model has a line for the area value in the Revit Properties window. Information embedded can be immediately accessible to the plugin, but if there is no area information, even though it may have a height or width, the component might be rejected. If this object is rejected, then users should have the family tag changed or remodeled as a compatible object type with an area value.

The plugin cannot collect sloped geometry for the Floors export. Due to the nature of the 3D Analysis tools (Daylight sDA% and Glare ASE%), cove.tool requires flat or stepped geometry to accurately generate grid-point/ heat map results.
​

This Is the scenario when two or more elements occupy the exact same location in space. In the 3D visualization, this co-planar situation will cause a stitching effect and make it difficult for the user to select and/or separate these items. In the plugin, z-fighting can cause the export or simulation to crash or give inaccurate results because it cannot decipher which it should select for export and/or takes multiples. This would cause a data conflict in the information. Make sure to not export geometry that occupies the same locations in space.

This describes models or elements, which have incredibly detailed or highly textured surfaces; this includes furniture, trees, people, parametric architecture, frit, or perforated shading materials. The typical file size of a general cove.tool export is less than 10-30 MB, but a file with a high surface count can generate a file size in excess of 300 MB. Note, however, that this issue is one of complexity and not size. Cove.tool can quickly gather details about a skyscraper, but collecting the data needed to recreate a tree can be 30 times more tenuous. Since the plugin will collect each plane of your model view record the surface area and coordinate the position of every element, simpler geometry will make a faster process. Simplify problematic geometry like context and shading elements by converting them into cubes of the massing-in-place command. Try to avoid irregular spheroid forms or other complex geometry as this will slow down the simulation while not increasing accuracy.

This is the method of loading a family of one component into the family of another. The data structure of how the geometry is handled in nested families prevents the area information and any singular object from being exported. For example, using a window type loaded into a custom wall family instead of loading it directly into the model. The window type inside the wall family will not be searchable in the main model. The parameters can be "shared", as described by Autodesk to extract schedules, but the geometry does not function in the same way. It is better to model any components, like windows, that need to be exported as a cove.tool layer directly in the component family and then loaded into the model. Also, ensure the objects are properly subcategorized as discussed in our article on windows and curtainwalls. Elements from nested families can be exported as long as embedded families are properly upgraded from older versions. It is generally beneficial to avoid multiple nested families.

Groups in Revit prevent the plugin from collecting the data of individual elements that are needed to recreate your model inside cove.tool. Ungroup these items in your file first. If your firm's typical workflow is to create groups for rooms, levels, or building components then the user might be required to detach a copy of the file and not use an ongoing working model.

The problems that can be created with curtain walls are less about the family type, and more about the issue of multi-tasked objects. Revit modelers tend to use the curtain wall family to model a wide range of items, especially when they need a repeating pattern to cover a large area. The point in which the curtain walls can start to trigger flaws in the export or simulation is when curtain walls have a mixture of categories embedded into the element. Users may attempt to model glass panes, spandrel panels, fins, and exterior walls all in the same layer. However, it can be challenging to separate them out and import them into their correct categories. There are workarounds available, but it is recommended to limit the amount of objectives each element is meant to take.

This situation occurs when planar objects are modeled perpendicularly inside a single category or Revit Family. Most often this is observed with mullions, fins, and overhangs projecting from a single plane element like walls or windows. This scenario causes the same issue as "generic models", where the plugin is unable to determine which element to select and export. The workaround is to separate the elements into different layers, or temporarily hide/disable any protruding geometry that would cause an error.

Happy Modeling!