hi
during fooling around with alpha-channel i realized, that transparency works only in one direction. i don't know much about opengl, but could it be that it is an issue of my gfx-card (ati mobility radeon 9600)? it seems that when an object (e.g. a rectangle), that is processed AFTER another object is placed (from Gem-perspective) in front of this first processed object, it gets transparent with alpha-values < 1. but when you rotate the whole thing (180 degree), you have the first processed object in front of the second processed object and the obj in front is darker, but not transparent.
the attached patch may explains better what i am trying to say.
is there a way to get transparency in all directions?
roman
Roman Haefeli wrote:
hi
during fooling around with alpha-channel i realized, that transparency works only in one direction. i don't know much about opengl, but could it be that it is an issue of my gfx-card (ati mobility radeon 9600)? it seems that when an object (e.g. a rectangle), that is processed AFTER another object is placed (from Gem-perspective) in front of this first processed object, it gets transparent with alpha-values < 1. but when you rotate the whole thing (180 degree), you have the first processed object in front of the second processed object and the obj in front is darker, but not transparent.
the attached patch may explains better what i am trying to say.
is there a way to get transparency in all directions?
Yes. You have to rearrange the objects into the order in which they will be drawn, using some sort of sorting algorithm. There is no other way...at least no easier way. The way openGL does transparency is by drawing over top of previously drawn objects and mixing the colours according to the alpha value of the closer object. Distant objects must therefore be drawn first. With the z buffer turned off, distant objects can still be drawn after the foreground objects but they will not appear transparent, so they will appear to be floating in front, which looks all wrong. In alphabehaviour.pd you would have to split the rectangles where they join and adjust their drawing order according to the rotation angle. Can this be done in Gem? Martin
thanks, martin and IOhannes for the hints.
but this means, if i'd like to cross two rectangles, there is no other way to make all parts transparent besides splitting them in separate rectangles to set the execution order?
suddenly this is not a real solution when using textures.
cheers roman
"IOhannes m zmoelnig" zmoelnig@iem.at wrote:
Martin Peach wrote:
Roman Haefeli wrote:
join and adjust their drawing order according to the rotation angle.
Can
this be done in Gem?
you can change the order of [gemhead] execution dynamically by sending it a [set <priority>( message.
mfg.asdr IOhannes
___________________________________________________________ Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de
Roman Haefeli wrote:
thanks, martin and IOhannes for the hints.
but this means, if i'd like to cross two rectangles, there is no other way to make all parts transparent besides splitting them in separate rectangles to set the execution order?
and of course you could change the gemchain with the help of [spigot] to render one rectangle after the other one.
suddenly this is not a real solution when using textures.
this i don't understand.
however i understand that it can be a pain in the a to keep track of the positions (and the depth)
mfg.asdr. IOhannes
sorry for my language. i see that one can change the execution order dynamically, but this doesn't help in the case when two rectangles cross each other (like an 'X'). then you have at the same time the first AND the second rendered rectangle in front, but only one part is transparent.
roman
"IOhannes m zmoelnig" zmoelnig@iem.at wrote:
Roman Haefeli wrote:
thanks, martin and IOhannes for the hints.
but this means, if i'd like to cross two rectangles, there is no
other
way to make all parts transparent besides splitting them in separate rectangles to set the execution order?
and of course you could change the gemchain with the help of [spigot]
to
render one rectangle after the other one.
suddenly this is not a real solution when using textures.
this i don't understand.
however i understand that it can be a pain in the a to keep track of
the
positions (and the depth)
mfg.asdr. IOhannes
___________________________________________________________ Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de
On 12/1/05, Roman Haefeli reduzierer@yahoo.de wrote:
sorry for my language. i see that one can change the execution order dynamically, but this doesn't help in the case when two rectangles cross each other (like an 'X'). then you have at the same time the first AND the second rendered rectangle in front, but only one part is transparent.
roman
You need 4 rectangles to do that properly. This is one of the oldest problems in 3D rendering.
chris clepper wrote:
On 12/1/05, Roman Haefeli reduzierer@yahoo.de wrote:
sorry for my language. i see that one can change the execution order dynamically, but this doesn't help in the case when two rectangles cross each other (like an 'X'). then you have at the same time the first AND the second rendered rectangle in front, but only one part is transparent.
roman
You need 4 rectangles to do that properly. This is one of the oldest problems in 3D rendering.
and use [pix_coordinate] to set up the textures correctly (i think this is your problem with textures)
mfg.as.dr IOhannes
hi IOhannes
"IOhannes m zmoelnig" zmoelnig@iem.at wrote:
and use [pix_coordinate] to set up the textures correctly (i think
this
is your problem with textures)
exactly... thx for the hint.
roman
___________________________________________________________ Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de
-
chris clepper -
IOhannes m zmoelnig -
Martin Peach -
Roman Haefeli