[PD] GEM: Example blend_mode patch.

B. Bogart ben at ekran.org
Mon Apr 4 23:41:33 CEST 2005


Hi Anton,

I have had a few people complain to me about this. It is due to
render-order. I'm not sure exactly how it works but I've assumed this is
because the render order is specified by each element being drawn, since
the cube has 6 sides I think each of the sides gets a different
render-order. In order to render a cube "normally" we would have to
render the back faces first, which change based on rotation. So for each
frame the render order needs to be re-sorted. (I think this is the same
as Z-buffering?)

I was told by Chris that to add the per-frame sorting would be a real
performance hog. :(

You can tinker with using "depth" which seems to do some strange things,
but you never get the effect your talking about, It does some kind of
off inverting in Z though... just try putting a "depth" in a chain with
a translucent cube and you'll see what I mean.

b.

> 1) in the patch below, during rotation not all faces of the cube show
> properly as being transparent. Im aware that when dealing with separate
> geometry during rotation, one has to be aware of rendering order to deal
> with issues during rotation (things behind rendering after things
> upfront have, which looks odd), but should this happen with a single
> object that has an alpha between 1 and 0 ?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20050404/b3a5a69b/attachment.pgp>


More information about the Pd-list mailing list