FBX and normals Import going very wrong!

Hi guys I created an answerhub post with an fbx test file and more images and it’s ongoing, I thought i’d post it here as well just in case someone can help out as we are struggling with this for almost 3 days now!

Would like to note that using morph target to drive the same animation pose instead of the rig does not produce any such problems.

Thanks.

Here’s the shortened version of the post:

Hello,

I’m facing a smoothing or normals issue after import of my skeletal mesh in UE4 causing dark patches. The animation is basically a blink of the eyelid, so you got a folded eyelid that would blink, its the folded areas when unfolded during the animation that are causing most of the trouble in unreal when they look fine in Max.

Everything is ok in max and the FBX file when imported back into the 3d app, all the smoothing and normals directions are fine but something in the import in UE is still going wrong as you can see from the normals directions. Tried all sorts of import and export settings. The mesh is fine no corruptions or other issues related to skinning etc. I’m pretty sure of this.

Also if i import the mesh with lid closed as static in Unreal the normals and smoothing seem to work fine. It appears to be only affecting skeletal meshes.

https://s29.postimg.org/by2ccf3ur/Normals_Max.jpg

https://s29.postimg.org/ryn2wg79v/Normals_Max02.jpg

https://s27.postimg.org/3ulqob12n/Normals_Unreal.jpg

https://s29.postimg.org/9mutjq69v/Normals_Unreal02.jpg

https://s30.postimg.org/rmtwtgdzx/FBXSettings.jpg

https://s23.postimg.org/xtmi8rznb/Normals_Unreal_Settings.jpg

https://s29.postimg.org/irckt76jr/Normals_Gif.gifgifs upload

The above Gif’s dark area is not shadowed just to illustrate the normals misbehaving.

Well to give a response that would be correct I/we would need a copy of the source asset as there are some fundamental requirements to insure the fidelity of the asset remains intact as there are things that 3ds Max does with in it’s own space that does not translate well to another space like UE4.

The use of smoothing groups for example is unique to Max which is a painted effect that makes an object look smooth across it’s surface as rendered in Max but when imported into a different app could render as blotching so the first thing I would check is to see if the object has more than one smoothing group assigned across it’s entire surface.

Another issue relating to asset editing is the tendency to make use of the scale tool and not realizing that all it does is changes the relative scale of the object as to world space and not to it’s local scale as to the size of the object as seen in world space. Since UE4 uses real world lighting models it can be assumed that lighting behavior on the object is based on it’s local scale which would be true to it’s size in local space which made transparent could be larger or smaller than intended. Standard practice if relative scaling to world space is to use the xform modifier or use the xform rest tool to force the visible object into it’s true state as well force the local scale of the object to it’s relative size.

Last tip is for cloth based objects, like a flag, quads is not the ideal build surface as due to it’s nature does not flex or allow lighting behavior to function correctly as it would on a static surface. A static surface is generally light as a stationary object where an object like cloth should be considered as being movable so it would be expected that lighting behavior would be different between a static and skeletal object but because of the topology lighting and shadowing is still going to be off.

Instead give Max’s Garment Maker a try as it does create a sub-divided surface that will behave a lot more natural with out having to increase the density of a quad object to get the same kind of behavior expected from cloth.

That’s all I can think of off the top of my head as to the things Max’s does but if the lighting and shadowing is strange then make sure that as a skeletal object that it’s type is set to movable as all skeletal objects should be considered movable objects .

Hello FrankieV,

Thanks for pitching in.

The source files in Max and FBX can be found in the mid section of the answerhub link if you can check it out.

The scale as far as i last checked is correct on this sample file (this is a small part of an eyelid, note the same issue exists on these eyelids with the whole head), i also always ensure these are correct and reset xform is applied at first ( there are no other corruptions or anything of the sort on the mesh). The object also has one smoothing group applied to all surfaces and as you can see I checked the normals directions to make sure they are correct, what is happening is that the normals are changing their direction as soon as imported in Unreal. For instance this does not happen when using a morph target doing the same unfolding movement on the same mesh from max to UE, only when its rigged and animated by a bone it does this. I think Unreal for some reason is not “Updating” the normals directions when the mesh unfolds with a rig during animation, it’s as if the normals are “Baked” in their initial open position during import and “Baked” Wrongly if that makes sense because in max i did another test trying to make sure the normals stay explicit during the eyelid close, but that didn’t work out either in the engine.
I imported the FBX file back into max and it works fine, nothing seems to be wrong with it.

I also tried triangulating the mesh in max and checking the normals again exporting it out and the problem is still there. It is not this mesh that’s the only problem it is any mesh that is folded like an eyelid or pinched that gets unfolded that is causing the issue.

So i’m kind of puzzled as to what it may be that’s causing the issue.

Edit: Including FBX and Max files here as well:

http://s000.tinyupload.com/?file_id=66160972481559841291

Update on this lovely adventure:

In Brief, so far i concluded that no matter what i do Unreal does not want to import proper vertex normals or smoothing group information from the outside FBX file created in Max. Doesn’t matter if you tell it to import normals or tangents none of that makes any difference it seems.
So what happens when you import a character with eyes open and later it is animated to blink without the pre-computed explicit normals in Max? Unreal calculates normals on reference pose frame 0 or 1 again from scratch and by doing so ofcourse it would create dark spots in folded places of the mesh such as the folded upper eyelid, because naturally the polys in that area would be pinched with normals facing various directions, so when the eyelid unfolds and the character blinks, you get to see the dark weird normals all over the place.

Workaround so far (its a horrible one), Import character with animation eyes closed as first frame pose, unreal will recognize the unfolded eyelids and calculate normals based on that pose, later when the character opens its eyes it will be ok since normals are already computed at ref frame 0.

This is of course very strange and not intuitive, I even asked someone to test things out form Maya just in case and all the same result. Will keep trying.

I hope someone out there or Unreal Devs can pitch in after the holidays for this, I will probably bump this thread up then, shamelessly because it’s been a week on this problem already with no solution so far.

Appreciate the help some of you guys have tried to pitch in so far.

Update 3 on this issue:

Received a confirmation about this issue from another user in answerhub, I wouldn’t be bumping this if i didn’t feel it needs that kind of attention.

Meanwhile wanted to provide another example with normals going wrong, and here’s a comparison with Untiy this time.

Edit: to better spot the Facets Directional light must have detailed shadows, in this case the Num of dynamic shadow cascades are bumped up from the default 3 to 6.

File FBX and Max:

120176-geo%20-%20copy.zip (75.4 KB)

Sorry guys Bumping this one up as i said I would after the holidays, hoping Unreal staff would have a look at it.
It’s just been too much of a frustrating problem.

Thanks.

Hi there. :wink:

I checked out your Max file and the problem your having is the same old same old problem of polygons do not make for an ideal topology for soft body objects and more so if the object needs to respond to some kind of simulation or physics behavior you would expect from and object that is I assume cloth.

Here is what actually happens when you deform polygons and how to fix it if your after the result and not as a real time cloth object.

By turning edges you force whatever lighting solution you applied into the direction of the edge turn and not across the face normal as to the result in your example pic’s

If you need real time cloth then you should change the topology to something more suitable as to cloth as I also demonstrated as Garment Maker’s topology results in less edge turning into the wrong direction

Isnt this just the issue that polygon normals in unreal are locked and not recomputed every frame? I call it the “armpit effect” as thats where it shows often. Character is modeled with arms in t, or down. So normals are set that way. When then importing the character those normals are either computed at import time or imported too. Then they are locked and apparently never touched again.
So if you then deform the mesh so much that locked normals really become apparent, like raising arms or so, then you get the dark areas accordingly.

So far I havent found a workaround, but one way I would try was to manually soften normals in maya/max/blender/[insert…] and import them with the model.
Not sure if ue4 has the capability to recompute normals per frame - probably would be a rather expensive task anyway.

Hi guys,

Just noticed your replies since i didn’t get an email notification,

Ok first of all thanks for having a look at this and for taking the time to upload the video!

FrankieV: What you are saying may be correct perhaps for cloth in terms of the garment modeling approach especially for those edges, ( I will give it a try and let you know) but this still doesn’t explain the rest of the areas displaying as facets, if you also look at the head areas in the answerhub link it too is facets all over, I have all the smoothing groups and normals in max facing correctly, i don’t assume that unreal is going to calculate them per frame i just want to import their smoothing information from max into unreal based on that pose, (similar to whats going on with the upper eyelid area), and this isn’t working, Unreal seems to completely ignore any “imported normals”. Eyelid is a good example, In max I close the lid and i rig it based on the closed lid plus the normals accordingly and then i open it back up and export it as ref pose only to find out that unreal has reset the normals back again and completely ignores the max setup. This is evident with other geometry by looking at the normals in unreal (they are all over the place). The only time i’m not having the shading issue with the eyelid is when i use a morph target instead of skeletal to make it blink. But the facets issue is still visible on many areas of the body even the head regardless of the morphs. I’m saying this because when i import the mesh in other 3d packages including Unity I don’t get these problems, this just led me to assume something is happening with Unreal? Perhaps i’m still missing something.

Recently two other posts have come up in the forums with similar problems, I don’t know if this is coincidence or if we are all missing something.

Ok Tried Both methods you suggested, sorry still getting the issue, I also did a quick test and simmed a quick garment, and you can still see the facets worst than ever on that mesh. again completely seemed to ignore smoothing groups/normals.

Image Below.

OK that’s not even close to what I was expecting to see.

Not knowing what purpose the asset needs to serve I tried a bit of an experiment to see what would it take to achieve the best result and this is what I came up with.

One sample uses quades and the other geo surface and they both responded as to what I expected they would in UE4.

If you give the same process a go the process might tell you where things have gone wrong.

P.S. Just for general info for others even if you know it or not Smoothing groups is a 3ds Max thing and there is no expataion that a 3rd party app, be it UE4, will respect the groupings in the same manner as in 3ds Max

Ok here’s the thing from what i gathered so far:

To keep you in the loop, I got a few responses from Epic, one is in this thread posted by another person running into a similar issue, the others are by mail and answerhub.

For the record we are talking about skinned moving skeletal meshes and not static ones.

My first problem (eyelid shades) had in fact to do with normals of the mesh and there is a workflow for it that i’ve tried before but epic guys presented it in a step by step procedure in max which solved that problem after i tried it again, its in answerhub.

The second problem the facets is still a problem: this thing has very little to do with the topology of the mesh, it has however to do with lighting and detailed shadows in UE and from what i also heard that there is still an ongoing side issue with normals and tangents inside unreal after the recent updates which may not be helping and is being looked into to be hopefully resolved in the future. I don’t know for sure if this has anything to do with my current problem or if it will reduce it. Because on the surface without knowing the shadow map contribution to this problem it would definitely look like a normals issue gone wrong that’s why it was my first impression, but its more complicated than that apparently.

The problem will not be immediately visible with unreal’s default lighting scenarios or indirect lighting (such as in your scene), however it will be visible under a directional light with detailed shadows, by this i mean trying to achieve high fidelity shadows on surface detail such as nose and hair strips casting detailed shadows on the face and themselves, for that, shadow cascades and dyn moving distance needs to be modified on the light and when you do this apparently the shadow map itself and the nature of it in engines will effect and bring about artifacts on the surface of the mesh. sort of like the bias settings and how that could introduce artifacts, (for the record i always leave this on default settings) and my shadow map res is set high 4K for now.

I’m still trying to understand it all and the why and the how are still lurking somewhere in my brain : ), but i’ve been hinted at these culprits along with the questionable normals issue on the side that has been reported.

So i went back and brought down my cascades to default settings and started tweaking other settings in the light to get similar results, but in the end i didn’t solve the artifact. it is still there but i brought it down a little.

That’s as far as i’m at for now. So try your scene under moving or stationary directional light with lets say dynamic shadow cascades set to 6 and moving distance adjusted to as best as possible according to a close up camera. You will most likely see these artifacts pop up. you may even leave the shadow cascades to 3 and try just with the moving distance until you get detailed shadows the artifacts will pop up. Also make sure they are skeletal meshes. if you don’t have time feel free to upload your mesh and i can show you what i mean.

The whole thing is about trying to get detailed shadows on characters and faces without these artifacts.

1 Like

Hummm OK so I’m coming in late to the party then :wink:

What hints at the problem could be here?

What is interesting is this

Looking at the same objects but with Buffer Visualization set to display AO only the artifacts really do pop out even more so than what I would expect from a simple smoothing group problem and have noticed AO does seem to have a problem with vertical and horizontal intersecting objects so could the artifacts be a problem with AO since shadowing is based on geometric shape and not face normals?

You weren’t late to the party at all : ), the party was in silence mode for almost 2 weeks until everything exploded for a few hours in a single day.

Anyway at least we have some answers now and more insight.

AO seems nothing to do with it, I also double checked it to be sure, it is simply the detailed shadow coupled with bias settings. I had to tweak the default values some more to get somewhat slightly less artifacts but it seems there is no way around this for the time being. If someone wants to have detailed shadows they Will have to just live with them.

I always thought light and shadows were very much related to Normals, guess in this case it works differently. Maybe in the future we’ll get to see updates on this. What I would’ve liked though is some online tutorial or Doc or live stream that discuss about these issues, I mean we wasted almost 2 weeks on this problem because we didn’t understand how unreal works underneath with shadow maps, we looked at normals and fbx and spent more time worrying about possible topology or FBX import issues when the main problem was from what we’ve seen little to nothing to do with them in the first place.

Naturally for the record Mesh resolution will also play a part in this, higher density meshes will have the triangles closer so the artifacts will show less, so you may get somewhat less artifacts visually on a detailed head mesh while a shirt with larger triangles on the same model will show more artifacts.

Anyhow I would still like to thank Epic for looking into the problem and to you guys, especially you Frankie. If you’d like to discuss this more i’ll be around, if not then good luck to you!

Heya! Did you ever find a resolution to this problem? I’m using the latest version of UE4 and seem to have the same issues. It’s really insane to me that this issue could still exist nearly 4 years after you posted this original thread.

No immediate solution, It has to do with Shadow Maps and Bias in UE4, they did try a tweak in the recent 4.22 or 4.23 versions by changing how Shadow map bias works in the engine, but it doesn’t produce perfect results and comes with its own artifact problems. I don’t know why this is still a problem in this engine, there were some explanations but lead to nowhere really in terms of stable results.

@WilliamK Do you think you could make a new (4.23) sample of the problem?
Mostly asking because it seems like you (or whoever posted it) weren’t using smoothing groups when modeling the tissue/cloth example.

For the new guy with the new similar problem’ perhaps a new post with a proper description and images could help us give you a work around of some sort based on your specific setup.

Of course there were smoothing groups, I have no time at the moment to make another sample but will try. Also this question came up before and turned out it had nothing to do with the model, the topology or smoothing groups, it has however everything to do with Shadow Bias and the way shadows are working with the normals of the mesh, this is especially visible when shadow bias is set very small which you need to set to have the shadow cast on detailed geometry like a face.

It was also present on all of our character geometry not just cloth.

Epic tried to fix this issue in 4.23 with dynamic shadow bias improvements you can check this in the release notes.

While it isn’t perfect, it seems to at least reduce the artifacts somewhat but i noticed it also introduces some of its own issues in some places.

I didn’t get the chance to test scenes in 4.23 with this fix though.

Try Meshmatic. https://meshmatic3d.com/

$80/m to perform basic mesh cleanup tasks? FOR THE LITE VERSION?

“What is included in the mesh clean up tools?”
“The mesh clean up includes tools to combine meshes, delete non-manifold faces, fill holes, generate LOD’s, remove duplicate faces and vertices and more.”

“What is included in the hierarchy optimization tools?”
“Hierarchy optimization includes tools to combine children to a single mesh, to delete extra parents/nodes, delete empty nodes and more.”

LMAO.