pyro shader gamma?

   6450   1   0
User Avatar
Member
1533 posts
Joined: March 2020
Offline
hey hi
guess this question goes to Mario..
just curious, was the pyro shader designed to work(viewed)at sRGB or gamma 1? i would imagine it 2.2?
If i set my gamma to 1, the alpha and the rgb seem match up.
At gamma 2.2, the rgb falloff is much broader than the alpha.
or should we not premult smoke passes?

jason
HOD fx and lighting @ blackginger
https://vimeo.com/jasonslabber [vimeo.com]
User Avatar
Member
941 posts
Joined: July 2005
Offline
Hi Jason,

Just in case this is just a viewing problem, let me first mention that if you're comparing the rgb and alpha values in mplay, then you should keep in mind that the viewing gamma (the gamma value you set in mplay) is *not* applied to the alpha channel – just the rgb. So if you set gamma>1 (in mplay) and then flip between rgb and alpha to compare, you might wrongly conclude that their falloff rates are wildly different (they *are* in the viewer – mplay is correcting rgb but not alpha – but not in the actual image).

With that out of the way, I'd say yes, you probably want to be viewing your renders (and adjusting your shading) at gamma=2.2 (or whatever correction mimics the final display device). If you want to check how the volume will composite (i.e: check how its opacity+rgb levels play with background objects), then render a background object as well (const-colored plane, whatever).

Now to the shader…

I'm pretty sure the shader isn't doing any tone mapping or other color-space manipulations. It works in “linear” space to the extent that all the inputs are used directly, without any correction – so I guess a more correct statement would be to say that it *assumes* linear space, like every other shader I know of.

Light intensity arriving at a microvoxel is used directly as reported by Mantra, and attenuated (or “premultiplied” if you like) by the fragment's opacity (1-exp(-k*density*dPdz)) which I believe is the correct composition in a ray-marching context. It also ensures that the fragment's opacity ends up in the expected range (which is guaranteed if ‘k’, ‘density’, and ‘dPdz’ are >=0, and which the shader goes out of its way to enforce).

Radiance, however, has no upper-limit applied to it (the shader only enforces that it be non-negative). This means that the “luminance(RGB)” of the result is allowed to have a higher value than the Mantra-composited opacity (or the Alpha of the final image). This (rgb>alpha) is guaranteed to happen when there is emission (directly from fire, or indirectly from the scattering), or when the sum of intensities of all the lights illuminating a fragment is >1… and there are probably other cases I'm forgetting. However, it's expected, not an error.

So… no, there's no “gamma correction” going on with any of the inputs (tone-mapping of the black body intensities excepted, since that doesn't apply here). At least, not that I remember

Hope that makes sense.
Cheers.
Mario Marengo
Senior Developer at Folks VFX [folksvfx.com] in Toronto, Canada.
  • Quick Links