Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

Bugs with AOV

2007-05-07
2013-04-25
  • Hi!
    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.

    Thanks!

    Fell free to reuse this shader. http://akhil.nightmail.ru/path/skytest_composed-512.ogg - 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.

      Cheers

      George

       
      • 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.

        Cheers,

        Moritz

         
        • 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

          Cheers

          George

           
    • 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.

      Cheers

      George