- If there is some material that do not find a match, those materials will stay in the imported order. The import will output a log message saying the material names do not match.
- If there is less material in the hires mesh description, the import will create empty section in the hires mesh to ensure the order of the materials. No log message will be output in that case.
-If there is more material in the hires mesh description, the import will transfer extra material section triangle to the first valid hires material section data (i.e. this should be matching the LOD 0 first material section)
We do this reorder when we import a hires nanite mesh and also if we have already a hires mesh description and we re-import the LOD 0 base mesh. This ensure we always have the hires meshdescription materials in the same order of the LOD 0.
#jira UE-179144
#rb jeanluc.corenthin
#rnx
#preflight 6426fd09c463fac9c8833dcd
[CL 24876565 by alexis matte in ue5-main branch]
Highlights:
* Only allocate and use a wedge map for non-Nanite LODs, or if the mesh is sub 300kindices and it will be cache optimized
* Only allocate and use a remap if there are no overlapping corners
* When the Nanite landscape mesh is created, we now ensure the mesh description is fully compacted, computed, and optimized prior to committing it, along with making sure there are no overlapping corners.
* Since Nanite landscape is checked to ensure no overlapping corners before the build, we can also now skip computing the overlapping corners, which was an intense number of tiny allocations.
* When Nanite landscape is being built as a static mesh, we now avoid super expensive temporary copies of the mesh description, knowing that no actual mutation will occur.
* The original code (after building) would release the memory from the mesh description copy, but it would not release the original immutable cached copy from memory (now that is released too)
* Fixed NaniteLODIndex incorrectly creating a mesh description at a LOD other than the expected 0
* Removed a full loop over all vertex positions by calculating the bounding box while we're building the vertex buffer (and already processing every vertex)
* Added a NeedsCompact() helper to MeshDescription to avoid expensive and unnecessary Compact() calls that do lots of reallocs/copies even if the mesh description is already contiguous\packed in memory.
* Skip building distance field and mesh card representations for the Nanite landscape mesh, which also avoids more cached mesh description deserialization and copies into memory.
Note: In the near future the APIs around this wil be cleaned up further.
#rb richard.talbotwatkin, yuriy.odonnell
[FYI] zousar.shaker, brian.karis, rune.stubbe, juan.canada, danny.couture
#preflight 640b7390482188d710464d39
[CL 24601442 by graham wihlidal in ue5-main branch]
Rollback cl 21484193.
In CL 21484193, DPosition1 and DPosition2 were normalized to avoid a null normal in case of very small triangle. This was done without taking care of the computation of the tangent and binormal.
Tangent and binormal have to be aligned on the UV map.
Normalizing DPosition1 and DPosition2 breaks the relationship between the dimensions and the UV of a triangle. The calculation of the tangent is therefore false.
The use of a square threshold is sufficient to avoid null normal (CL 21484193).
#preflight 63fd0c4c60163ed3c25261ce
#rb jeanluc.corenthin
[FYI] MarcAndre.Lalonde
[CL 24432682 by david lesage in ue5-main branch]
* Use FMatrix as the conversion to FTransform can't handle non uniform scaling
#rb patrick.enfedaque
#preflight 63f7bb45dd78dd50f60568bb
#tests built HLOD for Asteria, no more floating pieces (a few neon signs were using ISMCs with non-uniform scaling)
[CL 24397797 by sebastien lussier in ue5-main branch]
* When packing UVs, avoid relying on the UV area to scale triangles in the UV map. Instead, use the edges length (perimeter)
[CL 23130087 by sebastien lussier in ue5-main branch]
[FYI] Steve.Robb
Original CL Desc
-----------------------------------------------------------------
TMap and TSet can now be declared as members with forward-declared key and value parameters.
KeyFuncs::KeyInitType and KeyFuncs::ElementInitType typedefs are no longer used and user-defined KeyFuncs do not need to provide them. Deprecated placeholders for these typedefs exist though they may not be defined exactly as they were before. A new KeyType typedef needs to be provided by custom KeyFuncs which don't already inherit from BaseKeyFuncs or TDefaultMapKeyFuncs.
KeyConstPointerType, KeyInitType, ValueInitType and ElementInitType typedefs have been deprecated across TMap, TSet and TSortedMap. Regular C++ parameter-passing semantics should be used instead (const T& Ref or T Value, depending on T).
Added missing FSetElementId::operator!=().
[FYI] steve.robb
#rb james.hopkin
[FYI] henrik.karlsson
#preflight 635a56c15d49a96f7b31938f
[CL 22850782 by graeme thornton in ue5-main branch]
KeyFuncs::KeyInitType and KeyFuncs::ElementInitType typedefs are no longer used and user-defined KeyFuncs do not need to provide them. Deprecated placeholders for these typedefs exist though they may not be defined exactly as they were before. A new KeyType typedef needs to be provided by custom KeyFuncs which don't already inherit from BaseKeyFuncs or TDefaultMapKeyFuncs.
KeyConstPointerType, KeyInitType, ValueInitType and ElementInitType typedefs have been deprecated across TMap, TSet and TSortedMap. Regular C++ parameter-passing semantics should be used instead (const T& Ref or T Value, depending on T).
Added missing FSetElementId::operator!=().
#rb james.hopkin
[FYI] henrik.karlsson
#preflight 635a56c15d49a96f7b31938f
[CL 22810695 by steve robb in ue5-main branch]
