vertex normals are not calculated correctly on the skin mesh and morphs
Hi ,
Unfortunately this seems to be an issue on Autodesk’s end with FBX. Currently normals are not exported with FBX files. At least that’s the current state of the but that I entered for this a while back(UE-19861) and my testing seems to support it.
Ability to add a morph target with normals inside the engine? Possibility of recalculation normal morphs? This functionality inside the engine would be very useful for developers.
I spent a little test, created by morph target with custom normals. And 3d editor does not make changes in the normal, only the change in vertex positions. I am not aware algorithm for calculating normals, but they are not exactly taken with morph targets. I still think that this is a bug unreal, and FBX nothing to do with. Am I correct or wrong?
morph custom normal test video
Hi ,
Give one of your morph targets reversed normals. Try exporting your mesh to fbx and then re-importing it into 3dsMax. Manipulate the reversed morph target and see if it shows the custom reversed normals. From my experiments and talks with engineers, this is an issue where FBX does not send along normals for morph targets/blendspaces.
Right, FBX does not support custom vertex normals on morph-target model, but the 3d editor does not support them. I just wrote about this in a previous comment. Perhaps it would be a nice feature but not required for this task.
From my experiments with geometry attached in the first comment should be: Inside the engine the normal model with the morph, in a bind pose visually coincides with the normal to the editor, there is a visible difference when you play the animation. Also, I tried to import the model back into 3DS Max, any problems with the normals I had not seen, normals are exactly the same as the intended.
therefore - the normal morph geometry match until the model is in a bind pose, after which the skin shader should be all incoming data for bone transformation matrices (vertex coordinates, bone influence and the normal has with Morpher), but something goes wrong .
Theoretical results must match the result in the editor (as the initial data are the same) but this is not happening.
Throughout this chain for me it remains unclear the calculation of the normal for morph. The fact that changes morph vertex normal and the editor and unreal. Theoretically, the normal should always be tangent space. But the small difference between the editor and the unreal is still there.
I’m not sure, but I think it’s a mistake in the calculation of the normal vertex inside skin vertex-shader.
(I try to check that translates “on Google Translate”, so I apologize if there are any inaccuracies.)
Hey ,
After some further investigation, I see what you mean. Maya/3dsMax handle the normals correctly (even from just the fbx), but manipulating them the same way in UE4 causes unexpected normal orientation (sometimes even reversed normals). I’ve reported this as UE-33456, but I noted some similarity to UE-19861, which reports that Morph Target Normals do not behave correctly when the Maya Blendspaces have locked normals.
Hi
It was improved by fiddling the source of the engine.
A normal can’t be taken out in MorphTarget.
But when it’s a model of an element, a normal is stocked.
Using this, I twiddled a source of an engine and dealt so that a normal might be merged.
The detailed explanation was written in JapaneseSection, there are no responses yet.
There are circumstances, but it is impossible to put an image with improved source was post mounting method to JapaneseSection.
We want you to contact the Japan of Epic support if necessary.
Thankyou.
Hi yuu,
Have you tried submitting a pull request on github? I’m going to try and get our Japanese Support to take a look at your other thread.
Thank you for posting a possible solution.
Hi
OK.
Not be able to submit from yourself now if there is a situation.
So permission to submit to github, make sure the team.
Allowed in will soon submit.
It takes a little time.
Thank you.
Hi
It was submitted to PullRequest today.
Since wearing the image of the test results to the link destination, it is also seen once the results.
Thank you.
, I see that UE-19861 is backlogged right now.
Is there an alternative fix? Did yuu’s above solution make it in? It wasn’t clear on what it was exactly.
I’ve contacted Autodesk about FBX’s storing a morph’s normal information. But it doesn’t sound like that’ll be in a new FBX plugin anytime soon.
An idea: an alternative fix that is DCC driven, is to possibly allow users to manually import morph targets outside of the initial skeletal mesh.
Users would export/import to Unreal their base skeletal/static mesh from the FBX as usual. But from the DCC they would also export the morph target with the unique normals each to a separate FBX. In UE4 they’d then import the morph target FBX’s with the unique normals one by one (or batched).
It’s suboptimal, but it’d be a reliable method and option for those wanting to import unique normal data for each morph target.
I’m currently doing a lot of correctives that involve full translate/rotate/scale of joints and the normals on the morphs need some serious correction themselves.
Hey ,
The problem with importing morphs outside of the initial import is that it isn’t really a sustainable system if you ever update your mesh down the line. It’s too many variables and data files when you get into meshes that have dozens, sometimes hundreds of morph targets.
I’ll poke this ticket again in internal comments.
I’ve made a comment on UE-33456 to see if it gets any response
Why not recalculate the normals for changing the value of the morph in the tangent space of geometry before the geometry begins to deform by the skin modifier (), just as it happens in 3d editors?
In the bind pose, we recalculate the normals for the morph (GPU?), Then we deform the skin.
PS:After some verification it looks like it is already happening but not like in 3d editor.
Possible 3 options:
The skin improperly transforms the normals.
The morph is incorrectly transformed into a normal.
both
https://issues.unrealengine.com/issue/UE-33456
I do not understand why the error does not require correction?
The behavior of the normals does not correspond to their behavior in the 3d editor.
Because of this, it is impossible to accurately predict the behavior of the normals in UE4
In particular when using a combination morph + skin animations
I seem to understand that the GPU morph targets calculates the normals for some other algorithm … not the same as the CPU
And I would like to understand is this a bug for the GPU morph normals calculation?
And it is intended for static geometry? (Because with skin geometry behaves unpredictably)
Or it is a normal behavior?
(ue4.16.2 )
Any news? I tried the proposed fix - check gpu recompute tangents in settings - but it doesn’t seem to fix anything. Moreover, I have a mesh that should be imported with normals and tangents, importing normals only and recomputing tangents makes it look strange (another bug?).
This is something that Arc System Works and several other anime game companies have clearly solved, as they use custom normals and morph them flawlessly. It appears as if their meshes transfer the normals from a proxy that doesn’t deform. Is this something that is possible in UE4? Can the team at epic reach out to Arc System Works for an explanation?
1 Like
Have there been any developments?