Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
please check my example scene http://akhil.nightmail.ru/sky_AOV_bug.tar.bz2
First bug in sky-STILL.rib. FrameBuffer shows float variables with artifacts. It doesn't affect to other displays such as openexr.
Second bug more destructive. When Opacity in objboxes/sky-STILL.rib line 10 not equal (1, 1, 1) (line 95 in skydome.sl) all AOV disapears.
Fell free to reuse this shader. http://akhil.nightmail.ru/path/skytest_composed-512.ogg - this is rendered sky after compositing.
The first (framebuffer) bug is fixed, adn only affected 1-channel displays.
In terms of the second issue, I think we only emit AOVs for non tranparent surfaces. This might well be wrong. I'll investigate this.
Actually, AOVs do get alpha composed, which is why you have to premult them in the shader (to get the "correct" result). A fully transparent object, if using premultiplied AOVs will indeed not contribute. However, if the user chooses to not premultiply a particular AOV, it will get added up, as one would expect (and as is Ci, see the lensflare shader in ARMan for some use for this). And since Oi is varying and can be overwritten in the shader, even if the user sets Opacity 0 0 0 in the RIB, this can never be used to decide to switch an object off.
This is also one of the biggest shortcomings of AOVs in RMan, as far as I am concerned: the lack of a pre-AOV, per-channel alpha (basically an Oi for each AOV). The other shortcomings are addressed well currently only by 3Delight with "exclusive" AOVs and some other stuff, no available in a release yet. Although I heard an upcoming PRMan version will have similar stuff.
I've just finished code which will have color AOVs opacity composite properly - which is what you're referring to. All of Akhil's AOVs were float or vector, which we will not opacity composite - I believe this is the same for PRMan (compositing a vector doesn't make sense).
We don't have per-channel alpha for AOVs yet - but it is a good idea. Currently we're compositing colors down with Oi - though that is a good sensible default.
So what the planned / current svn implemention will do for color aovs - assuming a shader outputs CoutAmbi (raw, not modulated by Oi) is:
frontmost transparent sample: CoutAmbi_frontmost
second transparent sample: += (1-Oi_frontmost)*CoutAmbi_second
Third transparent sample: += (1-Oi_frontmost)*(1-Oi_second)*CoutAmbi_third
and so on
Which I think matches? Is that right?
The separate alpha per channel is a good idea though
Previously we intentionally did not emit AOVs for transparent objects. Though perhaps this is not the most useful implementation.
Now AOV's will now be output for transparent objects. The frontmost object only (reguardless of transparency) will contribute it's AOV to the output channel. AOVs will not be alpha composited - this can be done later in a compositing package.
I believe this behaviour matches PRMan - though I will need to test it.