Thanks Jonathan. After your answer and a bit of reading on the subject, I realised I had this even more backwards than I thought. :)
For starters, I was under the impression that FillMat was doing blending when setting its alpha < 1, but it's not. It's just setting the out pixel as you said. Also, I ignored that, when fragment_shader is called, the "out" pixel is already filled with the values of that fragment thus far. Thanks again for the valuable info. Cheers, Ivan On Mon, Jul 11, 2011 at 1:15 PM, Jonathan Egstad <[email protected]> wrote: >> ... the VertexContext in fragment_shader() seems to ignore that (or it's >> being overridden by something else). For now, I've been doing this in >> fragment_shader(), but I don't know if that's good practice, or if I should >> be doing that differently. > > Cf represents the vertex color only, and is only supported by default when > you set a GeoOp's render mode to 'solid'. Under the hood the Primitive class > assigns a SolidShader (Material.h) to the render primitive and that shader > colors the Primitive with Cf's value. > > >> Also, this raises another question for me. Even if I can get the color I >> want into the "out" Pixel, what should I do for the renderer to take into >> account opacity? If I set my out Pixel to have an alpha of 0.5, it does >> render out with an alpha of 0.5, but any objects behind are still fully >> occluded. However, Fillmat seems to do what I would like to. What does >> FillMat do to set its color and opacity? > > FillMat directly sets the output Pixel and will overwrite a blend done by a > shader on it's input. > > You can either allow the renderer to do the final fragment blend itself (it's > actually the default Iop::fragment_shader() that does this, not the renderer > per-se) or take over the blend in your shader by manipulating > VertexContext::blending_shader. > If you set blending_shader to you're Iop/Material's pointer at the start of > fragment shader then you 'take ownership' of the blend stage and if the > shaders on your input honor the blending_shader var they shouldn't do a > blend. It then up to you to do the over, or whatever combine math you want > to the output pixel. > > Because the output pixel *is* the final result that goes into the output Row > and the fragments are called in order from back-to-front (assuming > 'ztest_enabled' is on in the renderer,) you can do any combine math you want. > It's done this way so that things like shadow channels can be max-ed > together rather than over-ed. You need to call your input's fragment shader > with a different Pixel that will contain the FG value, then do your blend > math to the output Pixel you were passed. At the start of the shader tree > the output Pixel will contain the background image fed into the renderer. > > I never came up with a better scheme to make this easier, and Renderman > co-shaders suffer from the same blending-context issue. > > -jonathan > > _______________________________________________ > Nuke-dev mailing list > [email protected], http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev > _______________________________________________ Nuke-dev mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
