[Blender Exporter] Question about normal material

[xaero59]

I noticed that the normal material doesn't behave like other materials in blender ( see : self.textures.append(Texture('bumpTexture', 1.0 / mtex.normal_factor, mtex, mesh, exporter)) )

The normal level is = to 1/lvl , is it a bug or is it required by bjs or blender ?

[Wingnut]

Hi @xaero59.  No replies yet, huh?  Sorry.  May I try to clarify?

You are talking about this: https://github.com/BabylonJS/Babylon.js/blob/master/Exporters/Blender/io_export_babylon.py#L2069  ... yes?

You are asking why line 2069 is different... than lines 2065 and 2073, yes?  Why the extra mathematical division for bump map level?  *nod*

I also see it happening at https://github.com/BabylonJS/Babylon.js/blob/master/src/Materials/babylon.standardMaterial.ts#L819

Let's request an audience with @JCPalmer, who has been known to be an export in experting.  Errr... I mean... an expert in exporting. 

But, all forum users... if you have info on this unique decimal-point-shifting for level... on normal/bump maps... we would love to hear it.  Thanks!

[xaero59]

@Wingnut  Yes absolutely  

It's interesting to see that babylon is doing the same for bump material , so there's certainly a good reason.

[JCPalmer]

don't know.  This line was in exporter before I started with it.  Doing an inverse twice certainly looks suspicious though.

[gryff]

@xaero59, @Wingnut: @JCPalmer. Well I'm not the best person to understand the whys and wherefores of coding but I do notice that one of Wingy's links goes to "io_export_babylon.py" - version 4.6 of the exporter. However, as Jeff points out the problem line was " in exporter before I started ". So why?

All I can do is to comment on normal maps in general and how they are created. Baking normal maps with red, green and blue channels can get complicated. Different software can have different definitions about what each channel represents.

See from about 45 secs of this video that compares what the channels represent in Maya and UDK. Blender is different again.

I'm not sure whether this is connected to your issue, but always be careful with normal maps.

cheers, gryff

[xaero59]

Found when the modification happened : https://github.com/BabylonJS/Babylon.js/commit/71539bb29371fca67a6ab3329265b6a07e1050cc


Since the bump level is set directly in the babylon file, that doesn't seem very relevant to me.

@gryff You are right on this, personally I'm working with collada files imported into blender , the original meshes use a greyscale bump map , so I'm converting them into normal map , it's not perfect but it works, the only thing is that I need to adjust the bump level very often.

[V!nc3r]

So can we patch this line by deleting "1.0/" ? I vote yes

(just a little tip in case someone don't know : you can do maths directly in number input in Blender, very useful in this case )

[Wingnut]

Yeah, Jack Caron worded that git PR...

"use the inverse of the normal factor to match the inverse level in the loader"

match ==  compensate-for?  I'd say yes.

I wonder if we should scour the change/version logs for Blender, and see if/when a change happened to that value(s). 

But as Gryff kindly pointed-out... it is a bit of a moving target... in various software.

All in all, I think Jack's PR was to compensate-for (counter-act) an unusual calculation... seen in the exporter.  Jack could not access the exporter code, so he compensated by modding the framework. (in theory).  But still... somebody put that code in the exporter... long ago, and there was probably a reason. 

Perhaps we should examine the code of other Blender exporters, and see if others did the same?

Let's look at "them".  https://github.com/mrdoob/three.js/blob/master/utils/exporters/blender/addons/io_three/exporter/material.py#L82

Hmm... bump_scale and normal_scale.   Lets go deeper... like here and here.  Hmm, is there more to this story, my dear Watson?     Perhaps Blender only provides these little "scalar?" values (fractions), and perhaps BJS needs a big fat integer to use for .level?  I'm just speculating... but... I smell something.  heh

[xaero59]

 

6 hours ago, V!nc3r said:

So can we patch this line by deleting "1.0/" ? I vote yes

(just a little tip in case someone don't know : you can do maths directly in number input in Blender, very useful in this case )

I vote yes too , and thanks for the blender tip !! Very useful indeed.

My theory with the exporter modification is that maybe in the past when BJS was loading imported mesh the bump material was processed using 1.0/lvl as well ( so let's say one put 0.5 as the bump level in blender, it would give : 1.0/0.5 = 2 , 1.0/2 = 0.5 ) but it's not the case anymore and the bump level is just directly processed without any additional maths.

[GameMonetize]

@xaero59 is completely right. This comes from ages ago

And because I'm here to keep the backward compatibility safe, I cannot allow this change  A lot of .babylon file won't work if you change this as the will still come with a  1 / level value

[V!nc3r]

Understandable ; so we need to write this tips on the exporter doc I think.

[GameMonetize]

But I thought it was transparent for the user and blender export 1/x and bjs loads 1/loaded which in turn end up with x right?

[V!nc3r]

Personnally I must do the maths to have the correct value in the exported .babylon file.

[GameMonetize]

You have to invert the value manually? If yes I'm for removing the inversion in the exporter

[gryff]

To add to this topic about the issue I mentioned above - an example. See images below.

First image - a high poly sphere that I sculpted in Blender so that it has some protruding ridges. I then baked a normal map which I then applied to a low poly sphere (used to create the high poly sphere by subdivision)

Second Image - I exported that low poly sphere at two geometry settings for the normal factor 5 and its inverse 0.2 and viewed them in the Sandbox. Note the ridges do not protrude out but are cutting into the sphere.

I gather this is caused by the red and green channels being "inverted" compared to Maya.

cheers, gryff