AcademySoftwareFoundation
Add emission_weight
After some discussion internally (with @ZapAndersson), we feel that the emission controls would be improved if:
- we add an
emission_weightparameter in [0,1], that multiplies the luminance, defaulting to 0. - we make the
emission_luminancedefault to 1000 nits.
Currently, instead we have:
- no
emission_weight. emission_luminancedefaults to 0.
The issue with this is that some DCCs (e.g. 3ds Max) don't have the concept of a "soft-range", so the emission_luminance has to be a constant or spinner.
It's more convenient for there to be a simple [0, 1] emission_weight modulating the luminance which can be controlled via a slider (and also textured with a [0, 1] mask). Also this is more consistent with the other "lobes" which all have an associated weight dialing the strength of the effect.
Adding this weight defaulting to 0, then allows the emission_luminance to default to the (reasonable) 1000 nits value, rather than having this value merely be the soft-max (which as noted some DCCs don't support).
Adding an emission_weight makes the parametrization more symmetrical with the other lobes, and adds an easy to map parameter controlling a harder to map physical quantity.
An issue with making the emission_luminance 1000 by default is that if that makes it into 1.2 for exemple, then rendering the node in 1.1 all shapes would be emissive, so versioning would need to be done very carefully.
Perhaps MaterialX can handle this versioning for us via its shader translation graphs. It would be good to be able to make such small improvements (at least, in this initial refinement phase) without having to avoid it due to lack of a versioning system.
To facilitate writing such version translation logic, it would be quite helpful to also keep track of the detailed changes between each version, in some reference document.
@AdrienHerubel @portsmouth That matches my current thinking, that upgrades from earlier OpenPBR versions should be handled through the MaterialX versioning system (for lossless upgrades such as this one) and shader translation graphs (for any lossy upgrades that may be proposed in the future). As Jamie notes, it will be important to allow improvements to OpenPBR over time, without restricting ourselves to changes that are purely backwards compatible by design.
Implemented in https://github.com/AcademySoftwareFoundation/OpenPBR/pull/231