On Tue, Oct 11, 2011 at 8:38 PM, MobileVisuals <eyv...@astralvisuals.com> wrote: > I see, now I understand the color4f method. I can't sort the > transparent sprites back-to-front,because they are all in one vertex > array. It would be much slower if I had one vertex array for each > quad, because it would be so many drawArray calls.
Think about your problem from the depth sorting perspective. Again, I don't know what exactly you are doing but your geometry looks quite regular to me - perhaps the depth sorting, once established, never changes? If you're drawing everything in a single glDrawArrays() call then all of your quads share the same transformation (the same values you pass to glTranslate()/glRotate()/glScale()). If that's the case your geometry is likely pre-transformed (you transform vertices of each quad before putting them into the array) - could you sort the quads as you transform them? Try to take advantage of any problem-specific knowledge you have (and I don't). In my experience it's rather unlikely that you're unable to do the required depth sorting. > I will only use one layer of quads from now on. But the particles in > the animation are morphed, so one particle will sometimes be placed > above another. > Do you mean that this will always result in black quads? Unfortunately yes. When using translucency with depth buffering I don't know of any other solution, in general. To understand this consider you draw a partially transparent quad, just like one of yours. Its transparent pixels will not change the frame buffer since they are transparent - the corresponding frame buffer pixels will stay at your clear colour. However, the quad also writes into the depth buffer. Now, consider another quad comes that (partially) overlaps with the first one and should be visible where the first quad had transparent parts. Also consider that this second quad can be further away from the camera which can well happen since your quads are *not* back-to-front sorted. The second quad will be prevented by depth test from writing to any pixels touched by the first quad. This means your clear colour remains where the first sprite was transparent/translucent. Hence your black rectangle - a quad close to camera comes first and blocks other quads further away from the camera from writing over it. I'm afraid you will have to figure out how to depth-sort your geometry properly. As I said before, it shouldn't be *that* tough. ;-) > I will only use star1.png for testing,since you said that image was > correct. I used this guide to add the alpha channel: > http://fabiovisentin.com/tutorial/gimp_transparent_image/gimp_how_to_make_transparent_image.asp That is a fine tutorial, however you will notice the example image has (perhaps apart from some anti-aliasing) sharp edges. The process they describe there is appropriate for that sort of images. However, your stuff is supposed to smoothly blend into its surroundings, with no defined edge, pretty much. The process from the tutorial is not well suited for this kind of image. Consider getting rid of the black component in your art for instance by loading it into Gimp, then going to Colours->Colour to Alpha... and setting the colour to black. I checked and even star1.png seems to have more black in it than would look right ... Only you know what you're trying to achieve so this might or might not be an appropriate fix. To me, your art fixed like this looks about right and ready for some serious blending. ;-) -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
