All morph targets entirely mess up on small scale assets!

Imagine you have a mouse or a bug in UE4 with a few cm scale for a head, now try making morph targets work on that and you will notice they wont work or blend correctly, the vertices move but mess up, it’s as if every two or three vertices move while the others either don’t or they shift awkwardly, I suspect something with threshold is going all wrong.

It works perfectly fine in 3ds max, also works perfectly fine in Unity! As it almost always does :), sorry Epic Sometimes we collectively get pissed at the amount of bugs or shortcomings on basic and I mean basic features in this engine!).

Turns out scale is the issue, so the workaround now is to import all assets scaled up by at least 10 in the FBX Transform settings and then scaled back down again in BPs or editor.

I suspect its a standing problem, if any one out there has a solution then please share if not then hoping for a fix in the near future.

It’s a floating point thing.
The values get truncated below a certain precision, so the morph target becomes imprecise.

make your model bigger, scale it back down in engine - it still won’t be precise, but it might work a little better.

However, the only way to have it work right is to scale everything up.
if your project involves a lot of small things, just make the small things huge things and change the viewpoint/perspective.

Yes seems it is a floating point thing :), So devs at Unity 3d, Autodesk 3ds max, Maya, Zbrush, Blender all have it working, Yet a brand new re-written engine that just came out a few years ago needs a workaround.

This is exactly why things baffle me in UE4! 3ds max has single precision not even double and it works fine. Even Old Unity3d version 5 works just fine.

I have advice for the project manager at Epic, how about cutting down man hours spent on developing Raytracing and that Social media stunt of a feature “VR viewport editing” and dedicate more time on these issues first.

I mean this is the kind of stuff that many of us been complaining about for Epic to fix first, the very basics, before moving on to new ventures (not to mention the other morph issue with cloth sims being nonexistent but that is another matter), I hate to rant but I can’t help it here.

It is simply unacceptable in a production to start scaling things left and right or changing perspectives. Things need to be consistent. If I didn’t have that scaling option in FBX we would be in further trouble forcing us to take an even greater totally unnecessary workaround because there is no way we are going to touch our rigs which took days and weeks to make for each character.

For now as I mentioned we bring them into UE4 scaled up via FBX import settings after which we are forced to scale things back down inside UE4 after the import, which seems to fix the problem, but this is by no means a good solution in the long run.

A 3d program has WAY more resolution then a game engine can - it’s very simple math.
The game engine has to do a TON of things that a graphics program does not do. One of these things happens to be mathematical vertex precision.
The fact that it works in Unity is interesting, but it’s also part of why Unity sucks at graphics when compared to UE4. You end up using resources that are better spent elsewhere.

Regarding your issue and scaling. There is absolutely 0 problems scaling a whole rig in Blender, applying said scale, and having an exported FBX that is the exact size without having to leverage the import settings. Surely this is true for any other 3d software out there if it’s true for Blender of all things.

The question becomes testing how badly shrinking distorts in the end - it should not because calculations are performed before the shrinking - but you still have to test it thoroughly.

Another thing you maybe don’t realize is that you could pull the engine code, modify it, build it, and use a custom version of UE4 that does what you need - almost like every AAA game out there does in the end.

i do not think finding excuses for ue works here, i understand very well an engines limitations but this is not one of them. Proof unity works and i would bet you cryengine may work just as well.

also scaling a rig is not an option especially if your rig is anything decently complex for proper custom character animation. Also building scaling functions in the rig is a large task of its own and not recommended for most cases. I know because i have been rigging for 15 years. If a rig can be scaled in blender then it is either relatively a simple rig or a stock rig used for multiple purposes similar to CAT in max but start adding more functions and no.

the only way to scale it in that case is to scale the fbx export rig itself which i am already doing as a workaround.

lastly i disagree completely of unity being an inferior graphic engine its slowly proving to be the contrary just wait and mark my words when in a few years unity develops their visual scripting how indie devs will start flocking there. If you think it slows down something else in the engine then i believe the best judge of that is the dev not the engine, the engine should provide the options and we choose the compromise.

this is a problem in ue, again sorry no excuses i am raising it here becuase it is and causes headaches. If Epic cares fine if they dont we have to live with it and i dont have the resources to dig its core looking for solutions and most other indies don’t either.

There is a common “issue” when using 3ds Max where the object being edited can become out of alignment with how the object is configured with in the view port and the actual properties as assigned and generally show up once the object is moved out of Max and into another 3d application like unreal 4.

The most common issue is when editing scale using the “relative” scaling tool the actual local scale of the object does not adopt the changes made as a relative change to the size of the object that can cause all sorts of unusual problems such as strange morphing behaviour and improper results to physics based additions such as physics type lighting models, materials, or cloth based simulations.

Such alignment issues usually occur during the editing process and the cure is to simply force the object into it’s true state by applying a X-form reset available in the utility tab and has been common practice to make use of this utility once all editing requirements of the object has been completed.

Just a guess on my part but based on the original example is say we have a mouse the size of a pickup truck the usual edit behaviour is to use the relative scale tool to scale down the mouse to the proper size in the view port. With out using the x-form modifier or reset utility your only changing the scale of the object relative to world space but the relative properties stay the same as to the original local scale of the object as to it’s base size upon creation so not hard to see that morph target precision is going to be off.


thanks for trying to help, but ofcourse all assets are properly reset xformed pivot aligned to zero world etc. Otherwise our morphs and rigs wont work properly either, no the issue is 100% coming from how ue is handling morph vertex precision on small scale assets. The rig itself and meshes are perfectly fine in terms of their integrity and followed through with care.


If most of the indis can’t take 5 minutes to add or remove a 0 from a line of code to increase mesh paint and/or morph precision - it’s on them. Not the engine.
The code is there and it can easily be changed precisely because those issues exists.
it’s up to you - the developer - to actually develop…

1 Like

Most indies wont take 5 minutes to touch the source code because we both know it does not take 5 minutes to touch the source code, also it takes 5 minutes and less time to break the engine, it takes hours to build the engine after a change, it takes the same amount of time to do all this again and again with every single little update to the engine and then cross your fingers it doesn’t break again.

Also the source code is the least documented section of the engine. But I’m supposed to know it regardless because I’m a “developer”?

But if it does really take just adding or removing a zero from the code to make it work, then why isn’t this mentioned anywhere concerning this problem? Why isn’t it made aware or documented? why did we have to discover the issue half way through production, I just googled it and nothing came up, in fact no other posts came up about the issue to my surprise. That in itself is a problem is it not? If you do have a solution to the problem could you be kind enough to point what and where needs to be modified since it will just take you five minutes? (I really don’t mean to be rude).

My job is to develop, I already have a million things to change and add on a car and I have a team of two or three to get it done because I don’t have millionaires backing me, all I had asked from the company is to provide me with a working engine, that is all, I will invent the wheel change the gears and add the frames to the capacity and resources of my team that is the unspoken deal struck with Epic, Unity, Cryengine or any other real time engine when you start working with them for the ten percent (or more) they take from you when and if you make a return . Otherwise nothing will get done in a lifetime.

Make sure you have permission and access to github, pull the whole thing then

Line 231
const float MINWEIGHT = 0.01f;
const float MINWEIGHT = 0.001f;

Can’t guarantee that’s it, but I can guarantee that adding the 0 won’t break anything in any release.
I don’ t have a mesh that gives me this issue and I am indeed using a custom built engine to improve weight paint - which is what this line does. it makes weight painting more sensitive and limits issues arising from paint precision being trimmed when below .01 decimals.
Since I don’t have issues on morph targets I’m Assuming this also affects them and it is why I don’t see the issue. However since you never did share a file to test this is an assumption.

Pull the branch, make the edit. make a better game regardless.

Your nonsense about the source being undocumented is just that, nonsense. As you will see when you pull the cpp file above the code is commented - more or less accurately, but commented/documented nonetheless.
You have to read the code along with the comments to get what it does, just like every other code you ever run into? And I have to say, they really do try and keep the best commented stuff I have seen.

A legitimate question/feature request would be to expose the MINWEIGHT variable to the importer so that you can set it when importing each individual FBX. I bet you if you asked for it on answer-hub and posted the link back on here in a new topic you’d manage to get traction on it.

Thanks for taking the time trying to help, i really appreciate it.

Will try and look into this.

my bad for not providing a file yet just had no time, it would be better if i do yes.