Houston we have a problem: Lumberyard not sync with MikkT tangent basis.

I don’t know why I was surprise, since Lumberyard is base off of Cryengine 3.8, which also had problems with sync normal workflow. It suposely support MikkT tangent basis but it isn’t syncing up with it.

Here’s a good link to what a “sync normal map worflow” means, for the laymen:

http://docs.cryengine.com/display/SDKDOC2/NoMaps+-+Normalmap+Conversion+Tool

Basically, it boils down to using 1 smoothing group , not needing to split up hard edges , which creates extreme gradient in the normal maps that still look correct in the engine. I tried this on a simple cube, with 1 smoothing group and a simple cross UV:

The cube face should be flat shaded(it’s incorrect shaded here) and the corners should have a bevel shading(which is correct). This same cube with the normal map, looks perfect in Unreal Engine 4(which is sync to Mikk T)

In Cryengine V, they introduced a fix via an external app call NoMaps, but for Lumberyard I think this should be support at the core level, no need to add another standalone apps to download/use.

Please please fix this…

1 Like

Hello @SonKim, thanks for bringing this up to us. We would like to let you know that we are aware of this issue and are actively discussing solutions. Please stay tuned for future feature announcements and updates.

@Jordan thanks for the confirmation! :slight_smile: this issue is a big one, it’s kinda a deal breaker for me. Even if I use workaround(splitting UV at hard edges) the shading will still have some flaws(you can see this the BAR I imported into Lumberyward).

Not that Amazon doesn’t know but I just want to reinforce what SonKim said. A proper synced workflow is very important to me. Splitting UVs for better looking normals is really wasteful for complex objects. Also, texturing becomes more complex due to higher difficulty matching across UV islands. You’re basically stuck painting in 3d only. And procedural textures are harder to deal with as well.

This should be high priority. I see SonKim posted this over 9 months ago. I just got the engine and I can’t really find anything on synced normal workflow. If there is a way then I apologize and ask how and where is the information about it, if not, get on it guys.

Hey @EricW_CG, let me resurface this to the team to see if there is any movement here (I’ve also only recently joined the team). I’ll let you know what I fond out.

@Binky Congratulations on joining the team :slight_smile: Find anything out?

Thanks @EricW_CG! Just to make sure this is on the roadmap I created a Jira ticket and it has been assigned. It’s definitely something we are discussing internally. I’ll keep this thread posted as we progress.

+1 This would be huge. I wasn’t aware of this limitation until I saw this post, and spent many hours trying to figure out what I was doing wrong.

I have since found a suitable workaround, but still have to add geometry and split/weight normals in Blender according to this tutorial: http://polycount.com/discussion/154664/a-short-explanation-about-custom-vertex-normals-tutorial . I guess this is the method employed by Star Citizen. While it isn’t a terrible technique, it isn’t suited for low-spec applications or high detail models.

I tried custom normals yesterday with fbx workflow and they import correctly but breaks as soon as you add normal map(probably it recomputes the normals it needs to be a choice possibly on import and then remembered).

Many people reports this technique as invented by Star Citizen, but i was the first to talk about it online 7 years ago after many years of use.Web sites are gone, but this youtube video dated 7 years ago shows a 3dsmax script implementation of this technique that possibly still represent the state of the art of vertex normal workflows.I used this techniques so many years before people start to really worry about the relation between vertex normals and normal maps that knowing that this problem is still relevant in 2017 makes me a bit sad.

That’s awesome @Gamely. But true, it’s amazing how somethings move so quickly while other issues kinda linger in a perpetual state in this field.

First to talk about it online ? ok pal.
Maybe the first to talk about it on some lame website that no longer exists.

Was this fixed.

I’m trying to use a tangent normal map as part of a mesh decal sheet.

I’ve tried rendering it in Substance Designer, Xnormal using MikkT and inverted green as specified and it looks correct at first glance.

But when I rotate a section of the sheet 90 degrees and align it to a section that should be seamless they appear in normalmap debug view as slightly different shades of the same color and a seam shows as a result.

I’m not sure if I’m expecting the normal map to do something it can’t do there or if the internal calculations are not synced.