transmission/translucent volume parametrization
portsmouth opened this issue · comments
@brechtvl wrote:
The way transmission_color and transmission_scatter work I believe is not easy to control if I remember correctly. I did some tests regarding this in the past, with the main issue that density and color are not controlled independently this way, which makes it harder to tweak and texture. Some images of that.
The parameters I used to try to solve that work as follows:
scattering_coefficient = density * transmission_scatter_color
absorption_coefficient = density * max(1 - sqrt(max(transmission_absorption_color, 0)), 0) * max(1 - transmission_scatter_color, 0)
This deserves a separate discussion. We had much discussion on the OpenPBR Slack about the best parametrization previously, and didn't settle on a solution.
One reasonable behavior of the stated formulas in the current document (which is the current Arnold implementation) is that the color of the transmitted light and the scattered light is specified roughly independently. Whereas if one makes transmission_scatter equal to the scattering albedo color, this doesn't work since then if e.g. transmission_color is red (=> cyan extinction) and transmission_scatter is white, the scattered light is cyan, which is weird. Though as noted in your link, it's unintuitive that transmission_color also affects the density, agreed
@brechtvl wrote:
The Blender parameters I think are different from what has been discussed in this channel earlier. The absorption color in Blender does not affect the scattering coefficient, and so does not have the cyan scattered light problem. It only affects the remaining non-scattered light.
I'm not that keen on the proposed approach, since:
- the transmitted color is no longer specified directly, instead it depends on both the
transmission_scatter_colorandtransmission_absorption_color - as
transmission_absorption_color-> 1, absorption coefficient -> 0 (so extinction coef. = scattering coef.). Then the transmitted color will actually be complementary totransmission_scatter_color(e.g. redtransmission_scatter_color, whitetransmission_absorption_colorwill produce cyan transmission, and cyan was not asked for) - it's a bit ad-hoc and the
transmission_absorption_colordoesn't have a clear physical meaning as an observable color.
Instead if we use the Arnold approach of:
- 1 MFP (scale) is defined by
transmission_depth(or 1/transmission_density) transmission_color= RGB transmittance at 1 MFPtransmission_scatter= RGB scattering coef. * 1 MFP
the observed transmitted and scattered colors are as specified (at 1 MFP depth, with the usual caveats about multi-scatter), with no complementary color. (Actually, not quite, since the extinction has to be fixed up if scattering coeff. > extinction coeff. But at least this only adds grey extinction).
The only issue is that it's potentially confusing that the volume disappears as transmission_color -> 1. (Because transmittance=1 implies zero extinction or infinite MFP). If we can set transmission_color < 1 by default, that gets rid of that issue mostly.
We could do that if we either a) get rid of the transmission tinting special case completely, or b) have a non-physical transmission_tint specifically for that. My preference is a), and require users to use thin-walled to get this tinting behavior (which is the physically based way).
@brechtvl wrote:
My opinion is that the extinction coefficient is not an intuitive thing to specify, so doing that directly is not a goal.
-
The idea is that these cases with unexpected colors are harder to encounter. If you set a red scattering color, change the absorption color from the default black to white, and have a lighting setup where the light coming behind the object dominates over the scattered light, then indeed you get cyan tint on the light coming from behind. I think it's unavoidable to have something like that happen with any parametrization, but I would argue it's more rare like this.
-
The
transmission absorption colorI would consider like edge tint for metals, an artistic parametrization, with all the pros and cons associated with that.
Though the existing parametrization I think doesn't specify extinction directly, it specifies transmittance and computes extinction via the log (i.e. basically the artist sets the observable transmitted color given white incident light). So:
the observed transmitted and scattered colors are as specified (at 1 MFP depth, with the usual caveats about multi-scatter), with no complementary color.
Though it does require adding grey to the absorption internally (as scatt. coeff. cannot exceed extiction coeff.), so the color will shift somewhat, but mostly just a desaturation.
If you mean that it's actually unintuitive to specify the transmittance, maybe so, e.g. a white transmittance produces no volume (because that is the only way to get the white transmission color asked for). We can mitigate that by making the default transmittance grey instead. Speculatively, the color could be separated into a hue and opacity control, or possibly the components remapped to say [0.0, 0.5] range so the volume cannot be removed via the color alone.
If you set a red scattering color, change the absorption color from the default black to white, and have a lighting setup where the light coming behind the object dominates over the scattered light, then indeed you get cyan tint on the light coming from behind. I think it's unavoidable to have something like that happen with any parametrization, but I would argue it's more rare like this.
Is it though, since the Arnold formulas (as stated below, taken from the current spec) don't seem to produce a complementary color at all?
The
transmission absorption colorI would consider like edge tint for metals, an artistic parametrization, with all the pros and cons associated with that.
Certainly it's on the table to produce some more artist-friendly parametrization that is not directly associated with the physics, though it should have the property I think that it reproduces well the artist intent (i.e. the specified colors and density), which I'm not convinced (yet) the particular form given does (or at least, not better than the one given in the spec -- apart from the issues around the unintuitive white transmission == no volume). e.g. Is there a rationale behind the sqrt appearing, or it just seemed to work well?
@peterkutz wrote:
From my experience different volume parameterizations work best in different scenarios and have various tradeoffs so it's hard to select only one or two for the model. We can keep exploring the best options.
We seem to have settled on the existing parametrization described in the spec, for the time being, so suggest to close this.