Probably your source texture image has no any transparency. That's why black squares are visible. Setting alpha to 0.25f makes your stars look faded. You should not change the alpha value in glColor4f. You should prepare star image with transparency. Anyway I still think that it's possible to get away with point sprites.
BTW glDrawArrays works fine with other primitive type. Not just GL_TRIANGLE_STRIP. On 8 окт, 13:08, 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
