We’ve noticed an issue with our grooms, specifically with the LODDeformedRootPositions for each LOD of the grooms. Regardless of the curve decimation setting in each LOD, it has no effect on the size of the LOD’s DeformedUniqueTrianglePositionBuffer as this seems to be taken from the source groom itself (using RootCount directly). We noticed the issue when we had 50+ instances of a specific groom, and changing the LOD settings had no impact on memory cost. Shouldn’t the FHairStrandsLODDeformedRootResource/FHairStrandsRootBulkData take into account it’s LOD’s curve decimation property?
We found that changing the curve decimation setting in the groom’s interpolation settings does effect memory, but this is global for each group, rather than each LOD
The binding data are built once for all hair LODs of the same group. This is why you see it having no impact on the memory side when changing LOD. The curve count used during binding computation comes from the actual data used at runtime (it has to match). This is why you see a reduction when changing the curve decimation setting in the groom’s interpolation settings.
> We noticed the issue when we had 50+ instances of a specific groom, and changing the LOD settings had no impact on memory cost.
So yes, this would be expected, as again the root data are computed once for all LODs and shared at runtime.
Side note: If the skeletal mesh has several LODs, it will be compute also for each of these skelemesh LOD.