GroomAsset cards/meshes ImportedMesh is not marked editor-only, so every hair-cards source StaticMesh ships in cooked builds

FHairGroupsCardsSourceDescription::ImportedMesh and FHairGroupsMeshesSourceDescription::ImportedMesh are plain UPROPERTY(EditAnywhere) TObjectPtr<UStaticMesh> members.

Every read of either pointer in the engine is already behind #if WITH_EDITORONLY_DATA, and FHairGroupsCardsSourceDescription::GetMesh() explicitly returns nullptr in a non-editor build, so the data is editor-only by intent.

But because the UPROPERTY itself is not declared inside a WITH_EDITORONLY_DATA block, the reference is harvested into the Game dependency at save time.

The cooker therefore pulls every hair-cards / hair-meshes source StaticMesh into the build, where it can never be read.

On our project that is 483 StaticMesh packages and 122 MB of cooked payload on Windows (218 MB on PS5), a 39% overhead on top of the groom assets themselves, for geometry that is already baked into FHairCardsBulkData inside the GroomAsset. The meshes are also hard-imported by the cooked grooms, so they load at runtime — measured at 869 KB resident per mesh in a packaged build, 868 KB of it video memory, plus a UBodySetup that is genuinely constructed.

We would like this fixed upstream rather than carried as a local engine patch.

The clearest signal that this is an oversight rather than a design choice is that the engine already treats the field as editor-only in two places while leaving the declaration unguarded:

FHairGroupsCardsSourceDescription::GetMesh() is written as

#if WITH_EDITORONLY_DATA

return ImportedMesh;

#else

return nullptr;

i.e. the accessor already assumes the member does not exist outside the editor.

GenerationSettings, thirteen lines below ImportedMesh in the same struct, is wrapped in #if WITH_EDITORONLY_DATA.

So the change we are proposing mostly makes the declaration agree with the accessor you already ship.

Here is our fix:

[Image Removed]

[Image Removed]

[Image Removed]

[Attachment Removed]

Hi Dan,

Thank you for reporting that. This makes sense. I prepare a CL for this. I will keep you posted once this is checked in.

/Charles.

[Attachment Removed]

The fix was checked in CL 58260591 in our mainline.

Thank again for taking the time to report this!

/Charles.

[Attachment Removed]