If a in-game mesh have a maximum of 100k triangles, the HLOD generation should start the approximation with 100k triangles no matter what the source MeshDescription is
Steps to Reproduce
We found late in one of our projects that the HLOD generation process for generated meshes use the raw MeshDescription and don’t use any Nanite Settings in the process. The HLOD process would be super long because we had meshes with a lot of triangles
in the source asset. We never limited the about of triangles because Nanite take care of everything normally. It also caused issue when exporting to USD for some external software (ex: Maya)
If we have MeshA with 1 millions triangle with KeepTrianglePercent of 10%, in game it will be a mesh of maximum of 100k triangles
If we have MeshB with 100k triangles with KeepTrianglePercent at 100%, , in game it will be a mesh of maximum of 100k triangles
But MeshA will have a much better looking HLOD than MeshB since all the mesh processing use the MeshDescription, we can’t do any geometry processing with Nanite. So all our HLODs depend on what the artist decided to put in the source asset.
The HLOD quality were changing drastically based on the density of the source asset.
It was even possible to create a HLOD actor with more resolution that the in-game mesh.
The issue is that GenerateApproximationMesh in ApproximateActorsImpl.cpp use the MeshDescription and there’s no limit how big they can big since it’s directly linked to the source asset.
Each entry in FMeshSceneAdapter have a copy of the FMeshDescription (see FMeshDescriptionTriangleMeshSurfaceAdapter). If we have 100 rocks with 1 millions triangles, that’s 100 millions we need to process. All the mesh processing use MeshDescription, Nanite doesn’t exist. Also each approximate actors have a maximum of 50k triangles (Simplifier.SimplifyToTriangleCount(50000)), it seem that mesh with the most triangles get prioritized, that’s why rock in general look better.
Hi Mathieu, there is a setting that you can use to have LOD0 Render Meshes (or Nanite Fallback meshes) used instead of Source Mesh Data - bUseRenderLODMeshes in FMeshApproximationSettings
/** If true, LOD0 Render Meshes (or Nanite Fallback meshes) are used instead of Source Mesh data. This can significantly reduce computation time and memory usage, but potentially at the cost of lower quality output. */ UPROPERTY(BlueprintReadWrite, EditAnywhere, Category = PerformanceSettings) bool bUseRenderLODMeshes = false;I think that might be what you’re looking for?
On that project it was not a viable solution since we couldn’t use the fallback meshes, their reduction settings were too aggressive because of memory issues we had.
Hi Mathieu,
I created a public issue for this - Unreal Engine Issues and Bug Tracker (UE\-307108)
It should be up once approved.
While not ideal, there’s an option in 5.6 to get rid of the fallback meshes at cook time, so that you aren’t paying for them if they are not used. Maybe that could help you for those meshes ?
Regards,
Sebastien