When developping a realtime 3D application, keeping a smooth framerate is an obligation.

The framerate can easily go under 60 FPS when dealing with CAD data, as such models can have very complex topologies, which means a high number of polygons, but also a high number of parts and materials, which translates to a very high number of drawcalls.

Reducing the polygons count

When importing a 3D models using PiXYZ, a very generic optimization process is executed. This process can be tweaked using Import Settings, for instance to control the overall quality of the imported meshes.

This setting will rely on tessellation or decimation alorithms (depending of the nature of the model) to lower the number of polygons until the quality level is reached. Is is also possible to have several levels of quality per mesh by generating LODs at import time.

If the polycount is still too high after importing the model, there are several possible strategies, depending on your usecase. These operations can be done manually using the Toolbox or made completely automatic using the Rule Engine.

The most common way to reduce the polycount is to decimate meshes to a certain quality or target (ratio or polycount).

This will work up to a certain limit, after which the geometry will get too damaged.

Another option is to remove inside geometry. This is very efficient if the models have been modeled as solids or have internal parts, that are not visible from the outside.

Retopologizing can also be a great way to reduce polycount as a baked normal map will mimic slight surface changes without the need for polygons.

Reducing the drawcalls count

While the impact of  number of polygons is easy to understand as it diretly affect the framerate in an almost linear way, the way drawcalls affect performances is trickier. In simple terms, a drawcall is a command issued from the CPU to the GPU. It's a command the computer sends to the graphics processor to draw something on the screen. As the CPU and GPU aren't made for the same purpose, they only briefly talk together for issuing commands during the rendering of a single frame. The more time is spent sending those commands, the less time the GPU has to execute those commands in the remaining frame time. This is why we always try to have a low number of commands or to "batch" several commands in a single one.

Unity has a number of builtin features to optimize the number of drawcalls (Static Batching, Dynamic Batching, GPU Instancing, ...), that works well in a number of cases, especially for games where the same objects are often instanced multiple time. In the industry, the number of different objects (or "parts", to be more specific) is much higher, and Unity is often unable to batch these drawcalls efficiently.

ECS (or DOTS) will improve performances by simplifying memory layout and allowing more effective code compilation, but it won't fix such drawcalls issues, even if it can heavily leverage GPU instancing.

Merging is the easiest way to batch drawcalls, but it will flatten the hierarchy. You can merge at specific levels using the Rule Engine to only merge sub assemblies that can be considered as a whole. However, if your assembly mainly consist in a lot of instances of the same object, merging will destroy instances and might not be that much beneficial.

Retopologizing is also a great option as it will reduc meshes and material drawcalls on top of reducing the polycount.