Odd Coverage buffer result from pBSDF SSS render...

[jwiede]

Okay, I'm still poking at the odd SSS scene's results (scene attached), and in the process ran across something odd in the Coverage buffer. Maybe I don't understand the Coverage buffer expected behavior, but what I'm seeing in this case certainly seems incorrect...

Here's the SSS final render again, not much light but it's just a big cube with the same SSS surface on all polys:



The Alpha buffer output is just what I expected:



However, the Coverage buffer looks like this:



That looks incorrect to me. There's only one object and only one surface present, so I'd expect the background to be one solid color, and the cube to be a different solid color -- because it's just one object with one surface (the default surface). That the Coverage buffer instead is showing a solid color at the edges of the cube fading to a _different_ solid color (white) in the center seems completely wrong to me, because there's only one surface on the cube.
Scene attached:

odd_sss_2018.zip

(edit) Oliver pointed out that only the R channel of the Coverage pass contains valid data. B & G appear to contain unrelated data, and that was causing the odd result. As I mention below, I'm still likely to file this as a bug -- if they're only populating R channel with valid data, then IMO, they should _zero out_ B & G, not leave unrelated data in them.

[oliverhotz]

cause you looking at color.. just use the red channel

[jwiede]

cause you looking at color.. just use the red channel

Seriously, they only encode it in the R channel, and leave G & B filled with unrelated garbage?

That's... annoying. Oh well, good to know, thanks!

I'm still probably going to file as a bug, because at the least, they should clear B & G if they're only putting valid data in R.

[oliverhotz]

to be honest, it took enough fighting to get the coverage buffer in there as it is...

in fusion, you'll notice its only a single channel thats being used for the coverage pass.

due to its nature, its only really of limited use (although when you NEED that limited use, its life saving).... Once Michael Wolf finishes Cryptomatte, those worries will finally be gone once and for all. Until then, you have my AOV passes already.

[jwiede]

to be honest, it took enough fighting to get the coverage buffer in there as it is...

Point taken, but still worth doing in the most efficiently-usable / discoverable form. Worth doing, and worth doing right.

People here are getting WAY too accommodating of issues and incomplete work -- lowering standards only encourages further decline and attrition, it's the exact opposite of what's needed to turn things around.

[oliverhotz]

People here are getting WAY too accommodating of issues and incomplete work

be very careful with what you assume..

[lardbros]

Definitely report it!!
I noticed this the other week, and it's pretty annoying.

Also, the Object ID buffer doesn't record its ID's in integer values correctly, as AE doesn't see them.
Using EXR trader DOES work in AE... so LW needs to fix it's object ID pass too

[jwiede]

Filed as LWB-4198.

[dpont]

I don't think that green and blue channel of Coverave Buffer are totally useless (until you haven't cryptomatte)
the green is a normalized Depth Buffer and the blue is a normalized Object ID Buffer.

Given a front object with heavy motion blur over a second object,



You get this object ID Buffer,



isolating the first/front object ID from this buffer,



the red channel of Coverage Buffer is here,



combining them you get… a bad mask,



now isolating the object ID from the blue channel of Coverage



(not easy because it is arbitrary normalized, here 1/15) you get,



combining with red Coverage channel you get a cool mask,



Very tricky and only available for first front object, not for the sphere,
but perfectly anti-aliased and blurred.



Denis.