Generally speaking, we recommend that models done in Revit stay in Revit and ElumTools is used to run lighting calculations. The reasoning behind this is that Revit models are complex and there is often little to nothing that can be done (not a timely manner anyway) to make them import and/or calculate quickly in AGi32. Sometimes there isn't any way at all to get a Revit model to calculate in AGi32.


Behind this complexity lies several things to consider with Revit models:

  • Revit allows for and in a way encourages every single part of everything to be modeled, even if many of those parts will have no bearing on lighting calculations. After all, Revit is not a lighting program and the lighting functions it does have are secondary, perhaps tertiary to the program's main functions.

  • Revit, like SketchUp and some CAD programs, internally model everything as a Polymesh. This isn't a big deal for the program that created the geometry and has processes built-in that will hide all the lines between the polygons forming a surface, but when that geometry makes its way to some other program, all that built-in "make it look good" functionality is gone and the true geometry behind it all is revealed. Polymesh is the "least-accurate" form of geometry and relies on whatever program is reading it to create the polygons to form the surfaces rather than the full surfaces themselves being the only geometry present. Polymesh (or something similar) is necessary for curved surfaces but it isn't necessary for straight ones. This last bit ties into the next item as well.

  • Architects and engineers think in terms of solid walls, floors, ceilings, etc. as solid objects which are necessary for the physical construction of things but bad when it comes to things like running lighting calculations, which only need to consider the surfaces or parts of surfaces light will hit. Since the surfaces need to be broken down into smaller pieces to accurately evaluate how light plays on them, having present ONLY the surfaces the light will hit and having those surfaces as singular polygons (not Polymesh with multiple polygons) makes breaking down those surfaces for the lighting calculations easier and more accurate and doesn't necessitate calculating all the surfaces the light isn't (or shouldn't be) hitting. In other words, a rectangular "room" in AGi32 has 6, single-sided surfaces which are only 6 one-sided surfaces to break down, track, and calculate. On the other hand, a Revit model will have a minimum of 36 surfaces (with each wall, the floor, and the ceiling constructed using a 6-sided, solid object), every surface is double-sided (because it is an object) and worst of all, the surfaces are formed by Polymesh polygons (unless the program evaluating them, AGi32 in this case, was able to merge the polygons during import) which means that there are likely more than 6, double-sided surface for each of the 6 objects making up the walls, floor, and ceiling. The best-case scenario here is 6 objects each with 6 double-sided surfaces which is 72 surfaces to break down, track, and calculate.

  • Revit allows for entities to be automatically "subtracted" from other entities but isn't always that good about how the geometry ends up being formed. Take, for instance, a door placed in a wall. The door should remove the portion of the wall where the door occurs but if the wall itself drops even a little bit below the door, into the floor, or the door itself doesn't completely meet up with the bottom of the wall, there will be a "sliver" or "isthmus" of surface area left on the wall where the door didn't completely cut through the wall itself. Internally, Revit knows how to handle this scenario but when a program like AGi32 tries to evaluate the surface, there can be problems with the sliver of surface area left between the door opening and the edge of the wall in that the actual area of the sliver is mathematically zero. When a surface containing a part that has no surface area is evaluated, it will usually render the model incalculable.

The items above list only some of the potential problems with bringing Revit models into AGi32 but hopefully this information is enough to substantiate the position that Revit models should remain in Revit and not imported into AGi32. If it is necessary to bring models into AGi32 from Revit, here are some things to consider:

  • Export as little 3D geometry as possible from Revit. It typically isn't possible to export only what is vital to running lighting calculations but one should try to achieve this goal.

  • Export the 3D geometry as ACIS Solids, NOT the default Polymesh. The PDF attached below contains information on how to export geometry from Revit as ACIS Solids.

  • If possible, open the DWG file in AutoCAD and delete and/or simplify as much as possible to further reduce the model to only what is necessary for the lighting calculations.

  • During import, if there are any Layers containing entities that don't need to be imported, deselect those Layers so the data isn't imported. This is something that can be done in AutoCAD, too, by disabling the Layer(s) while editing the DWG file.

If the geometry fails to import it is probably because the model contains too much geometry for AGi32 and/or small geometry that can't be correctly converted. If the model does import, the very first thing to do is try opening the model in Render Mode. If the model won't open in Render Mode, it won't calculate and there isn't any point in putting in a bunch of work to find out later the model won't calculate. In cases like this, the problem usually comes down to further simplification of the model or that there is "invalid" geometry somewhere (or many places) in the model. Invalid geometry can be "slivers" of a surface between an opening and the edge of the surface, geometry that backtracks on itself, and geometry that folds over on itself. All of these are relatively common when it comes to Revit-exported files and the likelihood for problems is even greater if the geometry is Polymesh (hence the reason for exporting geometry from Revit as ACIS Solids).

Keep in mind, too, that the geometry exported from Revit is "heavy" and contains a LOT more geometry than what actually needs to be calculated. Massive simplification of the model will help avoid problems, speed up the calculation time, and make it "easier" to track down "invalid" geometry if the model contains such geometry. That said, tracking down invalid geometry can not only be challenging and time-consuming but there are cases where it is impossible to track down the problem and all the time spent trying to do so ends up being for naught.


Lastly, whenever possible, we recommend that Adaptive Subdivision is enabled in AGi32. This function breaks down geometry where light levels are changing and can help eliminate "light leak" (light transferring across large surfaces, under, over and around other surfaces from one room to another). This is a common problem with Revit-imported models as oftentimes there are large floor slabs, ceilings, and walls that cross from one "room" to another. However, breaking down surfaces into smaller pieces in an effort to reduce light leak requires RAM. Since Revit models are typically heavy, there usually isn't enough RAM to enable Adaptive Subdivision and calculate the model. Sometimes further simplification can free up resources but most of the time, Adaptive Subdivision cannot be enabled. AGi32 is a 32-bit program, meaning that it only has access to a maximum of 2GB of the system's available RAM. ElumTools does not have this limitation, and therefore has access to more RAM and has Adaptive Subdivision enabled by default. This will allow for better renderings, possibly more accurate calculations, and a reduction or elimination of light leak. This is yet another reason to run lighting calculations with ElumTools, inside Revit, rather than exporting to AGi32.