4.9 and 4.10 Set Morph Target not being sent to children of Inherited Mesh!

In previous versions of UE4, all you had to do to morph a model that was a child of the Inherited Mesh was to send that Set Morph target call to the Inherited Mesh and it would morph any children of the Inherited Mesh that shared that morph target name.

For instance, lets say I have a character model that has the Inherited Mesh set as the character’s body. Then I added the character’s head model and made it a child of the Inherited Mesh. In all previous versions, the method for morphing the character’s head would be to send the Set Morph Target call to the Inherited Mesh. The Inherited Mesh would then repeat that Set Morph Target to each of it’s children. All meshes that had that morph target name would have the morph value applied.

In UE4.9 that is not working anymore. This is a major issue that I would recommend hot fixing immediately.

Furthermore I can prove that this bug exists and if necessary I will provide a video demonstrating the bug.

I did some more investigating and I can confirm 100%, beyond a shadow of doubt that this bug exists. Created an entirely brand new project and reimported the models with morph targets. I then set up a new character model with a female body as the Inherited Mesh. I then added another skeletal mesh component (a shirt) placed it as a child of the inherited mesh (the body) and used Set Morph Target on the Inherited Mesh to set a morph value.

Both the female body and the shirt have a morph called “Weight”. Letter for letter, capitalization the same. Only the body is morphing, the children are not receiving the set morph target call. I’ll provide a video of this bug if necessary. This is so very game breaking to me that it is devastating so I’ll be very willing to assist in any way I can to help resolve this bug.

So, in order to assist with tracking and fixing this bug I have made a video proving the existence of this bug.

Please fix post haste.


It appears that 4.9 introduces few changes in order of execution when it comes to morphs, this inadvertently functionality to propagate morphs from master to slave skeletal meshes.

I changed SkeletalMeshComponent.cpp to read morph values from parent mesh (rather than parent’s animation instance) and this fixes this for me.

Github commit:

Thanks for the quick fix but I’m not going to mark this as answered as the bug does exist and it needs fixed in the release version. (On the plus side your answer may assist Epic in fixing the bug.)

Made a pull request for the fix – https://github.com/EpicGames/UnrealEngine/pull/1512

I can confirm that your adjustment fixes this bug. All they need to do is apply your fix to the release version and it’s all good. Btw, really man, thanks for the quick fix, this bug would’ve slowed production down big time. Gonna leave this ticket open though until someone at Epic acknowledges it.

Hi Nightasy,

Would you be willing to provide the files from your proof video for me to repro here? You can send via dropbox, google drive, or as PM to me on the . I realize xulture has a fix submitted via Github, but this may need to be looked at closer to make sure there are no other inadvertent effects.

Providing the proof file is not absolutely necessary, but it would expediate the process. Either way, thanks for bringing this to our attention.

Heya, i created tiny project with example. Red ball is ‘master’, yellow half-ball is ‘child’

With my fix, both morph correctly if you play the level. Without my fix, only the red ball morphs.

[Dropbox link

Dropbox - MorphTargetTest.7z - Simplify your life

Hi xulture,

Thanks for sharing the repro as well as submitting a fix via Github. I have used the project to file the following bug report addressing morph targets not being sent to the children of the inherited mesh: JIRA [UE-20781]. When this issue is addressed we will update this post to let you know.

Thanks again to both you and Nightasy for bringing this regression to our attention.

Still broken in 4.10

Yo, Epic, should I make another thread about this? Seems to have been forgotten.
This is a pretty big regression.

Also, this bug was NOT listed in the “known issues” for 4.10. Can we please get this regression recognized officially and then fixed asap? It’s a simple code fix? You change ONE LINE of code and everything magically works again.

The bug report that was previously listed as [UE-20781] had been previously reported as [UE-20602] which is currently still open and on the list of fixes to be completed. This issue has not been forgotten and, as I mentioned before, this post will be updated when the issue is fixed.

Oh alright then. I was just worried that it got lost somewhere. It’s a pretty nasty little bug that definitely needs attention. It prevents applying any morphs to anything other then the Inherited Mesh and that’s a major problem.

someone removed the github pages…ugh

No they didn’t. The pages are still there but you have to log into Github in order to see them otherwise you’ll get a page not found error.

Can anybody help me get to speed on this one please?
I read here that setting a morph target on the mastr mesh is NOT transferred to the slave mesh in 4.10 but in my view, this is not true. I have a body system that is divided into head and body with the body being the slave of head. I only set morphs on the head and they get propagated to the body mesh which is the slave.

However, I tried the previews 1 and 3 of 4.11 and in these versions, the morphs are NOT being propagated to the slave.

So I’m a bit confused. People post here that in 4.10 the morph is not propagated when in my opinion it is, yet now in 4.11 I see that the bug DOES exist and no propagation happens.

FYI I have reported a probably related bug [here which some of you may also have observed.

Morph Targets flicker Randomly in Slave Mesh - Rendering - Epic Developer Community Forums

@ - The issue most assuredly exists in 4.10 as well as 4.9. I have yet to test 4.11 and am actually downloading it now to check for myself. If it didn’t exist for you in 4.10 then what you had was a fluke. Ergo, you got lucky for whatever reason and the engine was letting you do it. Morphs do not propagate for anyone on the team I work with nor for anyone that I have had test it. The last known version of the engine in which morphs propagated to slaves meshes was 4.8 and since that version of the engine it has not worked.

Frankly I am aghast that Epic has not fixed this issue yet as it is most likely the foremost ENGINE BREAKER that exists. I don’t want to bash Epic (love the work you do) but come on guys, it’s been months and we already provided a fix RIGHT HERE in this very thread. It’d take you no time flat to implement the fix into the release. In my opinion, they could roll back every single change they have made since 4.8.3 and start from there without breaking morph propagation… the engine would be better off for it.

As an alternative to working around this bug our team had to go with using a scaling bone system for the body morphs and we completely abandoned the idea of separating the head from the body.

Thanks, that really sounds horrible. I built my character system completely on this morphing promise and I am not able to rebuild characters to use bones instead. For me, morphs flicker from time to time, especially when moving the mouse, I reported that as a separate bug and got a message from Epic that they suspect my bug was related to this one here and that it was fixed in 4.11P1 which I tried and that’s when morphs didn’t work anymore.
This is really a huge problem and if a fix was already provided by the community, I must say I am really amazed that it is still around, since it’ IS a big deal.

I confirmed. As of 4.11 preview 3 it is still broken.

The fix is still being evaluated to make sure that it does not conflict with existing code. I have increased user interest to the current bug report, JIRA [UE-20602] however, as our developers are currently extremely busy, I cannot accurately say when this problem is expected to be resolved.

As I’ve stated before, once it is resolved, I will notify all users interested in this fix with an update to this post.