<div dir="ltr">From the kernel point of view, the clear point to write deep EXR would be <font face="monospace, monospace">kernel_write_data_passes and kernel_write_light_passes </font><span style="font-family:arial,helvetica,sans-serif">The tricky part though is how to store them though, we currently assume pixel buffers of fixed size in the Blender render API, compositor, image APIs, Cycles host and device side buffers, etc. So it's a big undertaking to implement that throughout the entire pipeline. </span><span style="font-family:arial,helvetica,sans-serif">The easier solution is to write to a fixed number of passes, like Cryptomatte (see </span><font face="arial, helvetica, sans-serif"><a href="https://developer.blender.org/D2106">https://developer.blender.org/D2106</a> for a proof of concept implementation). That avoids a lot of the trickiness of each pixel having an arbitrary number of samples.</font></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jul 29, 2017 at 7:01 PM, Dylan McDiarmid <span dir="ltr"><<a href="mailto:dylanmcd@gmail.com" target="_blank">dylanmcd@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="#954F72"><div class="m_-3593421420916932329WordSection1"><p class="MsoNormal">Thank for the info, Brecht. I’ll keep the downsampling solution as a last resort, and try implementing a pass that gives me enough information to do the compositing operations in post. I don’t need to support blur or DOF, but overlapping transparency is a possibility I didn't think of. </p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Now that I know I’ll need to hack this together, I’ll work on getting a good development environment setup and familiarizing myself with the code. If Blender did support deep EXR, what would your high-level strategy be for implementing this feature for a solo object render? Is there a single place where the UV Pass is written, or is this something that happens from multiple places?</p><p class="MsoNormal"> </p><div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0in 0in 0in"><p class="MsoNormal" style="border:none;padding:0in"><b>From: </b><a href="mailto:brechtvanlommel@pandora.be" target="_blank">Brecht Van Lommel</a><br><b>Sent: </b>Friday, July 28, 2017 8:03 PM<br><b>To: </b><a href="mailto:bf-cycles@blender.org" target="_blank">Discussion list to assist Cycles render engine developers</a><br><b>Subject: </b>Re: [Bf-cycles] UV Pass and Self Overlap</p></div><div><div class="h5"><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal">There is currently no good way to output such information. Rendering in a high resolution and then scaling down may be the best way to try to recover this information. Modifying the code to write only the first sample might help with that, like we do for the Z pass.</p><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">In general it's not just "top" and "bottom", but rather an arbitrary number of objects that might contribute to a pixel, either due to antialiasing, transparency, depth of field or motion blur. A better solution to this is deep EXR, which we do not support currently.</p></div></div><div><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal">On Thu, Jul 27, 2017 at 9:25 AM, Dylan McDiarmid <<a href="mailto:dylanmcd@gmail.com" target="_blank">dylanmcd@gmail.com</a>> wrote:</p><blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt"><div><div><p class="MsoNormal" style="margin-left:4.8pt">I'm doing some work that involves mapping textures post-render, and I'm trying to figure out how to get anti-aliasing information out of the UV pass. From the UV pass EXR, it looks like for edges that overlap the background, we get a nice B value that indicates opacity. So, to find the actual UV position we would do U = R / B, V = G / B, and then do an alpha blend with what we want as the background using the B value.</p><p class="MsoNormal" style="margin-left:4.8pt"> </p><div><p class="MsoNormal" style="margin-left:4.8pt">However, when an object overlaps itself, the B value stays at 1, and instead we get the actual alpha blend of the top R,G with the bottom R,G. So when we're doing our mapping, this puts the UV at a completely wrong place.</p></div><div><p class="MsoNormal" style="margin-left:4.8pt"> </p></div><div><p class="MsoNormal" style="margin-left:4.8pt">To properly represent the antialiasing at places that self-overlap, we need 5 values, bottom U, bottom V, top U, top V, top opacity. I don't know HDR formats very well, are these values already being captured somewhere in some kind of metadata field? If not, is there currently a way to do a separate pass to capture this information?</p></div><div><p class="MsoNormal" style="margin-left:4.8pt"> </p></div><div><p class="MsoNormal" style="margin-left:4.8pt">I've done a bit of poking around to the source, but I'm afraid I've been hindered by a lack of domain knowledge. It seems that the pass information is being read from</p></div><div><p class="MsoNormal" style="margin-left:4.8pt"> </p></div><div><p class="MsoNormal" style="margin-left:4.8pt">kernel_passes.h : kernel_write_data_passes -> geom_primitive.h : primitive_uv -> geom_attribute.h : find_attribute -> kernel_compat_cpu.h: kernel_tex_fetch -> KernelGlobals->__attributes_<wbr>map.fetch(index)</p></div><div><p class="MsoNormal" style="margin-left:4.8pt"> </p></div><div><p class="MsoNormal" style="margin-left:4.8pt">but I'm having trouble figuring out where and when __attributes_map gets filled (and with what, and why :).</p></div><div><p class="MsoNormal" style="margin-left:4.8pt"> </p></div><div><p class="MsoNormal" style="margin-left:4.8pt">As a newcomer to graphics programming, it's a real pleasure to find such a great renderer that I can actual read the source to. So thanks to everyone involved.</p></div><p class="MsoNormal" style="margin-left:4.8pt"> </p></div></div><p class="MsoNormal" style="margin-right:0in;margin-bottom:12.0pt;margin-left:4.8pt"><br>______________________________<wbr>_________________<br>Bf-cycles mailing list<br><a href="mailto:Bf-cycles@blender.org" target="_blank">Bf-cycles@blender.org</a><br><a href="https://lists.blender.org/mailman/listinfo/bf-cycles" target="_blank">https://lists.blender.org/<wbr>mailman/listinfo/bf-cycles</a></p></blockquote></div></div><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal"><u></u> <u></u></p></div></div></div></div><br>______________________________<wbr>_________________<br>
Bf-cycles mailing list<br>
<a href="mailto:Bf-cycles@blender.org">Bf-cycles@blender.org</a><br>
<a href="https://lists.blender.org/mailman/listinfo/bf-cycles" rel="noreferrer" target="_blank">https://lists.blender.org/<wbr>mailman/listinfo/bf-cycles</a><br>
<br></blockquote></div><br></div>