Babylon Opacity - Inverted from my traditional thinking

Questions
1

Hi All,

Was always curious about the use of color in the opacity channel. Coming from CGI, black in the opacity channel was always transparent, and values towards white were more opaque. In Babylon this is reversed, so just interested if this is a gaming convention I wasn’t aware of.

image
image847×503 66.2 KB

I’ve always had to invert my maps before exporting from 3dsMax to GLB as a result.

https://playground.babylonjs.com/#20OAV9#24

2

Opacity does not come from the color (RGB) but from the alpha channel :slight_smile: so 0 in alpha means fully transparent no matter what the color is

3

Hi @Deltakosh, thanks for the explanation. I do understand the GLB exporter is taking the transparency map and adding it into the alpha channel and it’s not about the diffuse. (I know I could just use an RGBA here) but If I specify a grayscale as transparency its where it goes awry.

If I’m exporting from 3dsmax, I have to invert my transparency channel in order for the opacity to be correct on the exported GLB - Here’s an example with a shadow plane -

image
image734×696 68.6 KB

According to this map, normally the outside would be opaque and the gradient would be fading to transparent to the center of the plane. However it is not, and the exported GLB has a correct transparency.

Resulting GLB asset in the sandbox -

image
image905×563 21.2 KB

The generated map on the glb is indeed a correctly structured png file with alpha

image

If I set the material up with a transparency map in the conventional way i.e how i’d expect this to work - (black is invisible, white is solid) then it’s flipped in the output.

image
image716×704 68.8 KB

This should give a dark gradient shadow, fading off as it goes out right? This is the result in the sandbox -

image
image891×559 25.5 KB

and this is what has been written, which makes sense based on what I’m seeing

image

Hope this makes sense. Happy to send you the max file to test!

4

I guess I need to summon @PatrickRyan

2 Likes
5

@Lonerobot, what you are seeing here is a fundamental difference in how Max’s physical material shader treats alpha versus the mental model you have for alpha, and the clue is in the name. The Physical Material shader in Max uses transparency for alpha where your mental model is using opacity for alpha. Think of it this way:

  • black, which is a value of 0, in a texture means false
  • white, which is a value of 1, in a texture means true
  • any value in between is somewhere in between true and false depending on its proximity to 0 or 1

Then ask yourself the question using the terminology from the shader:

Transparency

  • black will mean false which means the pixel is not transparent
  • white will mean true which means the pixel is transparent

Opacity

  • black will mean false which means the pixel is not opaque
  • white will mean true which means the pixel is opaque

The Babylon shader model deals with opacity, as does the Arnold Standard material in Max. We know that the physical material is using a transparency model, so we convert the texture on export to comport with the transparency model by inverting it so that when we display it in our opacity model it renders the same as it did in Max.

I hope this makes sense as I know that when you hop between DCC tools or even between shaders within Max, it is easy to miss that the alpha model had changed. Let me know if you have more questions.

4 Likes
6

Hi @PatrickRyan, thank you for the explanation - that makes complete sense and very elegantly explained. If I’m honest I don’t ever touch the physical materials unless I’m exporting to GLB, so it’s always good to understand what sounds like similar concepts and how they dictate the workflow in this instance.

Ultimately, none of this affected being able to get the results I needed, it was more me wanting to understand why this workflow is in place.

Thanks a million to you and @Deltakosh for the support.

3 Likes