[Bf-cycles] UV Pass and Self Overlap

[Brecht Van Lommel]

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.

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.

On Thu, Jul 27, 2017 at 9:25 AM, Dylan McDiarmid <dylanmcd at gmail.com> wrote:

> 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.
>
>
>
> 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.
>
>
>
> 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?
>
>
>
> 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
>
>
>
> 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_map.fetch(index)
>
>
>
> but I'm having trouble figuring out where and when __attributes_map gets
> filled (and with what, and why :).
>
>
>
> 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.
>
>
>
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> https://lists.blender.org/mailman/listinfo/bf-cycles
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-cycles/attachments/20170729/1c98b644/attachment.htm