Known issues and limitations ​

Empty LOD meshes after switching reduction module to Simplygon ​

The empty LOD meshes issue appear when you run Simplygon using the mesh reduction interfaces without an initialized Simplygon handle. When doing this, Simplygon will return an empty mesh which will then get stored in the Derived Data Cache (DDC). To fix this issue, please do the following:

1. Make sure you have set up Simplygon correctly. You can verify this by seeing that the Simplygon logo in the toolbar above the viewport has a little green checkmark (or potentially an orange exclamation mark if you only want to use one of the Simplygon reduction modules). If the icon has a red warning icon, please check the log and fix the issues. A common issue when this happens is that the plugin can't find the Simplygon license.
2. Flush your Derived Data Cache (DDC). This should trigger Unreal Engine to rerun the LOD generation.

Unreal 5 Launcher version ​

The plugin is not installed to the engine folder for the installer version of UE5. You need to copy the plugin into your project manually. This is mainly due to how dependencies for the launcher version of the engine are coupled into the UE5ModuleRules assembly.

Issues with HLOD after upgrading to Simplygon 10.3 ​

The new Simplygon Unreal Engine plugin includes major modifications to the HLOD system, which potentially can affect projects that are getting updated to the latest version. We've decided to migrate all HLOD functionality, in favor of usability, flexibility and performance, to proprietary HLOD builders. This also means that previous workflows through the standard interface and HLOD Outliner no longer are supported. The Proxy LOD module will live on for a while so that users can get informed that Simplygon will no longer be active in those case.

Projects that have had Simplygon enabled for Proxy LODs before upgrading, users will have to make an active decision to disable Simplygon's Proxy LOD module in the project settings, not doing so will result in an error during generation. Disabling this module will allow Unreal Engine's built-in / third party optimization modules to take over the optimization.

Simplygon's HLOD generation will, as of now, be done through custom HLOD builders, such as the SimplygonHLODRemeshingBuilder which is now selectable and configurable in any HLOD Layer.

As Epic is moving towards World Partition we are following in the same direction; non-World Partition worlds are directly affected by this decision and are no longer supported.

DDC related issues ​

We recommend that you flush your DDC (Derived Data Cache) when you've switched over to using Simplygon's LOD interfaces after having used Unreal Engine's built-in version. This is to make sure that no cached LOD data from before will override or interfere with Simplygon generated LODs. Once you are using Simplygon we recommend that you use LODRecipes to generate your LODs.

Loss in texture resolution ​

Simplygon currently relies on material flattening to pre-bake the Unreal Engine material into an intermediate material. This is done using the material flattening process. This results in a new set of textures that are then used by Simplygon during its baking process. Since both material flattening and Simplygon are using the same output resolution, which is usually lower than the source textures combined, this can results in slightly fuzzy looking textures if viewed at close distance. Ideally, material baking should be used for far away meshes.

New UV generation limitation when separating trunk and foliage ​

Currently, when using the Billboard Cloud Foliage Pipeline with the setting Separate Trunk and Foliage checked, the number of UV's on the source asset has to be less than MAX_STATIC_TEXCOORDS (where MAX_STATIC_TEXCOORDS is an engine constant, default set to 8). The reason for this is that these settings requires us to keep both the source UV's (for the kept trunk geometry) and generate a new set of UV's for the foliage part. These combined can't be larger than the maximum set of UV's allowed.

LODGroup to LODRecipe Conversion ​

LODGroup to LODRecipe conversion is not currently provided. However, with Python scripting available technical artist should have tools available to easily write a script to map LODGroups to LODRecipes.

Distributed processing progress ​

When using distributed asset building there is unfortunately no support for getting progress from FastBuild or Incredibuild. However, for Incredibuild builds you can use the monitoring application provided as part of the package.

Distributed processing in World Partition ​

As of now, only Simplygon Grid is supported when running distributed World Partition HLOD processings.

HLOD generation for Non-World Partition worlds is not supported ​

As Unreal Engine 5 is heading towards World Partition we've decided to follow in the same direction. The new HLOD builder exposes more functionality than the previous standard interface implementation and will offer users much more flexibility when generating HLODs. A limitation of this action is that non-World Partition world types are no longer supported. Moving away from the standard interface also means that generation of HLODs through the HLOD Outliner and the Simplification HLOD builder will no longer use Simplygon.

HLOD in combination with Landscape Culling and / or Work Distribution ​

There are some limitations in Unreal Engine's WorldPartitionHLODsBuilder and some of its code paths which prevent us from implementing a good work distribution system. To bypass those limitations we've implemented our own SimplygonWorldPartitionBuilder.

For a custom Landscape Culling implementation we also had to remove some filtering that was done in UHLODBuilder, to allow the data to get passed down correctly we've implemented our own USimplygonHLODBuilder class.

For these two features to work it is required to run the WorldPartitionBuilderCommandlet with the builder set to SimplygonWorldPartitionBuilder. Replace {ProjectPath} with the path to your project file (uproject), and {MapPath} with the path to the level (umap).

For non-async / non-distributed HLOD generation:

.\UnrealEditor-Cmd.exe {ProjectPath} {MapPath}
-run=WorldPartitionBuilderCommandlet 
-Builder=SimplygonWorldPartitionBuilder
-AllowCommandletRendering

For async / distributed HLOD generation:
(distribution needs to be enabled in Simplygon plugin settings)

.\UnrealEditor-Cmd.exe {ProjectPath} {MapPath}
-run=WorldPartitionBuilderCommandlet 
-Builder=SimplygonWorldPartitionBuilder
-Async
-AllowCommandletRendering

Note: This means that the Build HLODs dialog in the Unreal Editor does not support Work Distribution and Landscape Culling through Simplygon.

SimplygonWorldPartitionBuilder, Async and GetCustomHLODBuilderClass ​

There is a limitation in SimplygonWorldPartitionBuilder that prevents execution of builders requested by a component's GetCustomHLODBuilderClass. The request will not be delegated properly when running Async tasks and will therefore result in these components not being included in the HLOD generation. Landscape (as an example) implements the custom builder class function. Non-Async tasks will delegate the work to the requested builder(s).

HLODs are generated from Nanite fallback meshes as default ​

Our current export function exports what is provided by Unreal Engine; that means that when Nanite is enabled we will read (and export) the fallback mesh instead of the regular mesh, as that is what is provided by the API.

There might be cases where the fallback mesh is good enough as a base for HLOD generation, but there might also are cases where it is not. As the quality may vary depending on Nanite settings on a mesh, we've added a setting called UseSourceMeshData, which, if a mesh has Nanite enabled, will export the source mesh instead of the fallback mesh. Simplygon can not guarantee the quality of the HLODs when fallback meshes are used as source. Something to keep in mind when having UseSourceMeshData enabled is that million of triangles need to be exported and optimized, and may therefore require extreme amounts of memory, processing power and disk space.

Generated Stand-Ins does not get Nanite settings applied ​

Stand-Ins does not currently get any Nanite settings applied; this can affect the rendering performance in the Editor as well as memory consumption in cases where the generated mesh gets a large amount (Nanite-level) of triangles. An example of when this can happen is when there is at least one Near Stand-In that has multiple high-resolution Nanite meshes as source meshes.

Baked materials become magenta colored ​

If Simplygon is tasked with baking new materials, the materials will first be flattened. Sometimes the combination of texcoords and texture size results in low quality flatten results, especially when there are a lot of separated UV charts with empty space between them and the texture size is small. In the worst case no pixels are being sampled correctly and this results in an uninitialized magenta texture. In other cases there might still be missing samples but it won't be as noticeable since the full texture won't be magenta colored.

There is a plugin setting under Flatten Material called: Use Tex Coord Adjuster that adjusts the texcoords slightly to cover texel centers and improve the material baking especially for very small textures. The tool is described in more detail here: TexCoord adjuster

The flatten resolution depends on the output material settings and on the plugin settings under Flatten Material: Use Variable Texture Size and Min Variable Texture Size.

Limited support for World Position node in materials ​

Materials using the world position node are currently baked in object space. Any material variation that depends on where in the world the asset is located will unfortunately not be taken into account.