Results 1 to 9 of 9

Thread: Odd Coverage buffer result from pBSDF SSS render...

  1. #1
    Electron wrangler jwiede's Avatar
    Join Date
    Aug 2007
    Location
    San Jose, CA
    Posts
    6,613

    Question Odd Coverage buffer result from pBSDF SSS render...

    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:

    Click image for larger version. 

Name:	Final_Render_000.png 
Views:	31 
Size:	1.43 MB 
ID:	142155

    The Alpha buffer output is just what I expected:

    Click image for larger version. 

Name:	Alpha_000.png 
Views:	24 
Size:	4.2 KB 
ID:	142154

    However, the Coverage buffer looks like this:

    Click image for larger version. 

Name:	Coverage_000.png 
Views:	36 
Size:	655.1 KB 
ID:	142153

    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.
    Last edited by jwiede; 07-08-2018 at 08:22 PM.
    John W.
    LW2015.3UB/2019.1.4 on MacPro(12C/24T/10.13.6),32GB RAM, NV 980ti

  2. #2
    cause you looking at color.. just use the red channel
    Oliver

    OD Tools Purchase Link: http://origamidigital.com/cart
    Vimeo Channel: https://vimeo.com/channels/850417
    Join ODRoot - https://www.odroot.com

  3. #3
    Electron wrangler jwiede's Avatar
    Join Date
    Aug 2007
    Location
    San Jose, CA
    Posts
    6,613
    Quote Originally Posted by oliverhotz View Post
    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.
    Last edited by jwiede; 07-08-2018 at 08:17 PM.
    John W.
    LW2015.3UB/2019.1.4 on MacPro(12C/24T/10.13.6),32GB RAM, NV 980ti

  4. #4
    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.
    Oliver

    OD Tools Purchase Link: http://origamidigital.com/cart
    Vimeo Channel: https://vimeo.com/channels/850417
    Join ODRoot - https://www.odroot.com

  5. #5
    Electron wrangler jwiede's Avatar
    Join Date
    Aug 2007
    Location
    San Jose, CA
    Posts
    6,613
    Quote Originally Posted by oliverhotz View Post
    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.
    John W.
    LW2015.3UB/2019.1.4 on MacPro(12C/24T/10.13.6),32GB RAM, NV 980ti

  6. #6
    Quote Originally Posted by jwiede View Post
    People here are getting WAY too accommodating of issues and incomplete work
    be very careful with what you assume..
    Last edited by oliverhotz; 07-09-2018 at 06:24 PM.
    Oliver

    OD Tools Purchase Link: http://origamidigital.com/cart
    Vimeo Channel: https://vimeo.com/channels/850417
    Join ODRoot - https://www.odroot.com

  7. #7
    Not so newbie member lardbros's Avatar
    Join Date
    Apr 2003
    Location
    England
    Posts
    5,875
    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
    LairdSquared | 3D Design & Animation

    Desk Work:
    HP Z840, Dual Xeon E5-2690 v2, 32GB RAM, Quadro K5000 4GB
    Desk Home:
    HP Z620, Dual Xeon E5-2680, 80GB RAM, Geforce 1050 Ti 4GB

  8. #8
    Electron wrangler jwiede's Avatar
    Join Date
    Aug 2007
    Location
    San Jose, CA
    Posts
    6,613
    Filed as LWB-4198.
    John W.
    LW2015.3UB/2019.1.4 on MacPro(12C/24T/10.13.6),32GB RAM, NV 980ti

  9. #9
    Member
    Join Date
    May 2006
    Location
    France
    Posts
    4,085
    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,

    Click image for larger version. 

Name:	color_image.jpg 
Views:	6 
Size:	24.2 KB 
ID:	146248

    You get this object ID Buffer,

    Click image for larger version. 

Name:	all_object_id.jpg 
Views:	5 
Size:	12.0 KB 
ID:	146249

    isolating the first/front object ID from this buffer,

    Click image for larger version. 

Name:	first_object_id.jpg 
Views:	5 
Size:	12.7 KB 
ID:	146252

    the red channel of Coverage Buffer is here,

    Click image for larger version. 

Name:	coverage_red.jpg 
Views:	5 
Size:	18.0 KB 
ID:	146251

    combining them you get… a bad mask,

    Click image for larger version. 

Name:	bad_object_mask.jpg 
Views:	7 
Size:	12.7 KB 
ID:	146256

    now isolating the object ID from the blue channel of Coverage

    Click image for larger version. 

Name:	coverage_all_id.jpg 
Views:	5 
Size:	7.5 KB 
ID:	146250

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

    Click image for larger version. 

Name:	coverage_id.jpg 
Views:	4 
Size:	11.7 KB 
ID:	146253

    combining with red Coverage channel you get a cool mask,

    Click image for larger version. 

Name:	coverage_mask.jpg 
Views:	7 
Size:	12.0 KB 
ID:	146254

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

    Click image for larger version. 

Name:	dpfilter_coverage.jpg 
Views:	7 
Size:	211.2 KB 
ID:	146255

    Denis.

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •