Normal map compression artefacts

[Thibaud Van Vreckem]

Hello,

We are using ue4 to develop a pre-production previz studio tool.
the product visualised are embossed product with very fine detail and resolution.
We noticed some artifacts (squares appearing at the edges of the relief) in the final 3d renderings.
Cfr attached 500% crops of the artefacts (normal red channel) compared to the substance designer output.
It turns out the artifacts comes from the generated normal map, and are due to the map compression scheme, which (and that's the culprit here) can't be changed in the UE4 plug-in integration.

This is a serious showstopper and after more than 6 months of development on this project we are now considering switching to unity in which substance apparently doesn't have any of theses limitations.

I'd love to hear any potential options I could explore to solve this issue. (Using externally generated map isn't an option. as the core principle of the tool we are building is the procedural generation based on inputs)

Thansk a lot.

[Wes McDermott]

HI,

Which version of the UE4 plugin are you using. Our latest iteration that natively supports UTexture2D allows you to change the compression settings for the generated textures.

Cheers,
Wes

[Thibaud Van Vreckem]

Hi Wes,
Thanks a lot for the reply,
I'm using the latest version of the plugin in UE 4.26.

that's precisely the part that I'm struggling with, as changing the compression settings in the normal texture does not affect the output at all.

Is there something I'm missing ?

[FncFuentes]

In 2014 I reported a similar problem related to artifacts due to normals map compression.
I remember solving it by modifying the source of the plugin by myself.
I don't know whether the source is still available for UE4 or not but I will describing my solution below:

It's about disabling the compression for the normals map in the plugin. I modified the source file:
Plugins\Substance\Source\SubstanceCore\Private\SubstanceCoreHelpers.cpp

It was a quick workaround, not an elaborated one, but it worked for me and the quality of the normals output was perfect after it. I don't either remember the mechanics of my changes but it was about forcing the plugin to not use DXT5 for raw textures but R8G8B8A8 instead. It worked for me and perhaps you can perform the same or a similar change to solve your problem.

I tell you again that it was a very quick workaround I performed back in 2014 and I didn't refine the code nor tested it extensively for any unwanted side-effect. You should do it by yourself.
Moreover, If Wes McDermott has a better solution (the UTexture2D one) I'd better use his.
In any case, here are the modifications with which I got very clean normal maps back then:


CHANGES in  SubstanceCoreHelpers.cpp:

Inside FUNCTION  SubstanceToUe3Format()

   case Substance_PF_DXT5:
      OutFormat = PF_DXT5;
      break;
   //-CHANGE-  Add this:
   case Substance_PF_RGBA:
      OutFormat = PF_R8G8B8A8;
      break;

Inside FUNCTION  ValidateFormat()

   switch(NewFormat)
   {
   // we force the Output in DXT when raw
   case Substance_PF_RGBA:
   //-CHANGE- Comment next line
   //   NewFormat = Substance_PF_DXT5;
      break;

Inside FUNCTION  Ue3FormatToSubstance()

   case PF_A8R8G8B8: return Substance_PF_RGBA;
   //-CHANGE- Add this
   case PF_R8G8B8A8: return Substance_PF_RGBA;
   //-CHANGE- Add this
   case PF_R16G16B16A16_UINT:  return SubstancePixelFormat(Substance_PF_RGBA|Substance_PF_16b);
   //-CHANGE- Add this
   case PF_R16G16B16A16_SINT:  return SubstancePixelFormat(Substance_PF_RGBA|Substance_PF_16b);


Inside FUNCTION  IsSupported()

      case PF_A8R8G8B8:
      case PF_G8:
      //-CHANGE- Add next line
      case PF_R8G8B8A8:
         return true;

[AliSafari]

Hi Wes,
Thanks a lot for the reply,
I'm using the latest version of the plugin in UE 4.26.

that's precisely the part that I'm struggling with, as changing the compression settings in the normal texture does not affect the output at all.

Is there something I'm missing ?

Hello @Thibaud Van Vreckem
I talked to one of our developers. Is it possible for you to send us the sbsar with this problem? How about replicating the problem in a small project that you can send us? You can send it via Direct Message me if you want.

Thx,

[Thibaud Van Vreckem]

Thanks a lot for the reply.
I've setup an empty new Unreal project with just this sbsar and the issue remains.
I've sent you a direct message with the required file to reproduce the problem

Thank you.

@FncFuentes
thank you for the suggestion. let's trust the kind devs at adobe for handling this issue the right way

[Wes McDermott]

Hi,

We did some investigating and the plugin seems to be working correctly. The output displayed in Substance Player will show as uncompressed and is not the same as the default compression settings in Unreal. Comparing Designer or Player outputs will not give a 1:1 comparison. Any compressed texture will show some artifacts. 

We switched the UE4 plugin to use UTexture2D at 4.24. The generated textures from the Substance material are using UE4's compression settings and all of the texture settings for an output are controlled via UTexture2D. You can change the compression settings for the textures. By default, we use the Normal Map BC5 compression scheme. However, if you set the compression to UserInterface2D (RGBA), this will essentially be uncompressed. 

I believe the Lossy Compression Amount and Quality settings are used when the project is built. I am not 100% sure on that. Those settings do not affect any textures in the Editor, so it's not specific to the Substance plugin.

Another option is to set the GBuffer state in the Project Settings > Rendering category to Use High Precision Normals. This will   encode the normals at 16 bit per channel.

Cheers,
Wes

[Thibaud Van Vreckem]

Thanks for the quick investigation and reply.
The reason I started this topic is precisely because:
1. Changing the compression settings has no effects at all.
2. Changing the compression format (from ie DXT5 to userinterface2D) has no effect at all.
under the hood the plugin will always stubbornly revert the normal to BC5 Format whenever sync rendering is called.
I believe this is quite a major bug, and I'm seriously surprised that didn't show up in your investigation.

For what it's worth the plugin is set to using the GPU engine in the settings.
Let me know how I can assist in providing further detail or information if needed.

Thanks a lot for looking into this.

[Wes McDermott]

Thanks for the quick investigation and reply.
The reason I started this topic is precisely because:
1. Changing the compression settings has no effects at all.
2. Changing the compression format (from ie DXT5 to userinterface2D) has no effect at all.
under the hood the plugin will always stubbornly revert the normal to BC5 Format whenever sync rendering is called.
I believe this is quite a major a bug, and I'm seriously surprised that didn't show up in your investigation.

For what it's worth the plugin is set to using the GPU engine in the settings.
Let me know how I can assist in providing further detail or information if needed.

Thanks a lot for looking into this.

Hi,

Thanks for the follow up. Our dev is looking into "under the hood the plugin will always stubbornly revert the normal to BC5 Format whenever sync rendering is called." He said this was indeed a bug. I wasn't testing any runtime components. I am sorry I overlooked this.

For me, changing the compression format does update in the Editor. Are you not seeing any change in Editor? Using userinterface2D seems to get rid of the artifacts for me. 

Cheers,
WEs

[FncFuentes]

Excuse me if I'm goofing here but this case quite reminds me of the problems I had years ago and how well it worked once I forced the raw textures to be stored as R8G8B8A8. Notice that it's not B8G8R8A8 (see the code in my previous post). I have always wondered if it was a bug in the plugin's code because both constants are prone to be confused.

Once again, excuse me if I'm goofing here. I haven't studied the plugin's code in deep and I could be wrong.

[Thibaud Van Vreckem]

For me, changing the compression format does update in the Editor. Are you not seeing any change in Editor? Using userinterface2D seems to get rid of the artifacts for me. 

Cheers,
WEs

As you may have seen on the video I sent, changing the compression format will actually invalidate the map (and also reset its size to 256x256). and when for some reason sometimes it doesn't invalidate the map, some weird stuff happens (which appears to be due to the editor preview fooled into displaying the same bc5 data into some other format)
the normal output is always unchanged, inspecting the normal red channel helps seeing the compression artefacts

[AliSafari]

For me, changing the compression format does update in the Editor. Are you not seeing any change in Editor? Using userinterface2D seems to get rid of the artifacts for me. 

Cheers,
WEs

As you may have seen on the video I sent, changing the compression format will actually invalidate the map (and also reset its size to 256x256). and when for some reason sometimes it doesn't invalidate the map, some weird stuff happens (which appears to be due to the editor preview fooled into displaying the same bc5 data into some other format)
the normal output is always unchanged, inspecting the normal red channel helps seeing the compression artefacts

Hello @  Thibaud Van Vreckem
Thanks for providing additional information regarding the issue. I have filed a bug in our bug tracking system and our development team is currently working on the issue.

Sorry about the inconvenience that this has caused for your project.

Thx,

[Thibaud Van Vreckem]

Thanks a lot for the follow up.
I'm looking forward the fix and clean substance normals in ue4

[Thibaud Van Vreckem]

Hello,

sadly the latest update didn't fix anything regarding this issue.
Is there any follow up on this ?

Tia

thibaud

[-kg-]

hey @Thibaud Van Vreckem ,

Apologies for the delay! It is in our current sprint and being worked on as we speak. We are hoping to get it into the next release of the UE4 plugin.