Messages

1

Substance Integrations - UE4 - Re: Normal map compression artefacts

 on: February 10, 2021, 11:26:09 pm 

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.

2

Substance Integrations - UE4 - Re: Normal map compression artefacts

 on: February 06, 2021, 02:36:57 pm 

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;

3

Substance Integrations - Autodesk 3ds Max - Re: Substance in 3ds Max 2.4.0

 on: February 06, 2021, 01:38:07 pm 

Just the opposite in my case: I can't open previous scenes that version 2.3.2 of the plugin loads just fine. With the new version, 3ds max 2020 crashes instantly.
Of course, I've downgrade back to v.2.3.2 until just today it failed to load a scene I have been working with and saved yesterday, without adding any additional sbsar to it. The "parameter block" error pops out instead.

What I'm realizing to this date is that including any of the substance plugin in my scenes is almost suicidal and I'm thinking of recovering all the old scenes I have with substances in it and baking their maps instead. Fortunately, I preserve in my hard disk several of the previous versions of the plugin. Anything is better than losing my old work because of a plugin.

4

Substance Designer - Technical Support - Re: "Tiling Mode" doesn't work at run-time and it isn't exposed in sbsar. SD2020.2.2

 on: January 29, 2021, 05:47:13 pm 

Thank you, Luca.

I have just located an old an very elaborated substance I made in 2017. In it I was making use of the Base Parameter "Output Size" dynamically. I thought it was working fine back then but this was in a Material Function (aka filter) deep inside the main graph so I can't be so sure now. Anyways the console sends a lot of errors when I open this graph in the new version so I'll have to rebuild it from scratch if I need to use it again.

The point is that nowhere in the docs of the links you sent me says anything about not exposing this parameter either. It should warn about exposing any of these "Base Parameters" of any node. They don't appear when you choose the Expose Parameters menu in the node but what I do very often is to create the parameter forehand and then reference it inside the node's function, or choosing it from the drop-down menu of the node's properties panel. By doing it this way you have no warning at all of your mistake.

Anyways, I'll have it in mind from now on.

Thank you again.
Francisco Fuentes.

5

Substance Designer - Technical Support - Re: "Tiling Mode" doesn't work at run-time and it isn't exposed in sbsar. SD2020.2.2

 on: January 29, 2021, 02:37:06 pm 

Thank you, Luca, for your fast reply.

It's very strange; In the link you pointed out, "Tiling Mode" doesn't appear in the limitations table and I think to remember using some of these kind of parameters at run-time before. Moreover, in this tutorial you can see it working at run-time or at least in the preview tab (min. 21:00):

Substance Designer - Using Functions in the Transform 2D Node Matrix, by Olga Polukhina:
https://www.facebook.com/OlgaPolukhinaArt/videos/871967809669684/

Please, don't feel bothered; I believe in what you say and your answer makes sense but I still think that I have used some of them before. Maybe it is something that have been changed recently?

Best regards.
Francisco Fuentes

6

Substance Designer - Technical Support - [SOLVED] "Tiling Mode" doesn't work at run-time and isn't exposed in SBSAR

 on: January 29, 2021, 01:32:01 pm 

Let's make an Integer parameter in a substance graph and assign it to the "Tiling Mode" function of any node, for example a "Transform2D" one. We can choose to expose it either as a slider or a drop-down list, it doesn't matter.

1.- It works as expected when you change its "Default" value in the graph's "Parameters" tab.
2.- It does nothing when you change it in the "Preview" tab.
3.- This exposed parameter doesn't even appear in the sbsar compiled graph, be it opened in Substance Player or in another application (3DS Max).

7

Substance Integrations - UE4 - Re: Loosing Resolution importing SBSAR

 on: July 11, 2014, 03:44:11 pm 

For God's sake! This is what I call an answer. No offense, please, but if you were a woman I would like to marry you!

No, seriously, should we close this thread by saying:
"At this moment you can't generate such high-frequency normals output with Substance plugin for UE4 without losing a big amount of quality in the result."?

No workaround?
(something like "Try to generate a bump map instead and then inside UE4's material editor ...").
In UE4 you actually can specify several compression types for an imported bitmap but you can't do it for a Substance-generated bitmap. You can't even visualize one of these Substance bitmaps.

May be you, Allegorithmic, can do it. Substance products have at this moment an important momentum; you are in the knife's edge.

Thanks.

8

Substance Integrations - UE4 - Re: Loosing Resolution importing SBSAR

 on: July 11, 2014, 01:38:20 pm 

Hello Cyrille Damez.

I'm very, very glad for having your technical answer to my problem. I'm an old engineer who is trying to move to another field, the architectural visualization.

As I infere from your answer, it seems to be a different layers stack working in the Substance plugin for UE4 than the one working in the Marmoset Toolbag plugin/module.

It is being compressed by the substance engine after the texture has been drawn, and before storing it in the graphics card video memory.

Therefore, either it is the UE4 Substance plugin who compresses the in-memory-bitmap before submitting it to UE4 or it is the plugin itself who directly stores the bitmap in the video card memory. I didn't think it works this way.

Marmoset is ... I suppose it does not compress the textures because it aims at maximum quality.

Therefore, in this case it is Marmoset Toolbag -not the Substance module- which is the responsible of compressing the textures and storing them in the video card memory. I thought this is how it worked in UE4 too.

You should be able to switch individual textures' compression on or off in UE4.

I have searched this alternative for long before posting my question in this thread. Haven't found it either.


I'd like very much should you be so kind to clarify the above questions for me (the layering of the engine) due to my incurable tech curiosity. On the other hand, perhaps the more pragmatic and urgent question is about whether is there any workaround. Can I generate high-frequency normals outputs in UE4 with the Substance product?

Thank you.

9

Substance Integrations - UE4 - Re: Loosing Resolution importing SBSAR

 on: July 11, 2014, 03:56:54 am 

Hello Jeremie Noguer.

Excuse me if I can't understand your answer; I'm not importing any bitmap, it's the SBSAR who is generating the normals output. When and where is it being compressed? It can't be compressed inside the SBSAR because, as I understand, it's being generated at render time.

Could you make it clearer for me?:
- Does your answer mean that we can't make a Substance graph which generates a high-frequency normals output?
- Why does Marmoset Toolbag, unlike UE4, render it fine?

Thank you.

10

Substance Integrations - UE4 - Re: Loosing Resolution importing SBSAR

 on: July 10, 2014, 01:10:53 am 

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.

11

Substance Integrations - UE4 - Re: Loosing Resolution importing SBSAR

 on: July 04, 2014, 10:33:12 pm 

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.