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

Reply via email to