Weird behavior of node material

Questions
1

Hello guys,

since the node material I created in nme fits my needs I tried to export the code and use it in my project. I noticed that the material doesn’t even look close to the pbr material but I can’t figured out why.

The preview in nme looks fine but using the code or parsing the material via snippet breaks it. This is not related to my code because it also happens in pg.

Here is the pg: https://playground.babylonjs.com/#SD96UQ#1
And here the nme: https://nme.babylonjs.com/#LWL6BV#30

I removed all node connections but the one necessary for pbr. Am I missing something or is this a bug?

Best

2

pinging @Evgeni_Popov

3

You should not switch to right handed system as your meshes/materials are not suited to this mode: just remove the line #4.

Or if you do want to keep this line, change the side orientation of the material to clockwise order:

https://playground.babylonjs.com/#SD96UQ#2

1 Like
4

Thank you @Evgeni_Popov that was very helpful. I always work in right-handed system so I didn’t even imagine that this could be the problem.

But I realized another issue and I was able to reproduce it in pg: https://playground.babylonjs.com/#SD96UQ#6

I created three cubes with exactly the same texture:

  1. Parsed node material including textures from nme. Works fine!
  2. Parsed node material from nme & added textures manually. Works fine!
  3. Created the node material using code & added textures manually. Textures are way brighter than before.

Any idea what’s the problem here?

Best

5

You need to add BaseColor.convertToLinearSpace = true; but it’s something that “Generate Code” should have done automatically.

This PR will correct that:

1 Like
6

Thanks. That solves it!

7

Sorry @Evgeni_Popov that I come back with this but I put the node pbr material in direct comparison to a normal pbr material and it still looks slightly different. Is there still something I miss? I created a pg for it here: https://playground.babylonjs.com/#SD96UQ#10

It seems that the reflections are not correct.

HtcuP4IXgJ
HtcuP4IXgJ775×905 81.5 KB

8

By default, the PBR material is taking the metallic value from the red channel of the metallicRoughness texture, the roughness from the alpha channel and the occlusion from the occlusion texture.

To match what you did in the NME, you should do:

    pbr.useAmbientOcclusionFromMetallicTextureRed = true;
    pbr.useRoughnessFromMetallicTextureAlpha = false;
    pbr.useRoughnessFromMetallicTextureGreen = true;
    pbr.useMetallnessFromMetallicTextureBlue = true;

Also, you should set the metallic and roughness properties to 1 as they are multiplied with the values read from the texture.

Here’s the fixed PG:
https://playground.babylonjs.com/#SD96UQ#13

1 Like
9

Oh, I should have known that. Thanks again!

10

Since this post still fits to the topic of a weird node material behavior I didn’t want to create a new topic. I encountered another problem that I think is very strange.

I want to blend two normal maps and the result in nme is exactly what I want:

t86OSkUXsm
t86OSkUXsm638×510 99.4 KB

So I tried to use the node material in my local project but that wasn’t possible. So I created a pg to check if the fault is part of my code. Parsing the nme to the exact same mesh lead to this result:

oHP8zHtaQu
oHP8zHtaQu753×585 30.2 KB

There is some kind of influence of the normal map but it is nothing in comparison to the nme one. So I wonder what is different, why is that happening. You previous answers were very helpful, @Evgeni_Popov. Do you have an idea what is going on here?

11

You will need to provide a PG for use to be able to help.

12

Oh sorry I forgot to paste the link. Here it is: https://playground.babylonjs.com/#SD96UQ#18

13

The problem is that you apply a very big scale, so your textures are stretched a lot on the surface and you can’t see the bumps.

If you remove the scaling, it’s better but not quite right yet: it seems your texture coordinates are not ok. See the comparison with a unit cube:

https://playground.babylonjs.com/#SD96UQ#21

If you apply a uScale/vScale of 10 on the textures it’s a bit better:

https://playground.babylonjs.com/#SD96UQ#22

15

Thanks for your response!

Indeed it looks better after adjusting the texture scale. But there has to be something something else that causes this behavior. I want to use the first normal map as a tileable material so adjusting the scale is no problem, but the second normal map is supposed to wrap the model to add some detail.

This problem is not happening if I export the model with materials. So I made a test using regular pbr material. That works fine with the same normal map and same scale. So I really think it has something to do with the node material. Here is the comparison: https://playground.babylonjs.com/#SD96UQ#28 (first & second normal map are working fine with pbr)

A lot of confusion on my side :sweat_smile:

I appreciate your help.

16

You’re right, in fact you are missing a normalize after the world normal computation:

https://playground.babylonjs.com/#SD96UQ#30

image
image877×611 92.3 KB

Note that this normalize block must target the vertex fragment to work correctly:
image

1 Like
17

Oh yes, that’s it! It looks beautiful. Thank you very much.

This normalize node isn’t part in the pbr node material example in the docs. So I didn’t even think about this.

19

“Generate code” miss it to set Normalize.target = 1. It works after setting it manually but it would be nice if you can add this to nme.

And the “visible in inspector” nodes are not shown in inspector if created the node material by code. Parsing the snippet works though.

20

Here’s the PR that will fix those problems:

1 Like