for a brighter result, try to use use additive blending: glBlendFunc(GL_SRC_ALPHA, GL_ONE)
e.g. http://stackoverflow.com/questions/393785/how-to-setup-blending-for-additive-color-overlays and yes, alpha should be in the png -> texture. best -- Mathieu On Oct 8, 11:08 am, MobileVisuals <eyv...@astralvisuals.com> wrote: > How do you mean that I should put brightness level in the textures? I > have already enabled transparency with > > gl.glEnable(GL10.GL_BLEND); > gl.glBlendFunc(GL10.GL_SRC_ALPHA, GL10.GL_ONE_MINUS_SRC_ALPHA); > gl.glColor4f(1f, 1f, 1f, 0.25f); > > I see that the transparency have effect, but it doesn't work as well > as it should. I have also noticed that the black square quads are > visible. Do you know what I can do to get rid of the black square > quads? Is there any way to make it as shiny and smooth as it was with > point sprites? > > I use this call to draw the quads: > > gl.glDrawElements(GL10.GL_TRIANGLES, vertices*2, > GL10.GL_UNSIGNED_SHORT,indiceBuffer); > > I don't think that I can use glDrawArrays,because that is for > TriangleStripArrays. I have 1200 particles, which makes it 4800 > vertices in the array for the quads. The positions are morphed for > each repaint. Maybe that is what is making it slow,but it was fast > with point sprites. > > Each star particle consists of 2 quads. The star particle in the > middle is smaller quad. The transparent blueish blur around that > particle is another quad. These are drawn with 2 arrays. I draw the > most opaque array first (the star particle in the middle) and then the > more transparent array later. This approach worked very well with > point sprites and size attenuation, but maybe this doesn't work with > texture mapped quads. Maye there are simply too much quads for the > system to take care off, which messes up the Depth Testing and the z > buffer. Maybe this is the reason that the transparency is not working > like it should, which causes the visible black square quads? > > On Oct 7, 4:58 pm, Kostya Vasilyev <kmans...@gmail.com> wrote: > > > > > > > > > Looking at the "dull" screenshot, I can see that your sprites are wrong > > - they don't have transparency around the "point" itself. > > > The black square quads are clearly visible, and they shouldn't be. > > > The brightness level is what you put in the textures, you should be able > > to make them as bright as you want. > > > As for performance, I haven't done any 3D work specifically on Android > > devices, so can't say for sure. Using glDrawArrays should help, does it not? > > > -- Kostya > > > 07.10.2011 17:44, MobileVisuals пишет: > > > > I have implemented this according to your approach now. I replaced > > > attenuated points with texture mapped quads. I implemented bilinear > > > filtering and alpha test. > > > It works, but the visual quality is not good. It doesn't look at all > > > as good as with Point sprites and size attenuation. It looked shiny > > > and smooth when I used Point sprites and size attenuation and it was > > > fast: > > >http://www.mobile-visuals.com/mgw.php > > > > Now it is just rough and dull and it is slow: > > >http://www.mobile-visuals.com/dull.png > > > > Are you really sure that is possible to get good visual quality with > > > your approach? > > > > On Sep 29, 9:26 pm, Kostya Vasilyev<kmans...@gmail.com> wrote: > > >> 29.09.2011 23:01, MobileVisuals ?????: > > > >>> I claim that HTC HD doesn't support OpenGL ES 2.0, because size > > >>> attenuation is a part of OpenGL ES 1.1 and it is not supported. > > >> Quite possibly, you're right... > > > >>> So HTC hasn't implemented the things that they say in the > > >>> specification, but why not? > > >> Who knows? > > > >> You could contact their support, but even if they provide a plausible > > >> answer (and that's a big "if"), it's not going to magically fix all the > > >> HTC devices out there... > > > >>> Thanks for the idea, do you mean like this? > > >>> Scale to small size if the sprite is far away. > > >>> Scale to medium size if the sprite is medium distance. > > >>> Scale to big size if the sprite is close. > > >> More or less - you are currently doing continuous range scaling of your > > >> sprites (I presume). If you replace them with texture mapped quads, you > > >> could always use the same image, or pick one of the ones predefined at > > >> various scale factors, to improve the image quality and performance. > > >> Sort of like mip-mapping. > > > >> But that's not the core idea - the main thing is to replace attenuated > > >> points with texture mapped quads. > > > >>> That could work for other animations, but it would be very slow for my > > >>> star cluster animations. There are hundreds of stars in each cluster. > > >>> As it is now, I draw each star cluster in one single glDrawArrays > > >>> call. That makes it fast. > > >> Hundreds doesn't sound too bad - at those poly counts, it's the fill > > >> rate (overdraw) that can kill performance. But since sprites are > > >> typically small, it probably won't be an issue. > > > >>> Wouldn't I have to make one glDrawArrays call for each one of the > > >>> stars if I had to scale them in different sizes? That would mean > > >>> hundreds of glDrawArrays calls instead of one. > > >> Not the way I'm reading the docs (mind you, my GL is more than a little > > >> rusty - last time I worked with 3D was more than 10 years ago).... > > > >> But it seems like you should be able to draw all quads that use the same > > >> texture in one call, using GL_TRIANGLES or GL_QUADS (not _STRIP or _FAN, > > >> because those are always joined). This can product transparency > > >> artifacts depending on their z-order, so you'd need to sort the quads > > >> according to their texture and z-order both. > > > >> Or just forgo the mipmapping for initial tests, then there's be one less > > >> thing to worry about with respect to sorting. > > > >>> A point sprite is a screen-aligned element of variable size that is > > >>> defined by a single point. Would it really be a sprite if it was > > >>> mapped to a quad polygon? > > >> If it looks like a sprite, and quacks like a sprite... > > > >> -- > > >> Kostya Vasilyev > > > -- > > Kostya Vasilyev -- 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