Help save net neutrality! Learn more.

Bugs with AOV

  • AKHmetgaleev ILdar

    please check my example scene

    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 all AOV disapears.


    Fell free to reuse this shader. - this is rendered sky after compositing.

    • George Harker

      George Harker - 2007-05-07

      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.



      • Moritz Moeller

        Moritz Moeller - 2007-05-10

        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.



        • George Harker

          George Harker - 2007-05-11

          Thanks Moritz,

          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



    • George Harker

      George Harker - 2007-05-07

      Hi AKHmetgaleev,

      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.




Log in to post a comment.