Ok well that makes it clear regarding the paint ops.
It threw me off a little when I was getting the desired behavior without using edge blur. I wish it would just sustain the same behavior when blurring.
In general though I do find many situations where I want to control the alpha channel in the same manner as an RGB channel in both the fxTree and the render Tree.
I was quite deflated when I saw a 'different' Mental Ray compatible software package slinging values into each RGB & A channel quite easily.
Maybe there is still a trick to doing this that I've missed. There are many times I just want to pack 4 mattes into one render.
But once again I appreciate your help.
----- Original Message -----
From: Luc-Eric Rousseau <lucer(at)Softimage.COM>
Date: Tuesday, August 29, 2006 12:37 pm
Subject: RE: alphas - was: fxTree - mask shapes
> It's because alpha is used for compositing and generally means
> pixel coverage, or the weight of the color in that pixel, it's not
> an additionnal color channel. It's closely linked to the RGB value.
>
>
> It's equivalent to the opacity channel, which isn't directly
> editable in adobe product.
>
> For the fxtree case, the mask shapes operator is meant to be used
> to produce gray scale matte. When connecting an RGBA image to its
> input, it get into this state where it isn't really a mask shapes
> operator anymore, but a normal color paint node. So it pastes the
> grayscale shape onto the background image, using its mask. The mask
> of the shape is white everywhere there is full pixel coverage, and
> a gradient where partial information, for the antialiasing at the
> edges.
>
> In other words the output of paint is alpha pre-multiplied. If the
> alpha of the shape were zero, it would mean that nothing would be
> painted, i.e. composited on the backgroud. So to paint a black
> shape in the color channel, one must paint a black shape with
> alpha.
>
> That's why you can't use the input of the mask shape operator to
> put black in the alpha channel of a background, you have to combine
> it with the original image with a compositing operator that doesn't
> use alpha for compositing, which is the only behaviour available
> with the paint operators inputs
>
>
> > From: dbarosin(at)optonline.net
> >
> > Thanks Luc. I'll give it a shot.
> >
> > Seems like there should be an option regarding the behavior
> > of the alpha channel.
> >
> > On another note I was having a similar issue with the render
> > tree and alpha channels. If you take a RGBA combine node and
> > plug it into a material you'll see that you have control of
> > the alpha while its rendering (need to have a render region
> > displaying the alpha channel to see this). But at the last
> > moment the alpha pops to white.
> >
> > I appreciate the help.
>
> ---
> Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text
> in body:
> unsubscribe xsi
>
---
Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
unsubscribe xsi
