Author Topic: Loosing Resolution importing SBSAR  (Read 13090 times)

I've compiled the latest version of UE4 with Substance designer integration, and I'm running into some issues with the resolution on import. The pictures are of a SBSAR published at 2k and the same graph exported as a bitmap at 2k. I've tried sizing up the SBS in UE4 from this point and sizing it down in SD and then back up in UE, and nothing seems to help. The problem seems to be the normal map. It looks like the other 3 maps are coming though just fine, but the normal is picking up some pixelation. The 2k bitmap export looks just fine. I'm not sure whats causing this but any input would be a great help. Thanks.

Hello Joe,

Would you be able to email the SBSAR (and perhaps the mesh/scene) to josh.coyne@allegorithmic.com so we can take a look at the output? Thanks in advance!

I just emailed you the SBS, SBSAR and the Mesh. Thanks Josh.

I just emailed you the SBS, SBSAR and the Mesh. Thanks Josh.

Hi Joe,

By chance could your normal map or maps feeding into the normal map output be set to an absolute size which would cause the resolution of the map not to change with the parent graph?

Cheers,

Wes
Head of Substance Demo Art Team
the3dninja@adobe.com
Twitter: The3DNinja

Hi Wes,

The normal map and all nodes leading up to the final output are set to relative to parent or relative to input, none are absolute and none fall below 2k in the chain leading to the output.

Hi Wes,

The normal map and all nodes leading up to the final output are set to relative to parent or relative to input, none are absolute and none fall below 2k in the chain leading to the output.

experiencing exactly the same problem, would really like to here more on this. Because right now it is destroying the workflow for me

From the images posted above, it seems like your normal map is DXT-compressed. In this case, you probably should set your substance normal map output to "raw". If it is already set to raw, then there might be a bug in the ue4 plugin that ignores that setting and makes it compressed anyway.

I had this problem too, and changing to raw instead of DXT worked :) Thanks.

By RAW do you mean something like RGBA mode? At the moment I can't test this as we are in production and compiling Substance into UE4 started giving us problems with other plugins. Can't wait for Epic to integrate Substance natively so us developers (more artist than programmer) can just work.

By RAW do you mean something like RGBA mode? At the moment I can't test this as we are in production and compiling Substance into UE4 started giving us problems with other plugins. Can't wait for Epic to integrate Substance natively so us developers (more artist than programmer) can just work.

Yes, exactly. Also, I'm amazed you even are able to publish a build using the Substance repo. For me Substance only works in the editor. Apparently the Dlls don't get included in the published build :/ for some reason.

Yes, exactly. Also, I'm amazed you even are able to publish a build using the Substance repo. For me Substance only works in the editor. Apparently the Dlls don't get included in the published build :/ for some reason.

Hi Mithril, thanks for your input on the image quality issue! We are also working on the published build issue.

I'm stuck with the same problem.

Unreal Engine: 4.2.0
Substance Plugin: 4.2.0.1
(Note: Substance Plugin is the latest (4.2.0.1) but it identifies itself as 4.2.0.0)
Substance Designer: 4.3.1

The normal OUTPUT is corrupted when Substance Plugin for UE-4 interprets it.
You can see it as the output of a very simple graph (SBS_Graphic.PNG).

I have tried several fixes: making the normal output as RGB; making it as RGB-16; the default mode and all the others possible modes; with no-mipmaps option; generating the normals by means of an input image instead of by a function. Making all graph's resolutions fixed at 2048x2048. Fixing the output's alpha channel by means either of a Channels Shuffle or a Levels nodes. Nothing works.
The substance works fine in Substance Designer and Player, also in Marmoset Toolbag. They also work even when you nest this simple example as a subgraph and combine the output from both graphs.

The only way to make it work in UE-4 is by having Substance Designer to generate the Normal map as a bitmap and then inserting this bitmap into the UE-4 material's normal input.

I'm attaching several images:

- SBS_Graph.png
The simple Substance graph which generates wood veins.

- UE-4_Material_Editor.png
The output of the graph in UE4 material editor in two versions; by taking the graph's normal output and by taking the normals bitmap previously generated by Substance Designer.

- UE-4_As_Subgraph.png
The same that before but applied to the final mesh (a simple box) as a nested subgraph (the outer graph generates the bevels of the door).

- SBS_Designer_As_Subgraph.png  and  Toolbag_As_Subgraph.png
The same but previewed by Substance Designer and Marmoset Toolbag 2.


- Doors.rar
The Substance package of the example.

Thank you.
Last Edit: July 05, 2014, 05:19:27 am

Hi FncFuentes,

Have you checked the Texture Format in UE4 to ensure the normal map is being compressed as a normal map? We've seen some assets where UE4 incorrectly assumes a normal map texture is a regular color map and then you end up with the artifacts I see in your screenshots.

Please excuse me if I'm wrong or I can't explain myself correctly, because English is not my main language. I think you all haven't seized the meaning of this thread's question.

Me and Joe_4 in his original post (I think) are both trying to explain that we can not make a substance which GENERATES a high-frequency normals OUTPUT without UE4 corrupting it at RUN-TIME.
Let me depict it:

   NOISE-GENERATOR NODE --->  NORMALS NODE --->  OUTPUT

   (THIS DOESN'T WORK WHEN RENDERED BY SUBSTANCE PLUGIN)

So, there is no input from a bitmap file in our questions. I really think Joe_4 is having my same problem. When we speak about a normals bitmap file input we do it as the only way to make it work and only for testing/debugging purposes. Hence the title of this thread "... importing SBSAR". We both attach an image with the graph's output (bad) and another image using a normals bitmap file previously generated by Substance Designer (good).

But, as I understand, your answers are all about how to import a normals bitmap file. I can't see the need to generate a procedural normals bitmap with another program and then to import it inside Substance Designer. We are supposed to use SD as the best tool for generating them at run/compositing time.

In order to reproduce the issue you only need to create a simple graph -like the one in my example- which generates a high-frequency normals output. I have already tried all workarounds I could imagine (changing fixed/relatives resolutions, etc.). For more details you can refer to my previous post. Note that Marmoset Toolbag 2, unlike UE4, seems to deal fine (at least much better than UE4) with the graph's output.

Please excuse me if I'm wrong or I haven't been able to explain myself.

Thank you.

----------------------------
EDITED:
Josh Coyne, in UE4, when you hover the mouse over the instance's normal-map icon you can see:

LODBias: 0
SRGB: False
Never Stream: True
Compression Settings: TC_Normalmap
Filter: TF_Default
LODGroup: TEXTUREGROUP_World

In Material Editor, you can see:
Sampler Type: Normal

Thank you.
Last Edit: July 10, 2014, 01:51:16 am

The issue I see on your screenshot is not corruption of the output, but rather look like simple DXT compression artefacts.
The DXT compression Substance uses is extremely fast but the quality may not be as good as the one used by UE4 when importing standard bitmaps, that's probably what these square patterns on the edges are.