ActorDesc having wrong bounds for child actors using absolute transform

Development World Creation
, ,
1

This question was created in reference to: [Actor bounds is invalid in World Partition [Content removed]

I noticed the child actor’s wrong ActorDesc transform makes the cluster bounds super large and pushes the cluster to always loaded cell, and my local fix was to add a WorldPartitionActorDesc::NAME_AbsoluteRootTransform descriptor property:

  • Init stamps it when the actor has a parent actor and anyroot axis is absolute. The value names the axes: “L” location, “R” rotation, “S” scale, concatenated (e.g. “L”, “LRS”).
  • UpdateActorToWorld composes as before, then copies the absolute axes straight from ActorTransformRelative, mirroring CalcNewComponentToWorld_GeneralCase. The legacy bHasValidRelativeBounds == false branch needs the symmetric treatment so the parent is not divided back out of an absolute axis.

Then I found the referenced thread and think I’d like to backport Epic’s fix if possible, however I wonder if there’s a potential pitfall in that fix: since it’s using ActorTransform.GetRelativeTransform(AttachParentActor->GetActorTransform()) to compensate for parent transform, I will unconsciously break child ActorDesc again if I move and save only the parent actor but not the child actor, since the child actor is using absolute transform, they don’t get dirtied when I move the parent actor, so this feels error prone.

[Attachment Removed]

2

Steps to Reproduce
Same with [Actor bounds is invalid in World Partition [Content removed]

[Attachment Removed]

3

Hi!

You are right, and dirtying children when moving the parent would break some editor features (particularly if the child is unloaded).

I’m putting a fix up for review. Basically, the issue is that abs-flags were not saved in descriptors, so it is not possible to compute the right final transform from descriptors only. The fix is to save those flags; unfortunately, it requires a new branch version for serialization to work as actor descs are not uobjects.

[Attachment Removed]

4

Hi again, I was able to submit a fix for UE6 in CL 56599798. However I ran into a serious conflict when merging it back to 5.8, but won’t have time to fix it properly for around 2 more weeks (vacations).

I would advise against just merging the fix for your branch because if you update FortniteMainBranchObjectVersions.inl or use another one of the branch version enums, you will run into major problems when merging future versions of the code that also upgrade these version numbers.

[Attachment Removed]

5

Hi, I was able to merge into //UE5/Main, CL 57633010, if you run into issues with your fix.

[Attachment Removed]

6

Thanks for confirming it! I’ll just use AddProperty to save the abs flag in our project for now and wait for the official fix then!

[Attachment Removed]

7

thanks for the update! I’ll stick to our own fix for now and probably won’t back port the official fix unless we notice any new issues, and we’ll be very cautious about porting UE6 changes in general.

[Attachment Removed]