Before you begin, also check out the ideal Revit model for cove.tool workflow here. These two articles will be your ultimate guide to modeling in Revit.
List of problematic Revit Categories and Situations for the cove.tool plugin:
- Group Models - 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.
- Linked Files - Links in the Revit file can cause issues if the geometry the user is attempting to export is inaccessible locally. Because links are Revit's solution to connecting multiple models and teams together, geometry required for cove.tool may not be selected/filtered/exported because it is in actuality being held elsewhere. Since the plugin cannot access the elements, it cannot gather the information it needs to properly export your building geometry. This article offers a solution on how to incorporate a linked model into the central model. The most ideal situation will require the user to have have a local architectural model with the walls, windows, roof, floors elements accessible. Learn more on why this is the case in this article about Architectural vs Mechanical models here.
- Sloped floors - The plugin cannot collect sloped geometry for the Floors export because of the types of analysis which will need to be ran, once inside cove.tool. Daylight sDA% and Glare ASE% cannot currently be simulated on sloped floors, so these elements will not be picked up during export. A good work around is to change the items to the floor family as steps.
- Z-fighting - 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 occupy the same locations in space.
- Highly triangulated surfaces - 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 to collect the data needed to recreate a tree can be 30x more tenuous. Since the plugin will collects each plane of your model-view and records the surface area and coordinate position of every element, simpler geometry will make a faster process. Simplify geometry like context and shading elements by converting them into cubes of the massing-in-place command. Try to void irregular spheroid forms or other complex geometry as this will slow down the simulation while not increase accuracy.
Less problematic, but still messy:
6. Generic models - This describes the custom volumetric forms whose construction method vastly differentiates them from the rest of the Revit categories. These model types, are volumetrically constructed (extrude, blend, sweep, void) and thus have 3-axis dimensions. This makes it difficult for the plugin to collect simple single-plane geometry data which is used to make the analysis models inside cove.tool. Other Revit categories, although seeming volumetric, are all planar with various attributes applied to them (thickness, material, properties, etc). Since the information varies on which construction method used, the objects may still import properly. 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 be remodeled as a compatible object type with an area value.
7. Curtain Walls and Over-tasked geometry - The problems that can be created with curtain walls are less so about the family type, and more so 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 mixture of categories embedded into the element. User may attempt to model glass panes, spandrel panels, fins, and exterior wall all in the same layer. However it can be challenging to separate them out and import into their correct categories. There are workarounds available, but it is recommended to limit the amount of objective each element is meant to take.
8. Perpendicular elements embedded in a model - 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 work around is to separate the elements to different layers, or temporarily hide/disable any protruding geometry that would cause an error.