[Bf-committers] Z Combine and other Z things (Was Re: Z values in key render mode)

[GSR]

Hi,
gsr.b3d at infernal-iceberg.com (2006-11-03 at 1922.52 +0100):
> Any tip or patch to change the current style, in which z values are
> not filled for all values where there is colour and alpha are above
> 0.0 (iow, non black and transparent)?

Found my own way: interpolation of z for those pixels, based in
neighbour pixels, doing a recursive processing. Probably worth make a
separate node that uses it, as the function supports extra offset and
z forcing for isolated pixels, and is useful for any task that uses z
and wants antialiased edges. Only issue, other than inventing the data
from the depths around, is that it process 1 pix border of the image
in a different style.
 
> Currently the last pixel or two around everything gets a very high z
> value while still having colour and alpha data, so combining two
> renders gets jaggy edges if you are using a z based method for the
[...]

And that shows in z combine node. Which lacked z result, btw. It looks
nasty as is, no intersection smoothing and the second image (right
monkey) gets jaggy edges "for free".
http://www.infernal-iceberg.com/blender/nodes/zcombine-0.png

Some trickery later, intersections and edges look smoother, with a
reduced set of conditions. Right monkey got better edges from a
different comparator rule.
http://www.infernal-iceberg.com/blender/nodes/zcombine-1.png

Let's add the z interpolator, it makes intersection look thick in some
parts as the alpha is not used. It would had fixed smooth edges of
right monkey if the rule had not taken care of it already.
http://www.infernal-iceberg.com/blender/nodes/zcombine-2.png

What if it supports alpha too? Non refractive glass becomes possible.
http://www.infernal-iceberg.com/blender/nodes/zcombine-3.png

Marks of which pixels need extra work (still figuring a pleasant
looking mixer function for when transparent surfaces are involved).
http://www.infernal-iceberg.com/blender/nodes/zcombine-4.png

Marks for a slight variation of the conditions, what I call "only
front surface expands over back one".
http://www.infernal-iceberg.com/blender/nodes/zcombine-5.png

And after some tweaking, and using the double line area as in 4 to
decide what is recomputed, something that is more or less final.
http://www.infernal-iceberg.com/blender/nodes/zcombine-6.png

As part of the experiments, I added output of the z value which
comment in code said to be done, but no code was doing it. This allows
output to be combined with other images via another z combine node,
without having to use a mix node for z data. Also removed need of z
interpolators, no matter if they get added or not (less clutter in
general).

Extra findings: Blender's compositor is premul type, not key. And
Blender gets key by dividing the result by alpha (iow, the raw render
is premul, look for convert_to_key_alpha function). Other nodes also
treat the borders of the image specially, so rendering with bleed area
is a good idea, not a pure waste of cycles.

Next thing is the z fix/expand node and maybe control to select if AA
is performed (compat... if people has used z combine as it was,
otherwise maybe not worth).

https://projects.blender.org/tracker/index.php?func=detail&aid=5189&group_id=9&atid=127

GSR