USkeletalMeshComponent: Use protected instead of private to facilitate plugin development

Development Character & Animation
, ,
1

As a plugin developer providing derived implementations of USkeletalMeshComponent in a plugin format, we access to the internal data in the USkeletalMeshComponent. As this data is private we need to achieve this indirectly via pointers to the original data which is messy and brittle. This also leads to code duplication as any functions accessing this data must be modified trivially to change the way we the data is referenced. This leads to a cascade of code duplication which would not be necessary if the data and internal helper methods were categorized as ‘protected:’ rather than ‘private:’.

Using ‘protected:’ would reduce our maintenance burden and reduce the risk of missing an implementation update down the road.

Pull Request #13291:

USkeletalMeshComponent: Use protected for internal data and methods. by bricamer · Pull Request #13291 · EpicGames/UnrealEngine

2

Steps to Reproduce
This is a refactor that would facilitate external plugin developers. And should not effect the engine behaviour in any way.

3

Hi,

Thanks for the pull request! While we understand the needs around derived plugin classes, unfortunately its unlikely we can take the request as-is at the time of writing. This is due to a pending refactor that will realign the data access patterns of USkeletalMeshComponent (and USkinnedMeshComponent) quite significantly, mostly around threaded access to buffer-like structures that are processed per-tick. Making the various inner data structures effectively public API would complicate this undertaking so we would prefer to defer it to a later time. If however your needs are restricted to ‘settings-like’ members, e.g. internal flags that are not updated per-frame etc., then we could consider accepting a PR with a more piecemeal approach.

4

Thanks for your reply Thomas.

It makes sense to wait for this refactor to land before attempting to reduce complexity/maintenance burden on our side. Can you share any information about when this refactoring is planned for? Is there a place where we can keep ourselves informed?

5

We will likely be addressing it in the 5.7 timeframe, as work on the Witcher 4 tech demo has exposed some serious shortcomings in terms of thread safety when interacting with UAF, so to move UAF towards shippable quality we need to address it ASAP. As to keeping informed, looking at changes to SkeletalMeshComponent.cpp in GitHub is probably the best place?