#ALPHA CHANNEL
That's my question as well. Those Alpha Channel buttons in the Yost IPAS
Boutique #1 .IXPs (Flare, Hilite, Glow, Blur, etc.) appear to be utterly
useless. Here's why: the instructions SAY that they will look at the Alpha
Channel of the item above them in the Video Post queue, assuming that said item
is 32-bit (has an Alpha channel) and that Use Alpha is On. This is apparently
not the case. Apparently they instead look at the ACCUMULATED Alpha of ALL the
Video Post queue entries above the .IXP entry whose timelines overlap at that
frame. In other words, they look at the Alpha channel of the CURRENT
COMPOSITED IMAGE being built, as it has been composited through the various
layers!
The problem is, ANY PIXEL THAT ISN'T BLACK in the accumulated composited
image is going to have an Alpha value greater than 0, or else it WOULD be
black! Solids and Gradients have completely white Alpha. KF Scenes have Alpha
according to transparency and anti-aliasing, with the non-edge faces of
non-transparent materials being white, and areas with no geometry at all (or
nothing but 100% transparent, i. e. invisible, objects) being black. Bitmap
layers may or may not have their own Alpha, but when they do, any portion of
the bitmap with no alpha doesn't show up, and for anything TO show up at those
pixels there must be pixels with positive alpha in preceeding layers — which
then get accumulated into the total Alpha layer of the composited image!
This sequence should make it plain:
Video Post Begins with all pixels set to R, G, B, and A of 0, 0, 0, and 0.
No color, no alpha of any kind. Thus:
PIXEL 1 PIXEL 2 PIXEL 3 PIXEL 4 PIXEL 5 PIXEL 6
RGB ALPHA RGB ALPHA RGB ALPHA RGB ALPHA RGB ALPHA RGB ALPHA
—————————————————————————–
Starting: 0 0 0 0 0 0 0 0 0 0 0 0
+ Bitmap: 0 0 >0 >0 >0 0 >0 >0 0 >0 0 0
—————————————————————————–
= Subcompst.: 0 0 >0 >0 0 0 >0 >0 0 >0 0 0
+ KF Scene: >0 >0 0 0 >0 >0 0 >0 0 0 0 0
—————————————————————————–
= Composite: >0 >0 >0 >0 >0 >0 >0 >0 0 >0 0 0
As you can see, any pixel in any layer with 0 Alpha will not be composited
into the image being built. If the corresponding pixel before was also 0
Alpha, then that pixel will still be black, since the only way it could be 0 is
if there were no Alpha anywhere in the chain since the Starting All-Black All-0
Alpha image. The RGB of those pixels in the layers has no bearing since
without Alpha they won't even be taken into account!
So you see, the "=0" and ">0" Alpha buttons in these .IXPs are all but
utterly useless. At least, I haven't been able to find a use for them.
To make matters worse, these routines not only have no usable Alpha to key
off of, but they also don't GENERATE Alpha. The points of hilights generated
by HILITE.IXP, for instance, are lightened by varying amounts as far as the RGB
goes, but the Alpha of those pixels aren't at all changed. This means there is
no way to have Hilite affect only the objects in a 32-bit Bitmap or KF Scene
and yet have the points of the Hilite be transparently visible whenever the
points go over the background (0 Alpha of the previous layer). Ditto for the
effects of FLARE.IXP, GLOW.IXP, etc.
I've verified all of this by using Alpha-Split and viewing the Alpha files
produced at each stage of Video Post directly. Both that there is no usable
Alpha for .IXPs to key from, and that the Yost Boutique #1 .IXPs don't generate
their own Alpha even if Alpha is On.
We REALLY NEED these things to be fixed. For now, I would settle for having
the Yost #1 .IXPs upgraded to generate Alpha, as the other problem can be
worked around (albeit tediously) by splitting Video Post jobs into multiple
jobs. Has this other problem been fixed in Release 4's Video Post? Or are
both of these problems being caused by something else, such as by some obscure
setting in 3DS.SET?