x

Search in
Sort by:

Question Status:

Search help

  • Simple searches use one or more words. Separate the words with spaces (cat dog) to search cat,dog or both. Separate the words with plus signs (cat +dog) to search for items that may contain cat but must contain dog.
  • You can further refine your search on the search results page, where you can search by keywords, author, topic. These can be combined with each other. Examples
    • cat dog --matches anything with cat,dog or both
    • cat +dog --searches for cat +dog where dog is a mandatory term
    • cat -dog -- searches for cat excluding any result containing dog
    • [cats] —will restrict your search to results with topic named "cats"
    • [cats] [dogs] —will restrict your search to results with both topics, "cats", and "dogs"

skin mesh + morph = broken normal

vertex normals are not calculated correctly on the skin mesh and morphs

skinmorphbugFBX.zip youtu.be/37e_8NPHQkU

Product Version: UE 4.12
Tags:
skinmorphbug.zip (93.4 kB)
more ▼

asked Jul 08 '16 at 11:00 AM in Bug Reports

avatar image

Sn_a_ke
147 9 16 20

(comments are locked)
10|2000 characters needed characters left
Viewable by all users

1 answer: sort voted first

Hi Sn_a_ke,

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.

-Matt W.

more ▼

answered Jul 11 '16 at 08:57 PM

avatar image Sn_a_ke Jul 12 '16 at 07:49 PM

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.

avatar image Sn_a_ke Jul 13 '16 at 05:53 PM

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

avatar image Matt.Williams Jul 18 '16 at 04:29 PM

Hi Sn_a_ke,

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.

-Matt W.

avatar image Sn_a_ke Jul 18 '16 at 05:52 PM

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.)

avatar image Matt.Williams Jul 19 '16 at 05:44 PM

Hey Sn_a_ke,

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.

-Matt W.

avatar image yuu Aug 04 '16 at 02:03 AM

Hi Matt.

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.

link text

Thankyou.

avatar image Matt.Williams Aug 05 '16 at 05:08 PM

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.

-Matt W.

avatar image yuu Aug 08 '16 at 08:42 AM

Hi Matt.

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.

avatar image yuu Aug 25 '16 at 03:13 PM

Hi Matt.

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.

link text

avatar image jmalaska Jun 07 '17 at 04:59 PM

Matt, 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.

avatar image Matt.Williams Jul 03 '17 at 07:49 PM

Hey jmalaska,

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.

-Matt W.

avatar image Sn_a_ke Jul 04 '17 at 02:55 AM

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

avatar image Sn_a_ke Jul 04 '17 at 05:38 AM

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? alt text alt text (ue4.16.2 )

avatar image Matt.Williams Jul 17 '17 at 09:07 PM

I've made a comment on UE-33456 to see if it gets any response

avatar image scha Jul 31 '17 at 12:18 PM

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?).

(comments are locked)
10|2000 characters needed characters left
Viewable by all users
Your answer
toggle preview:

Up to 5 attachments (including images) can be used with a maximum of 5.2 MB each and 5.2 MB total.

Follow this question

Once you sign in you will be able to subscribe for any updates here

Answers to this question