Add diagnostic AOV for invalid samples

[luisbarrancos]

Sometimes, specially with bigger shading networks and bigger scenes, it can be quite tricky to find out which shader(s) is generating NaN/Inf/invalid samples.
An diagnostic pass for this explicit purpose would help tremendously in pinpointing the misbehaving culprit.

[oktomus]

In the final exported AOVs, how do you know which shader is failling ? Do we export an AOv per shader ?

[dictoon]

@oktomus We don't export an AOV per shader. There is no easy way to know which shader caused invalid samples. However having a map (an AOV) that shows in which pixels did NaN/inf/negative samples occur would be enough I think. @luisbarrancos can you confirm this?

[luisbarrancos]

That is correct, just having fast visual feedback for inf/NaNs would suffice.

…

On Mar 1, 2018 9:39 PM, "François Beaune" ***@***.***> wrote: @oktomus <https://github.com/oktomus> We don't export an AOV per shader. There is no easy way to know which shader caused invalid samples, just having a map (an AOV) that shows in which pixels did NaN/inf/negative samples occur would be enough I think. @luisbarrancos <https://github.com/luisbarrancos> can you confirm this? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1815 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAXpGAep8ByvDin4NfXve5tqIWu1a6oqks5tZ_ojgaJpZM4RvMOb> .

[luisbarrancos]

Currently we have a object ID shader. What do you think about using this as a base or something similar, but rescaled so that it's within [0, 0.25] or [0,0.33], in order to provide some measure of background on which to overlap the invalid samples? This would give immediate feedback on which invalid samples were occurring, and from here we can go to any DCC app and inspect the shader networks (and resp. shaders) associated with it. Does something like this makes sense?

[dictoon]

It's an interesting idea yes, so the original render in the background (darkened) and invalid samples marked in e.g. bright pink on top?

[oktomus]

Why adding the original render in the background ? We can save both the rendered image and the diagnostic AOV.

[dictoon]

I agree and I'm slightly split about this, but I guess it's out of convenience: with a single image you can see where there are invalid samples in the render, you don't have to overlay two images (original render + diagnostic AOV). I'm fine with either solution: one is more convenient, the other is more orthogonal.

[luisbarrancos]

It was for convenience really, but then again, we can just toggle the aov back to object id, or beauty pass, back to invalid samples. Is there anything else we could include in such a samples AOV that would warrant further attention? I.e., normalized samples budget used on G channel, invalid samples on R channel? Or any other diagnostic quantity of use?

…

On Mar 1, 2018 11:58 PM, "François Beaune" ***@***.***> wrote: I agree and I'm slightly split about this, but I guess it's out of convenience: with a single image you can see where there are invalid samples in the render, you don't have to overlay two images (original render + diagnostic AOV). I'm fine with either solution: one is more convenient, the other is more orthogonal. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1815 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAXpGCiTXsUKlLaxzASU-sRvTYBMR41wks5taBqTgaJpZM4RvMOb> .

[oktomus]

I have another question @luisbarrancos, how do you get the shader network from only the object id? Sorry if it sounds stupid, but I'm wondering..

[luisbarrancos]

@oktomus np, but i meant if we had an image, visual cues to the objects (i.e, data from object IDs in one channel, dimmed), and the invalid samples in other channel, then we would immediatly have a visual idea of where the samples are in regard to the object. It would then be a matter of going into the DCC app (Max, Maya, Blender, whatever), and selecting the object where the invalid samples were placed, and seeing what shaders/shading networks were instanced with that object. From there we would already know one of the nodes was the culprit for producing the invalid samples, it would make things easier to debug.

This in the OSL case, where you have potentially complex shading networks. With appleseed materials, it would be the same principle, except instead of OSL networks or single shaders, we would have a visual cue for the potentially problematic BxDF attached to the object.

[oktomus]

Ok I understand, thanks :)

[oktomus]

So we finally go with a unique diagnostic AOV containing 20% of the luminance in R+G+B or bright pink if the sampling failed.

[oktomus]

Done.