AcademySoftwareFoundation / OpenPBR

Specification and reference implementation for the OpenPBR Surface shading model

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Suggest "presence" or "coverage" instead of "geometric_opacity"

andre-ilm opened this issue Β· comments

I was wondering if anyone would be open to using an alternative name for geometric_opacity.

In OpenPBR the intention of this signal is to create cutouts of the geometry, rather than to change how much light is transmitted through the surface. In my experience opacity is usually used to describe the degree of transmittance.

Interestingly, the definition of the parameter mentions presence:

where Ξ± = πšπšŽπš˜πš–πšŽπšπš›πš’_πš˜πš™πšŠπšŒπš’πšπš’ is the presence weight of the entire surface

In my opinion choosing presence would improve the readability of the parameter. coverage is another alternative if presence isn't appropriate for some reason.

Hi Andre,

I'm not sure I see the issue with terming the parameter "opacity". As we state in the spec:

image

So we do explicitly point out that the opacity/alpha is functioning as a presence weight, according to what the statistical mix operator is supposed to mean.

It's true that the transparency generated is not due to varying volumetric absorption in a finite width slab of material, rather it is due to microscopic holes in the thin surface. I think both situations are correctly interpreted as opacity/transparency though. (You could perhaps think of it as corresponding to the thin-wall limit of an absorbing slab, with a constant optical depth tau such that transmittance = exp(-tau) = 1 - opacity).

Also, in the thin-walled case, we do say that the geometry_opacity functions explicitly as a fractional value, i.e. specifying 1 minus transmittance (so not just a {1, 0} valued signal for cutouts):

image

In my experience, artists from the video game industry will expect to have an "opacity" parameter, and would likely be confused at a "presence" parameter.