Automatic remeshing in Energy3D for solar analysis

A headache in the practice of simulation-based engineering or computer-aided engineering is the incompatibility of the meshes used to create and render structures (let's call them the drawing meshes) and the meshes needed to simulate and analyze certain functions (let's call them the analysis meshes). This incompatibility stems deeply from the fundamental differences in computer graphics for visual rendering and computer simulation for physics modeling.

When importing a model from a CAD tool into a simulation tool, engineering analysts often have to recreate new analysis meshes for their computation, which requires fine-grained discretization such is in the case of finite element analysis and other methods. It becomes a nightmare when the conversion from the drawing meshes to the analysis meshes can only be done manually. Even if only a few drawing meshes need to be taken care by hand while the majority of the meshes can be converted automatically, the analyst still would have to check all the meshes to make sure that every mesh is good for simulation. So we really need a tool that can deal with all sorts of scenarios. And this kind of tool is by no mean easy to develop.

Mesh incompatibility was (and may remain for a long time) a problem for Energy3D when it imports structure models created by other tools such as SketchUp. For example, in most architectural CAD models, a structural element such as a wall or a roof (or a part of them) is represented by two planar meshes that have exactly opposite normal vectors, representing the interior and exterior surfaces, respectively. These two meshes have identical coordinates for their vertices, though the orders of their definition are different (one goes clockwise and the other anticlockwise in order for their normal vectors to be exactly opposite). Whatever they represent has therefore no thickness, but with the two faces, we can apply two different textures to them so that the viewer can tell if they are looking at its interior or exterior surface.

While this sounds good to people who use such models in 3D games, it spells troubles to Energy3D. The first problem is that it increases the number of vertices that Energy3D has to load and, therefore, the memory footprint of such models. In a physics simulation, a structural element without thickness is meaningless. If we don't really need the two faces in most cases (we do in some other cases, but I will skip that line of discussion in the article), why bother to import them in the first place? Despite spending days on researching on the Internet and checking the Collada specification, I couldn't figure out how to force SketchUp to export only the exterior meshes (SketchUp's Colloda export function does provide the option of exporting two-sided faces or not, but it sometime exports only the interior sides for some meshes, mixed with exterior sides for others). So it occurred to me that I had to deal with them in the Energy3D code.

If we don't treat them and use the meshes as they are, we then have the second problem: which mesh should we pick to be the side that receives solar radiation? While it is self-evident which mesh of the two identical ones faces outside when we look at the 3D model after it is rendered on the computer screen, we absolutely have no way to tell from their coordinates alone in our code. Somehow, we have to invent an algorithm that simulates how people discern it when they look at the 3D view of the model on a computer screen.

Picking and choosing the right meshes, of course, is crucial to the correctness of the simulation results. In order to test the new algorithms in Energy3D, I selected the lower Manhattan island and the US Capitol Building as two test cases. The results of the lower Manhattan island have been reported in an earlier article. But the Capitol Building has turned out to be a harder case as -- with over 15,000 meshes -- it is geometrically more complicated and it has so many details that really put our code to test. After more than a week of my work on solving a myriad of problems, it seems that Energy3D has passed the test (or has it?). The screenshots of the solar irradiance heat maps of the Capitol Building from different angles show that severe anomalies are practically non-existent across the heat maps.


The heat maps occasionally suffer from a flickering effect called "Z-fighting" when two planar surfaces are visually close, especially when being looked at from a distance sufficiently far away. For the Z-fighting between identical meshes, this can be mitigated by increasing the offset of their distance. But, as this doesn't affect the simulation result, it is less a concern for the time being.

Automatic remeshing for solar analysis may also need to include automatic repair of models that contain errors. For example, some models may contain surfaces that have only one mesh with the normal vector pointing inward (this could happen if the original designer accidentally used the "Reverse Faces" feature in SketchUp without realizing that the normal vectors would be flipped). This kind of mesh is tolerated in SketchUp because it does not affect rendering. But they cannot be tolerated in Energy3D because such a single-face mesh with a north-pointing normal vector, which appears to the viewer as south-facing, will show little to zero solar radiation when the sun shines on it. Luckily, due to the visualization in Energy3D, we can quickly spot those incorrect surfaces and fix them by reversing their faces manually. But we will need to find a way to automate this process (not easy, but not impossible).