[android-developers] Re: HTC and LG haven't implemented Android in the right way
That's odd.
Anyway I've just resent you email.
The point sprites project works OK on HTC G1 (Android 1.6).
On 24 окт, 11:25, MobileVisuals wrote:
> No, I didn't get the sample project, but it would be interested to see
> it, so could you send it again? Have you tested it on HTC devices?
>
> I don't get any black squares around the particles with my Quad
> approach either.
>
> On Oct 22, 12:59 pm, Nightwolf wrote:
>
>
>
> > Did you get a sample project I sent you earlier? It uses point sprites
> > and has no black squares around particles.
>
> > On 21 ÏËÔ, 15:20, MobileVisuals wrote:
>
> > > I solved this problem now for the morphed animation. I used a TreSet
> > > for the sorting. I made a Quad class and and added the quads to the
> > > treeset for each draw. The TreeSet šthen sorts them in an automatic
> > > way.
>
> > > It's not as fast as with real Point sprites and size attenuation, but
> > > the speed is OK. This really took a long time to fix. I am still going
> > > to write to the HTC support, just to let them know that they haven't
> > > implemented Android in the right way.
>
> > > On Oct 14, 10:39šam, MobileVisuals wrote:
>
> > > > The morphed positions for the stars are calculated from some
> > > > precalculated 3d arrays, one 3d array for each single galaxy shape,
> > > > like below.
> > > > positionsM1 and positionsM2 are the two 3d arrays, which get morphed
> > > > for this frame. The result is the new morphedPositions array, which is
> > > > drawn later. I can't find any frame-to-frame coherency here. I am
> > > > considering to start with another 3d animation instead, which doesn't
> > > > use morphing, because I don't have a clue how to make an effective and
> > > > fast sorting algorithm for this:
>
> > > > for (int i = 0; i < morphedPositions.length; i++) {
> > > > š š š š š š š š š š š š morphedPositions[i] = (morphcount *
> > > > positionsM1[i]) * mlInv
> > > > š š š š š š š š š š š š š š š š š š š š + ((morphLength - morphcount) *
> > > > positionsM2[i]) * mlInv;
> > > > š š š š š š š š }
>
> > > > On Oct 14, 10:17šam, Latimerius wrote:
>
> > > > > On Wed, Oct 12, 2011 at 7:09 PM, MobileVisuals
> > > > > wrote:
> > > > > > Thanks a lot for the info! The problem is that the positions for the
> > > > > > stars change for each new frame. This happens because the positions
> > > > > > are morphed.Wouldn't it be very slow to sort all the positions
> > > > > > according to their z-value for every frame?
>
> > > > > I'd take a close look at my positions morphing algorithm. šHow does
> > > > > the z-order change frame-to-frame? šI doubt it can change randomly,
> > > > > there will be some kind of frame-to-frame coherency - perhaps just a
> > > > > bunch of fix-ups are needed from the previous frame? šI'd try to take
> > > > > advantage of that, it should reduce your problem from a general full
> > > > > sorting one to something possibly way smaller.
>
> > > > > > Wouldn't I have to make one drawElements call for each quad if I
> > > > > > sorted them?
>
> > > > > Not necessarily. šTry keeping vertex positions data in system memory
> > > > > (i.e. in normal Java objects). šBefore rendering each frame you
> > > > > recompute positions, reshuffle the data to restore back-to-front order
> > > > > and make a single VBO out of that. šYou could check glBufferSubData()
> > > > > and similar to avoid transferring all of the data over the bus into
> > > > > VRAM each frame. šYou can then issue a single glDrawElements() to
> > > > > render the whole thing.
>
> > > > > How exactly to do that depends on your particular algorithm but it
> > > > > should be possible.
>
> > > > > > I assume that would be a lot slower than one drawElements call for
> > > > > > all of the quads,
> > > > > > as it is now.
>
> > > > > I understand your worries, they are well grounded. šTrying to do a
> > > > > more complex thing will usually mean your performance takes a hit.
> > > > > However, I found out in a surprising amount of cases that a thing I
> > > > > would have expected to be prohibitively slow performed very well. GPUs
> > > > > are complex beasts, they can parallelise, hide latencies and all kinds
> > > > > of stuff. šYou never know until you try.
>
> > > > > And, above all, remember that you can hardly make your renders look
> > > > > right if you use translucency with depth-buffering but don't sort
> > > > > back-to-front. šSo my strategy would be implement the sorting to make
> > > > > stuff look right, then look into how to restore plausible performance
> > > > > if needed.
--
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
[android-developers] Re: HTC and LG haven't implemented Android in the right way
No, I didn't get the sample project, but it would be interested to see
it, so could you send it again? Have you tested it on HTC devices?
I don't get any black squares around the particles with my Quad
approach either.
On Oct 22, 12:59 pm, Nightwolf wrote:
> Did you get a sample project I sent you earlier? It uses point sprites
> and has no black squares around particles.
>
> On 21 ÏËÔ, 15:20, MobileVisuals wrote:
>
> > I solved this problem now for the morphed animation. I used a TreSet
> > for the sorting. I made a Quad class and and added the quads to the
> > treeset for each draw. The TreeSet šthen sorts them in an automatic
> > way.
>
> > It's not as fast as with real Point sprites and size attenuation, but
> > the speed is OK. This really took a long time to fix. I am still going
> > to write to the HTC support, just to let them know that they haven't
> > implemented Android in the right way.
>
> > On Oct 14, 10:39šam, MobileVisuals wrote:
>
> > > The morphed positions for the stars are calculated from some
> > > precalculated 3d arrays, one 3d array for each single galaxy shape,
> > > like below.
> > > positionsM1 and positionsM2 are the two 3d arrays, which get morphed
> > > for this frame. The result is the new morphedPositions array, which is
> > > drawn later. I can't find any frame-to-frame coherency here. I am
> > > considering to start with another 3d animation instead, which doesn't
> > > use morphing, because I don't have a clue how to make an effective and
> > > fast sorting algorithm for this:
>
> > > for (int i = 0; i < morphedPositions.length; i++) {
> > > š š š š š š š š š š š š morphedPositions[i] = (morphcount *
> > > positionsM1[i]) * mlInv
> > > š š š š š š š š š š š š š š š š š š š š + ((morphLength - morphcount) *
> > > positionsM2[i]) * mlInv;
> > > š š š š š š š š }
>
> > > On Oct 14, 10:17šam, Latimerius wrote:
>
> > > > On Wed, Oct 12, 2011 at 7:09 PM, MobileVisuals
> > > > wrote:
> > > > > Thanks a lot for the info! The problem is that the positions for the
> > > > > stars change for each new frame. This happens because the positions
> > > > > are morphed.Wouldn't it be very slow to sort all the positions
> > > > > according to their z-value for every frame?
>
> > > > I'd take a close look at my positions morphing algorithm. šHow does
> > > > the z-order change frame-to-frame? šI doubt it can change randomly,
> > > > there will be some kind of frame-to-frame coherency - perhaps just a
> > > > bunch of fix-ups are needed from the previous frame? šI'd try to take
> > > > advantage of that, it should reduce your problem from a general full
> > > > sorting one to something possibly way smaller.
>
> > > > > Wouldn't I have to make one drawElements call for each quad if I
> > > > > sorted them?
>
> > > > Not necessarily. šTry keeping vertex positions data in system memory
> > > > (i.e. in normal Java objects). šBefore rendering each frame you
> > > > recompute positions, reshuffle the data to restore back-to-front order
> > > > and make a single VBO out of that. šYou could check glBufferSubData()
> > > > and similar to avoid transferring all of the data over the bus into
> > > > VRAM each frame. šYou can then issue a single glDrawElements() to
> > > > render the whole thing.
>
> > > > How exactly to do that depends on your particular algorithm but it
> > > > should be possible.
>
> > > > > I assume that would be a lot slower than one drawElements call for
> > > > > all of the quads,
> > > > > as it is now.
>
> > > > I understand your worries, they are well grounded. šTrying to do a
> > > > more complex thing will usually mean your performance takes a hit.
> > > > However, I found out in a surprising amount of cases that a thing I
> > > > would have expected to be prohibitively slow performed very well. GPUs
> > > > are complex beasts, they can parallelise, hide latencies and all kinds
> > > > of stuff. šYou never know until you try.
>
> > > > And, above all, remember that you can hardly make your renders look
> > > > right if you use translucency with depth-buffering but don't sort
> > > > back-to-front. šSo my strategy would be implement the sorting to make
> > > > stuff look right, then look into how to restore plausible performance
> > > > if needed.
--
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
[android-developers] Re: HTC and LG haven't implemented Android in the right way
Did you get a sample project I sent you earlier? It uses point sprites
and has no black squares around particles.
On 21 окт, 15:20, MobileVisuals wrote:
> I solved this problem now for the morphed animation. I used a TreSet
> for the sorting. I made a Quad class and and added the quads to the
> treeset for each draw. The TreeSet then sorts them in an automatic
> way.
>
> It's not as fast as with real Point sprites and size attenuation, but
> the speed is OK. This really took a long time to fix. I am still going
> to write to the HTC support, just to let them know that they haven't
> implemented Android in the right way.
>
> On Oct 14, 10:39 am, MobileVisuals wrote:
>
>
>
> > The morphed positions for the stars are calculated from some
> > precalculated 3d arrays, one 3d array for each single galaxy shape,
> > like below.
> > positionsM1 and positionsM2 are the two 3d arrays, which get morphed
> > for this frame. The result is the new morphedPositions array, which is
> > drawn later. I can't find any frame-to-frame coherency here. I am
> > considering to start with another 3d animation instead, which doesn't
> > use morphing, because I don't have a clue how to make an effective and
> > fast sorting algorithm for this:
>
> > for (int i = 0; i < morphedPositions.length; i++) {
> > morphedPositions[i] = (morphcount * positionsM1[i])
> > * mlInv
> > + ((morphLength - morphcount) *
> > positionsM2[i]) * mlInv;
> > }
>
> > On Oct 14, 10:17 am, Latimerius wrote:
>
> > > On Wed, Oct 12, 2011 at 7:09 PM, MobileVisuals
> > > wrote:
> > > > Thanks a lot for the info! The problem is that the positions for the
> > > > stars change for each new frame. This happens because the positions
> > > > are morphed.Wouldn't it be very slow to sort all the positions
> > > > according to their z-value for every frame?
>
> > > I'd take a close look at my positions morphing algorithm. How does
> > > the z-order change frame-to-frame? I doubt it can change randomly,
> > > there will be some kind of frame-to-frame coherency - perhaps just a
> > > bunch of fix-ups are needed from the previous frame? I'd try to take
> > > advantage of that, it should reduce your problem from a general full
> > > sorting one to something possibly way smaller.
>
> > > > Wouldn't I have to make one drawElements call for each quad if I sorted
> > > > them?
>
> > > Not necessarily. Try keeping vertex positions data in system memory
> > > (i.e. in normal Java objects). Before rendering each frame you
> > > recompute positions, reshuffle the data to restore back-to-front order
> > > and make a single VBO out of that. You could check glBufferSubData()
> > > and similar to avoid transferring all of the data over the bus into
> > > VRAM each frame. You can then issue a single glDrawElements() to
> > > render the whole thing.
>
> > > How exactly to do that depends on your particular algorithm but it
> > > should be possible.
>
> > > > I assume that would be a lot slower than one drawElements call for all
> > > > of the quads,
> > > > as it is now.
>
> > > I understand your worries, they are well grounded. Trying to do a
> > > more complex thing will usually mean your performance takes a hit.
> > > However, I found out in a surprising amount of cases that a thing I
> > > would have expected to be prohibitively slow performed very well. GPUs
> > > are complex beasts, they can parallelise, hide latencies and all kinds
> > > of stuff. You never know until you try.
>
> > > And, above all, remember that you can hardly make your renders look
> > > right if you use translucency with depth-buffering but don't sort
> > > back-to-front. So my strategy would be implement the sorting to make
> > > stuff look right, then look into how to restore plausible performance
> > > if needed.
--
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
[android-developers] Re: HTC and LG haven't implemented Android in the right way
I solved this problem now for the morphed animation. I used a TreSet
for the sorting. I made a Quad class and and added the quads to the
treeset for each draw. The TreeSet then sorts them in an automatic
way.
It's not as fast as with real Point sprites and size attenuation, but
the speed is OK. This really took a long time to fix. I am still going
to write to the HTC support, just to let them know that they haven't
implemented Android in the right way.
On Oct 14, 10:39 am, MobileVisuals wrote:
> The morphed positions for the stars are calculated from some
> precalculated 3d arrays, one 3d array for each single galaxy shape,
> like below.
> positionsM1 and positionsM2 are the two 3d arrays, which get morphed
> for this frame. The result is the new morphedPositions array, which is
> drawn later. I can't find any frame-to-frame coherency here. I am
> considering to start with another 3d animation instead, which doesn't
> use morphing, because I don't have a clue how to make an effective and
> fast sorting algorithm for this:
>
> for (int i = 0; i < morphedPositions.length; i++) {
> morphedPositions[i] = (morphcount * positionsM1[i]) *
> mlInv
> + ((morphLength - morphcount) *
> positionsM2[i]) * mlInv;
> }
>
> On Oct 14, 10:17 am, Latimerius wrote:
>
> > On Wed, Oct 12, 2011 at 7:09 PM, MobileVisuals
> > wrote:
> > > Thanks a lot for the info! The problem is that the positions for the
> > > stars change for each new frame. This happens because the positions
> > > are morphed.Wouldn't it be very slow to sort all the positions
> > > according to their z-value for every frame?
>
> > I'd take a close look at my positions morphing algorithm. How does
> > the z-order change frame-to-frame? I doubt it can change randomly,
> > there will be some kind of frame-to-frame coherency - perhaps just a
> > bunch of fix-ups are needed from the previous frame? I'd try to take
> > advantage of that, it should reduce your problem from a general full
> > sorting one to something possibly way smaller.
>
> > > Wouldn't I have to make one drawElements call for each quad if I sorted
> > > them?
>
> > Not necessarily. Try keeping vertex positions data in system memory
> > (i.e. in normal Java objects). Before rendering each frame you
> > recompute positions, reshuffle the data to restore back-to-front order
> > and make a single VBO out of that. You could check glBufferSubData()
> > and similar to avoid transferring all of the data over the bus into
> > VRAM each frame. You can then issue a single glDrawElements() to
> > render the whole thing.
>
> > How exactly to do that depends on your particular algorithm but it
> > should be possible.
>
> > > I assume that would be a lot slower than one drawElements call for all of
> > > the quads,
> > > as it is now.
>
> > I understand your worries, they are well grounded. Trying to do a
> > more complex thing will usually mean your performance takes a hit.
> > However, I found out in a surprising amount of cases that a thing I
> > would have expected to be prohibitively slow performed very well. GPUs
> > are complex beasts, they can parallelise, hide latencies and all kinds
> > of stuff. You never know until you try.
>
> > And, above all, remember that you can hardly make your renders look
> > right if you use translucency with depth-buffering but don't sort
> > back-to-front. So my strategy would be implement the sorting to make
> > stuff look right, then look into how to restore plausible performance
> > if needed.
--
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
[android-developers] Re: HTC and LG haven't implemented Android in the right way
The morphed positions for the stars are calculated from some
precalculated 3d arrays, one 3d array for each single galaxy shape,
like below.
positionsM1 and positionsM2 are the two 3d arrays, which get morphed
for this frame. The result is the new morphedPositions array, which is
drawn later. I can't find any frame-to-frame coherency here. I am
considering to start with another 3d animation instead, which doesn't
use morphing, because I don't have a clue how to make an effective and
fast sorting algorithm for this:
for (int i = 0; i < morphedPositions.length; i++) {
morphedPositions[i] = (morphcount * positionsM1[i]) *
mlInv
+ ((morphLength - morphcount) *
positionsM2[i]) * mlInv;
}
On Oct 14, 10:17 am, Latimerius wrote:
> On Wed, Oct 12, 2011 at 7:09 PM, MobileVisuals
> wrote:
> > Thanks a lot for the info! The problem is that the positions for the
> > stars change for each new frame. This happens because the positions
> > are morphed.Wouldn't it be very slow to sort all the positions
> > according to their z-value for every frame?
>
> I'd take a close look at my positions morphing algorithm. How does
> the z-order change frame-to-frame? I doubt it can change randomly,
> there will be some kind of frame-to-frame coherency - perhaps just a
> bunch of fix-ups are needed from the previous frame? I'd try to take
> advantage of that, it should reduce your problem from a general full
> sorting one to something possibly way smaller.
>
> > Wouldn't I have to make one drawElements call for each quad if I sorted
> > them?
>
> Not necessarily. Try keeping vertex positions data in system memory
> (i.e. in normal Java objects). Before rendering each frame you
> recompute positions, reshuffle the data to restore back-to-front order
> and make a single VBO out of that. You could check glBufferSubData()
> and similar to avoid transferring all of the data over the bus into
> VRAM each frame. You can then issue a single glDrawElements() to
> render the whole thing.
>
> How exactly to do that depends on your particular algorithm but it
> should be possible.
>
> > I assume that would be a lot slower than one drawElements call for all of
> > the quads,
> > as it is now.
>
> I understand your worries, they are well grounded. Trying to do a
> more complex thing will usually mean your performance takes a hit.
> However, I found out in a surprising amount of cases that a thing I
> would have expected to be prohibitively slow performed very well. GPUs
> are complex beasts, they can parallelise, hide latencies and all kinds
> of stuff. You never know until you try.
>
> And, above all, remember that you can hardly make your renders look
> right if you use translucency with depth-buffering but don't sort
> back-to-front. So my strategy would be implement the sorting to make
> stuff look right, then look into how to restore plausible performance
> if needed.
--
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
Re: [android-developers] Re: HTC and LG haven't implemented Android in the right way
On Wed, Oct 12, 2011 at 7:09 PM, MobileVisuals wrote: > Thanks a lot for the info! The problem is that the positions for the > stars change for each new frame. This happens because the positions > are morphed.Wouldn't it be very slow to sort all the positions > according to their z-value for every frame? I'd take a close look at my positions morphing algorithm. How does the z-order change frame-to-frame? I doubt it can change randomly, there will be some kind of frame-to-frame coherency - perhaps just a bunch of fix-ups are needed from the previous frame? I'd try to take advantage of that, it should reduce your problem from a general full sorting one to something possibly way smaller. > Wouldn't I have to make one drawElements call for each quad if I sorted them? Not necessarily. Try keeping vertex positions data in system memory (i.e. in normal Java objects). Before rendering each frame you recompute positions, reshuffle the data to restore back-to-front order and make a single VBO out of that. You could check glBufferSubData() and similar to avoid transferring all of the data over the bus into VRAM each frame. You can then issue a single glDrawElements() to render the whole thing. How exactly to do that depends on your particular algorithm but it should be possible. > I assume that would be a lot slower than one drawElements call for all of the > quads, > as it is now. I understand your worries, they are well grounded. Trying to do a more complex thing will usually mean your performance takes a hit. However, I found out in a surprising amount of cases that a thing I would have expected to be prohibitively slow performed very well. GPUs are complex beasts, they can parallelise, hide latencies and all kinds of stuff. You never know until you try. And, above all, remember that you can hardly make your renders look right if you use translucency with depth-buffering but don't sort back-to-front. So my strategy would be implement the sorting to make stuff look right, then look into how to restore plausible performance if needed. -- 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
[android-developers] Re: HTC and LG haven't implemented Android in the right way
Thanks a lot for the info! The problem is that the positions for the stars change for each new frame. This happens because the positions are morphed.Wouldn't it be very slow to sort all the positions according to their z-value for every frame? Wouldn't I have to make one drawElements call for each quad if I sorted them? I assume that would be a lot slower than one drawElements call for all of the quads, as it is now. -- 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
Re: [android-developers] Re: HTC and LG haven't implemented Android in the right way
On Tue, Oct 11, 2011 at 8:38 PM, MobileVisuals 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
[android-developers] Re: HTC and LG haven't implemented Android in the right way
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. 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? 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 On Oct 11, 4:22 pm, Latimerius wrote: > Hello, my guess would be you don't sort your transparent sprites > back-to-front, do you? > > For a couple more comments please see inline: > > On Tue, Oct 11, 2011 at 11:51 AM, MobileVisuals > > > > wrote: > > before. I tried to remove the gl.glColor4f calls, but that made the > > black square quads much more visible. This is how it looks like now, > > with gl.glColor4f(1f, 1f, 1f, 0.4f); > > >http://www.mobile-visuals.com/color4f04.png > > > with gl.glColor4f(1f, 1f, 1f, 0.8f); > > >http://www.mobile-visuals.com/color4f08.png > > > with no with gl.glColor4f calls: > > >http://www.mobile-visuals.com/noColor4f.png > > > This shows that with higher alpha value in glColor4f, the more black > > square quads. It also shows that the > > smaller alpha value in glColor4f, the more dull result. > > glColor() used with texturing simply modulates the texel colours in > your case. By specifying (1,1,1, <1) you leave the hue alone but add > 0.4f or 0.8f transparency. Smaller alpha means dull because whatever > you draw becomes almost transparent. Similarly, higher alpha means > what you draw is more visible, including the black artifacts. > > > This how the > > source textures looks like now: > > >http://www.mobile-visuals.com/trance1.png > >http://www.mobile-visuals.com/star1.png > >http://www.mobile-visuals.com/star2.png > > BTW apart from star1.png these assets don't look correctly authored to > me. I don't know exactly what you're trying to achieve but I believe > trance1.png and star2.png wouldn't work on a non-black background. > > > I have used 2 quads for each star, placed on each other here. > > This is where the above might bite you. If you draw say star2.png > over trance1.png the black component in star2.png's pixels will start > to show. I don't know if that's a problem for you, depends on what > your objectives are. > > > gl.glBlendFunc(GL10.GL_SRC_ALPHA, GL10.GL_ONE); > > Make sure your art *doesn't* have premultiplied alpha. If it does > then specifying GL_SRC_ALPHA would apply the alpha once more causing > transparent pixels to darken. You'd need GL_ONE in that case. > > > gl.glTexEnvf(GL10.GL_TEXTURE_ENV, GL10.GL_TEXTURE_ENV_MODE, > > GL10.GL_MODULATE); > > I believe this is the default so you could just as well leave it out. -- 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
Re: [android-developers] Re: HTC and LG haven't implemented Android in the right way
Hello, my guess would be you don't sort your transparent sprites back-to-front, do you? For a couple more comments please see inline: On Tue, Oct 11, 2011 at 11:51 AM, MobileVisuals wrote: > before. I tried to remove the gl.glColor4f calls, but that made the > black square quads much more visible. This is how it looks like now, > with gl.glColor4f(1f, 1f, 1f, 0.4f); > > http://www.mobile-visuals.com/color4f04.png > > with gl.glColor4f(1f, 1f, 1f, 0.8f); > > http://www.mobile-visuals.com/color4f08.png > > with no with gl.glColor4f calls: > > http://www.mobile-visuals.com/noColor4f.png > > This shows that with higher alpha value in glColor4f, the more black > square quads. It also shows that the > smaller alpha value in glColor4f, the more dull result. glColor() used with texturing simply modulates the texel colours in your case. By specifying (1,1,1, <1) you leave the hue alone but add 0.4f or 0.8f transparency. Smaller alpha means dull because whatever you draw becomes almost transparent. Similarly, higher alpha means what you draw is more visible, including the black artifacts. > This how the > source textures looks like now: > > http://www.mobile-visuals.com/trance1.png > http://www.mobile-visuals.com/star1.png > http://www.mobile-visuals.com/star2.png BTW apart from star1.png these assets don't look correctly authored to me. I don't know exactly what you're trying to achieve but I believe trance1.png and star2.png wouldn't work on a non-black background. > I have used 2 quads for each star, placed on each other here. This is where the above might bite you. If you draw say star2.png over trance1.png the black component in star2.png's pixels will start to show. I don't know if that's a problem for you, depends on what your objectives are. > gl.glBlendFunc(GL10.GL_SRC_ALPHA, GL10.GL_ONE); Make sure your art *doesn't* have premultiplied alpha. If it does then specifying GL_SRC_ALPHA would apply the alpha once more causing transparent pixels to darken. You'd need GL_ONE in that case. > gl.glTexEnvf(GL10.GL_TEXTURE_ENV, GL10.GL_TEXTURE_ENV_MODE, > GL10.GL_MODULATE); I believe this is the default so you could just as well leave it out. -- 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
[android-developers] Re: HTC and LG haven't implemented Android in the right way
Thanks, it looks better when I added an alpha channel to the textures. But I don't see that glBlendFunc(GL_SRC_ALPHA, GL_ONE) made any difference. There are still black square quads, but less than before. I tried to remove the gl.glColor4f calls, but that made the black square quads much more visible. This is how it looks like now, with gl.glColor4f(1f, 1f, 1f, 0.4f); http://www.mobile-visuals.com/color4f04.png with gl.glColor4f(1f, 1f, 1f, 0.8f); http://www.mobile-visuals.com/color4f08.png with no with gl.glColor4f calls: http://www.mobile-visuals.com/noColor4f.png This shows that with higher alpha value in glColor4f, the more black square quads. It also shows that the smaller alpha value in glColor4f, the more dull result. This how the source textures looks like now: http://www.mobile-visuals.com/trance1.png http://www.mobile-visuals.com/star1.png http://www.mobile-visuals.com/star2.png I have used 2 quads for each star, placed on each other here. I tried to only use one quad for each star. This improved the situation, but the black squares quads are still visible: http://www.mobile-visuals.com/onelayer.png I tested with another texture and got better result, but there are still black quads. They cover some of the stars, which makes these stars not visible: http://www.mobile-visuals.com/other.png Is there something more that I can do to get as good result as with Point sprites and size attenuation? I pasted my relevant code below. draw method: gl.glClear(GL10.GL_COLOR_BUFFER_BIT | GL10.GL_DEPTH_BUFFER_BIT); gl.glEnable(GL10.GL_TEXTURE_2D); gl.glEnableClientState(GL10.GL_TEXTURE_COORD_ARRAY); gl.glEnableClientState(GL10.GL_VERTEX_ARRAY); gl.glEnable(GL10.GL_BLEND); gl.glBlendFunc(GL10.GL_SRC_ALPHA, GL10.GL_ONE); gl.glEnable(GL10.GL_ALPHA_TEST); gl.glTexCoordPointer(2, GL10.GL_FLOAT, 0, textureBufferS); gl.glVertexPointer(3, GL10.GL_FLOAT, 0, vertexBufferLT); gl.glColor4f(1f, 1f, 1f, 0.8f); gl.glBindTexture(GL10.GL_TEXTURE_2D, textures[1]); gl.glDrawElements(GL10.GL_TRIANGLES, vertices*2, GL10.GL_UNSIGNED_SHORT, indiceBuffer); gl.glDisable(GL10.GL_TEXTURE_2D); gl.glDisableClientState(GL10.GL_TEXTURE_COORD_ARRAY); gl.glDisableClientState(GL10.GL_VERTEX_ARRAY); gl.glDisable(GL10.GL_BLEND); gl.glDisable(GL10.GL_ALPHA_TEST); surfaceCreated method: gl.glEnable(GL10.GL_TEXTURE_2D); gl.glClearColor(0.0f, 0.0f, 0.0f, 0.5f); gl.glClear(GL10.GL_DEPTH_BUFFER_BIT); gl.glEnable(GL10.GL_DEPTH_TEST); gl.glDepthFunc(GL10.GL_LEQUAL); gl.glHint(GL10.GL_PERSPECTIVE_CORRECTION_HINT, GL10.GL_NICEST); loadGLTexture method: gl.glTexEnvf(GL10.GL_TEXTURE_ENV, GL10.GL_TEXTURE_ENV_MODE, GL10.GL_MODULATE); bitmap1 = BitmapFactory.decodeResource(context.getResources(), R.drawable.trance1); gl.glBindTexture(GL10.GL_TEXTURE_2D, textures[0]); gl.glTexParameterf(GL10.GL_TEXTURE_2D, GL10.GL_TEXTURE_MIN_FILTER, GL10.GL_NEAREST); gl.glTexParameterf(GL10.GL_TEXTURE_2D, GL10.GL_TEXTURE_MAG_FILTER, GL10.GL_NEAREST); GLUtils.texImage2D(GL10.GL_TEXTURE_2D, 0, bitmap1, 0); On Oct 10, 10:50 am, bdk wrote: > 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-a... > > and yes, alpha should be in the png -> texture. > > best > > -- > Mathieu > > On Oct 8, 11:08 am, MobileVisuals 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 > > text
[android-developers] Re: HTC and LG haven't implemented Android in the right way
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 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 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 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. > > > >>> Woul
[android-developers] Re: HTC and LG haven't implemented Android in the right way
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 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 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 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 > >
[android-developers] Re: HTC and LG haven't implemented Android in the right way
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 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 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 _S
Re: [android-developers] Re: HTC and LG haven't implemented Android in the right way
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 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
[android-developers] Re: HTC and LG haven't implemented Android in the right way
The default Galaxy doesn't use Point sprites with size attenuation. It looks like it is just using plain points with spinning textures in the background. It looks like all the points have the same size. Galactic Core doesn't use Point sprites either. It looks like it is just using spinning textures. I can't find Galaxy Live Wallpaper on the market. I removed all HTC devices from the compatibility list for my Morphing galaxy live wallpaper, because the HTC users complained that it didn't look like it should. Here are some screenshots, which shows how it looks like: http://www.mobile-visuals.com/mgw.php On Sep 28, 9:54 am, Dusk Jockeys Android Apps wrote: > What is the Morphing Galaxy Live Wallpaper? I cant see that on the > Market. > > The default Galaxy, Galactic Core and Galaxy Live Wallpaper all work > perfectly well on my HTC Desire HD, with no blurring, so they are > probably not doing things the same way as you are. > > On Sep 28, 2:36šam, MobileVisuals wrote: > > > Yes, that is exactly what I am doing. I am using point sprites with > > size attenuation for my space animations, like the Morphing Galaxy > > live wallpaper. > > But what is the use of point sprites if the size attenuation do not > > work? > > > The size attenuation is not supported on devices from HTC and LG. This > > is what I mean with size attenuation: > > >http://www.opengl.org/sdk/docs/man/xhtml/glPointSize.xml > > > All the point sprites get the same size if the size attenuation do not > > work, which results in a blurry mess. > > > It looks like it should on most Android devices, but not those from > > HTC and LG. > > > On Sep 27, 7:11špm, Nightwolf wrote: > > > > Point sprites can be used to display stars in space. > > > > On 27 ÓÅÎ, 11:26, MobileVisuals wrote: > > > > > I need Point attenuation to produce space animations with shining > > > > particles, which look like stars. How can I achieve that effect > > > > without using Point attenuation? > > > > Do you mean that I should make small rectangular polygons with > > > > transparent textures instead? I have tried that before on M3G and it > > > > didn't look as good as Point attenuation. > > > > > Anti-Aliasing is a method of fooling the eye that a jagged edge is > > > > really smooth.Will that really be enough to get the same effect as > > > > Point attenuation? Could you please be more specific in which OpenGL > > > > technique I should use to make it work on HTC and LG? > > > > > Isn't Point attenuation a part of the Android OpenGL standard? > > > > Shouldn't HTC and LG support it in that case? > > > > > On Sep 27, 3:34šam, Indicator Veritatis wrote: > > > > > > Short answer: no. Longer: why do you need point attenuation? There are > > > > > other ways to do anti-aliasing, and some really cool graphics have > > > > > been done for Android phones using that instead of point attenuation. > > > > > > On Sep 26, 6:26šam, MobileVisuals wrote: > > > > > > > I have found that everything implemented with Point attenuation will > > > > > > look like a blurry mess on devices from HTC and šLG. This happens on > > > > > > even the newest devices from HTC, like HTC Desire HD. Why is it like > > > > > > this? Haven't they implemented Android in the right way? > > > > > > > Point attenuation works like it should on most Android devices, like > > > > > > those from Samsung. I have implemented Point attenuation according > > > > > > to > > > > > > the Android specification in two of my company's apps.I have worked > > > > > > with Point attenuation on Symbian and C++ before, so I am quite sure > > > > > > that I have implemented it the right way. It is about the same code > > > > > > implementation in all OpenGL. > > > > > > > Shouldn't all new Android devices support Point attenuation? It > > > > > > works > > > > > > on IPhone, so I think Point attenuation should work on all new > > > > > > Android > > > > > > devices too.- Hide quoted text - > > > - Show quoted text - -- 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
[android-developers] Re: HTC and LG haven't implemented Android in the right way
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 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 -- 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
[android-developers] Re: HTC and LG haven't implemented Android in the right way
What is the Morphing Galaxy Live Wallpaper? I cant see that on the Market. The default Galaxy, Galactic Core and Galaxy Live Wallpaper all work perfectly well on my HTC Desire HD, with no blurring, so they are probably not doing things the same way as you are. On Sep 28, 2:36 am, MobileVisuals wrote: > Yes, that is exactly what I am doing. I am using point sprites with > size attenuation for my space animations, like the Morphing Galaxy > live wallpaper. > But what is the use of point sprites if the size attenuation do not > work? > > The size attenuation is not supported on devices from HTC and LG. This > is what I mean with size attenuation: > > http://www.opengl.org/sdk/docs/man/xhtml/glPointSize.xml > > All the point sprites get the same size if the size attenuation do not > work, which results in a blurry mess. > > It looks like it should on most Android devices, but not those from > HTC and LG. > > On Sep 27, 7:11 pm, Nightwolf wrote: > > > > > Point sprites can be used to display stars in space. > > > On 27 сен, 11:26, MobileVisuals wrote: > > > > I need Point attenuation to produce space animations with shining > > > particles, which look like stars. How can I achieve that effect > > > without using Point attenuation? > > > Do you mean that I should make small rectangular polygons with > > > transparent textures instead? I have tried that before on M3G and it > > > didn't look as good as Point attenuation. > > > > Anti-Aliasing is a method of fooling the eye that a jagged edge is > > > really smooth.Will that really be enough to get the same effect as > > > Point attenuation? Could you please be more specific in which OpenGL > > > technique I should use to make it work on HTC and LG? > > > > Isn't Point attenuation a part of the Android OpenGL standard? > > > Shouldn't HTC and LG support it in that case? > > > > On Sep 27, 3:34 am, Indicator Veritatis wrote: > > > > > Short answer: no. Longer: why do you need point attenuation? There are > > > > other ways to do anti-aliasing, and some really cool graphics have > > > > been done for Android phones using that instead of point attenuation. > > > > > On Sep 26, 6:26 am, MobileVisuals wrote: > > > > > > I have found that everything implemented with Point attenuation will > > > > > look like a blurry mess on devices from HTC and LG. This happens on > > > > > even the newest devices from HTC, like HTC Desire HD. Why is it like > > > > > this? Haven't they implemented Android in the right way? > > > > > > Point attenuation works like it should on most Android devices, like > > > > > those from Samsung. I have implemented Point attenuation according to > > > > > the Android specification in two of my company's apps.I have worked > > > > > with Point attenuation on Symbian and C++ before, so I am quite sure > > > > > that I have implemented it the right way. It is about the same code > > > > > implementation in all OpenGL. > > > > > > Shouldn't all new Android devices support Point attenuation? It works > > > > > on IPhone, so I think Point attenuation should work on all new Android > > > > > devices too.- Hide quoted text - > > - Show quoted text - -- 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
[android-developers] Re: HTC and LG haven't implemented Android in the right way
I set up the attenuation exatly like this. It works prefectly on Samsung and most other devices, but not on HTC. Kostya and Nightwolf, thanks for the algorithm ideas. I am trying to implement it now. On Sep 30, 10:01 am, a1 wrote: > And did you correctly setup attenuation equation? Attenuation is controlled > by glPointParameter function > (http://www.khronos.org/opengles/sdk/1.1/docs/man/) with pname > GL_POINT_DISTANCE_ATTENUATION, where you suppose to provide array of 3 > floats with attenuation equation coeffs (a, b and c). > > This equation is: > > 1 / (1 + b * D + c * D^2) > > where D is point sprite distance. Initial value for this coeffs is 1, 0, 0 - > that is attenuation is disabled. -- 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
[android-developers] Re: HTC and LG haven't implemented Android in the right way
And did you correctly setup attenuation equation? Attenuation is controlled by glPointParameter function ( http://www.khronos.org/opengles/sdk/1.1/docs/man/) with pname GL_POINT_DISTANCE_ATTENUATION, where you suppose to provide array of 3 floats with attenuation equation coeffs (a, b and c). This equation is: 1 / (1 + b * D + c * D^2) where D is point sprite distance. Initial value for this coeffs is 1, 0, 0 - that is attenuation is disabled. -- 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
[android-developers] Re: HTC and LG haven't implemented Android in the right way
AFAIK it is possible to specify point size array along with vertex array. Enabling point sprites turns points to textured quads. Turn on bilinear filtering and alpha test or blending. Of course the texture should depict a star. On 29 сен, 23:26, Kostya Vasilyev 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 -- 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
Re: [android-developers] Re: HTC and LG haven't implemented Android in the right way
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 -- 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
[android-developers] Re: HTC and LG haven't implemented Android in the right way
It says in the HTC HD specification that it supports OpenGL ES 2.0:
http://www.mobiletechworld.com/2010/04/23/htc-hd-mini-review-is-it-worth-it/
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.
So HTC hasn't implemented the things that they say in the
specification, but why not?
On Sep 29, 8:54 pm, MobileVisuals wrote:
> 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.
>
> 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.
>
> 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.
>
> 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?
>
> I removed all HTC devices from the compatibility list for my Morphing
> galaxy live wallpaper, because the HTC users complained that it didn't
> look like it should. Lots of HTC users said the same thing, so I am
> sure that it doesn't work on any of the HTC's. My other LW's seem to
> work well on the HTC's, but they don't use any point sprites.
>
> On Sep 29, 11:16 am, Kostya Vasilyev wrote:
>
> > Bitmap sprites, mapped to a quad, perhaps of a few predefined sizes, picking
> > up the closest match and scaling to exact desired size You could then
> > distort the quad to provide a kind of hyperspeed blur effect near the edges
> > of the screen
>
> > BTW, I wanted to check out your wallpaper on my HTC Incredible S, but Market
> > won't let me install, reporting it as not compatible with the device.
>
> > -- Kostya
>
> > 2011/9/29 MobileVisuals
>
> > > Does anyone know if there is any other way to make space animations
> > > with
> > > shining star objects on HTC devices, where size attenuation don't
> > > work?
>
> > > On Sep 28, 10:29 am, MobileVisuals wrote:
> > > > Yes, it is in the OpenGL ES standard according to the book "Mobile 3D
> > > > Graphics with OpenGL ES and M3G" by Morgan Kaufmann. Here are 3 quotes
> > > > from that book:
> > > > --
> > > > "OpenGL ES 1.0 supports the geometric primitives shown in Figure 3.3:
> > > > points, lines, and
> > > > triangles. OpenGL ES 1.1 amends this list with point sprites."
>
> > > > "OpenGL ES 1.1 provides features for points that are especially useful
> > > > for particle effects:
> > > > point sprites, point size arrays, and point size attenuation."
>
> > > > "When points are defined by an array, in OpenGL ES 1.0 they all have
> > > > the same size, defined by glPointSize{fx}. In OpenGL ES 1.1 it is
> > > > possible to give each point its own size (see Section 8.1.2), and the
> > > > point sizes may be attenuated by the distance between each
> > > > point and the camera."
> > > > -
> > > > Could it be that the new HTC and LG devices only have OpenGL ES 1.0?
> > > > Devices with names like HTC HD and LG Optimus. I don't see anything HD
> > > > or optimus about them if they support an old OpenGL ES standard.
>
> > > > I don't have any HTC or LG devices, so I can't test
> > > > glGet(GL_POINT_SIZE_RANGE), but it would be interesting to so.
>
> > > > Do you know if there is any other way to make space animations with
> > > > shining star objects on LG and HTC devices? I have produced 2 apps
> > > > with 3D space effects, but I can't release them for LG and HTC. It is
> > > > the same thing for SonyEricsson, by the way. My space apps work
> > > > exactly like they should on Samsung and most other Android devices,
> > > > but I would really like to release them for LG, HTC and SonyEricsson
> > > > also.
>
> > > > On Sep 28, 1:03 am, Indicator Veritatis wrote:
>
> > > > > Now that I know what you are doing with the point attentuation, I see
> > > > > that you are not using it for anti-aliasing, so that comment turned
> > > > > out to lead to a dead end. As for why it is not supported, yes, it is
> > > > > in the Open GL standard, but is it in ES? ES doesn't support
> > > > > everything. And what do you get on those phones when you query
> > > > > glGet(GL_POINT_SIZE_RANGE) and glGet(GL_POINT_SIZE_GRANULARITY) or
> > > > > GL_SMOOTH_POINT_SIZE_RANGE and GL_SMOOTH_POINT_SIZE_GRANULARITY?
>
> > > > > On Sep 27, 12:26 am, MobileVisuals wrote:
>
> > > > > > I need Point attenuation to produce space animations with shining
> > > > > > particles, which look like stars. How can I achieve that effect
> > > > > > without using Point attenuation?
> > > > > > Do you mean that I should make small re
[android-developers] Re: HTC and LG haven't implemented Android in the right way
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.
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.
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.
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?
I removed all HTC devices from the compatibility list for my Morphing
galaxy live wallpaper, because the HTC users complained that it didn't
look like it should. Lots of HTC users said the same thing, so I am
sure that it doesn't work on any of the HTC's. My other LW's seem to
work well on the HTC's, but they don't use any point sprites.
On Sep 29, 11:16 am, Kostya Vasilyev wrote:
> Bitmap sprites, mapped to a quad, perhaps of a few predefined sizes, picking
> up the closest match and scaling to exact desired size You could then
> distort the quad to provide a kind of hyperspeed blur effect near the edges
> of the screen
>
> BTW, I wanted to check out your wallpaper on my HTC Incredible S, but Market
> won't let me install, reporting it as not compatible with the device.
>
> -- Kostya
>
> 2011/9/29 MobileVisuals
>
> > Does anyone know if there is any other way to make space animations
> > with
> > shining star objects on HTC devices, where size attenuation don't
> > work?
>
> > On Sep 28, 10:29 am, MobileVisuals wrote:
> > > Yes, it is in the OpenGL ES standard according to the book "Mobile 3D
> > > Graphics with OpenGL ES and M3G" by Morgan Kaufmann. Here are 3 quotes
> > > from that book:
> > > --
> > > "OpenGL ES 1.0 supports the geometric primitives shown in Figure 3.3:
> > > points, lines, and
> > > triangles. OpenGL ES 1.1 amends this list with point sprites."
>
> > > "OpenGL ES 1.1 provides features for points that are especially useful
> > > for particle effects:
> > > point sprites, point size arrays, and point size attenuation."
>
> > > "When points are defined by an array, in OpenGL ES 1.0 they all have
> > > the same size, defined by glPointSize{fx}. In OpenGL ES 1.1 it is
> > > possible to give each point its own size (see Section 8.1.2), and the
> > > point sizes may be attenuated by the distance between each
> > > point and the camera."
> > > -
> > > Could it be that the new HTC and LG devices only have OpenGL ES 1.0?
> > > Devices with names like HTC HD and LG Optimus. I don't see anything HD
> > > or optimus about them if they support an old OpenGL ES standard.
>
> > > I don't have any HTC or LG devices, so I can't test
> > > glGet(GL_POINT_SIZE_RANGE), but it would be interesting to so.
>
> > > Do you know if there is any other way to make space animations with
> > > shining star objects on LG and HTC devices? I have produced 2 apps
> > > with 3D space effects, but I can't release them for LG and HTC. It is
> > > the same thing for SonyEricsson, by the way. My space apps work
> > > exactly like they should on Samsung and most other Android devices,
> > > but I would really like to release them for LG, HTC and SonyEricsson
> > > also.
>
> > > On Sep 28, 1:03 am, Indicator Veritatis wrote:
>
> > > > Now that I know what you are doing with the point attentuation, I see
> > > > that you are not using it for anti-aliasing, so that comment turned
> > > > out to lead to a dead end. As for why it is not supported, yes, it is
> > > > in the Open GL standard, but is it in ES? ES doesn't support
> > > > everything. And what do you get on those phones when you query
> > > > glGet(GL_POINT_SIZE_RANGE) and glGet(GL_POINT_SIZE_GRANULARITY) or
> > > > GL_SMOOTH_POINT_SIZE_RANGE and GL_SMOOTH_POINT_SIZE_GRANULARITY?
>
> > > > On Sep 27, 12:26 am, MobileVisuals wrote:
>
> > > > > I need Point attenuation to produce space animations with shining
> > > > > particles, which look like stars. How can I achieve that effect
> > > > > without using Point attenuation?
> > > > > Do you mean that I should make small rectangular polygons with
> > > > > transparent textures instead? I have tried that before on M3G and it
> > > > > didn't look as good as Point attenuation.
>
> > > > > Anti-Aliasing is a method of fooling the eye that a jagged edge is
> > > > > really smooth.Will that really be enough to get the same effect as
> > > > > Point attenuation? Could you please be more specific in which OpenGL
> > > > > technique I should use to make it work on HTC and LG?
>
> > > > > Isn't Point attenuation a part of the Android OpenGL standard?
> > > > > Shouldn't HTC and LG
Re: [android-developers] Re: HTC and LG haven't implemented Android in the right way
Bitmap sprites, mapped to a quad, perhaps of a few predefined sizes, picking
up the closest match and scaling to exact desired size You could then
distort the quad to provide a kind of hyperspeed blur effect near the edges
of the screen
BTW, I wanted to check out your wallpaper on my HTC Incredible S, but Market
won't let me install, reporting it as not compatible with the device.
-- Kostya
2011/9/29 MobileVisuals
> Does anyone know if there is any other way to make space animations
> with
> shining star objects on HTC devices, where size attenuation don't
> work?
>
> On Sep 28, 10:29 am, MobileVisuals wrote:
> > Yes, it is in the OpenGL ES standard according to the book "Mobile 3D
> > Graphics with OpenGL ES and M3G" by Morgan Kaufmann. Here are 3 quotes
> > from that book:
> > --
> > "OpenGL ES 1.0 supports the geometric primitives shown in Figure 3.3:
> > points, lines, and
> > triangles. OpenGL ES 1.1 amends this list with point sprites."
> >
> > "OpenGL ES 1.1 provides features for points that are especially useful
> > for particle effects:
> > point sprites, point size arrays, and point size attenuation."
> >
> > "When points are defined by an array, in OpenGL ES 1.0 they all have
> > the same size, defined by glPointSize{fx}. In OpenGL ES 1.1 it is
> > possible to give each point its own size (see Section 8.1.2), and the
> > point sizes may be attenuated by the distance between each
> > point and the camera."
> > -
> > Could it be that the new HTC and LG devices only have OpenGL ES 1.0?
> > Devices with names like HTC HD and LG Optimus. I don't see anything HD
> > or optimus about them if they support an old OpenGL ES standard.
> >
> > I don't have any HTC or LG devices, so I can't test
> > glGet(GL_POINT_SIZE_RANGE), but it would be interesting to so.
> >
> > Do you know if there is any other way to make space animations with
> > shining star objects on LG and HTC devices? I have produced 2 apps
> > with 3D space effects, but I can't release them for LG and HTC. It is
> > the same thing for SonyEricsson, by the way. My space apps work
> > exactly like they should on Samsung and most other Android devices,
> > but I would really like to release them for LG, HTC and SonyEricsson
> > also.
> >
> > On Sep 28, 1:03 am, Indicator Veritatis wrote:
> >
> > > Now that I know what you are doing with the point attentuation, I see
> > > that you are not using it for anti-aliasing, so that comment turned
> > > out to lead to a dead end. As for why it is not supported, yes, it is
> > > in the Open GL standard, but is it in ES? ES doesn't support
> > > everything. And what do you get on those phones when you query
> > > glGet(GL_POINT_SIZE_RANGE) and glGet(GL_POINT_SIZE_GRANULARITY) or
> > > GL_SMOOTH_POINT_SIZE_RANGE and GL_SMOOTH_POINT_SIZE_GRANULARITY?
> >
> > > On Sep 27, 12:26 am, MobileVisuals wrote:
> >
> > > > I need Point attenuation to produce space animations with shining
> > > > particles, which look like stars. How can I achieve that effect
> > > > without using Point attenuation?
> > > > Do you mean that I should make small rectangular polygons with
> > > > transparent textures instead? I have tried that before on M3G and it
> > > > didn't look as good as Point attenuation.
> >
> > > > Anti-Aliasing is a method of fooling the eye that a jagged edge is
> > > > really smooth.Will that really be enough to get the same effect as
> > > > Point attenuation? Could you please be more specific in which OpenGL
> > > > technique I should use to make it work on HTC and LG?
> >
> > > > Isn't Point attenuation a part of the Android OpenGL standard?
> > > > Shouldn't HTC and LG support it in that case?
> >
> > > > On Sep 27, 3:34 am, Indicator Veritatis wrote:
> >
> > > > > Short answer: no. Longer: why do you need point attenuation? There
> are
> > > > > other ways to do anti-aliasing, and some really cool graphics have
> > > > > been done for Android phones using that instead of point
> attenuation.
> >
> > > > > On Sep 26, 6:26 am, MobileVisuals
> wrote:
> >
> > > > > > I have found that everything implemented with Point attenuation
> will
> > > > > > look like a blurry mess on devices from HTC and LG. This happens
> on
> > > > > > even the newest devices from HTC, like HTC Desire HD. Why is it
> like
> > > > > > this? Haven't they implemented Android in the right way?
> >
> > > > > > Point attenuation works like it should on most Android devices,
> like
> > > > > > those from Samsung. I have implemented Point attenuation
> according to
> > > > > > the Android specification in two of my company's apps.I have
> worked
> > > > > > with Point attenuation on Symbian and C++ before, so I am quite
> sure
> > > > > > that I have implemented it the right way. It is about the same
> code
> > > > > > implementation in all OpenGL.
> >
> > > > > > Shouldn't all new Android devices support Point attenuation? It
> works
[android-developers] Re: HTC and LG haven't implemented Android in the right way
Does anyone know if there is any other way to make space animations
with
shining star objects on HTC devices, where size attenuation don't
work?
On Sep 28, 10:29 am, MobileVisuals wrote:
> Yes, it is in the OpenGL ES standard according to the book "Mobile 3D
> Graphics with OpenGL ES and M3G" by Morgan Kaufmann. Here are 3 quotes
> from that book:
> --
> "OpenGL ES 1.0 supports the geometric primitives shown in Figure 3.3:
> points, lines, and
> triangles. OpenGL ES 1.1 amends this list with point sprites."
>
> "OpenGL ES 1.1 provides features for points that are especially useful
> for particle effects:
> point sprites, point size arrays, and point size attenuation."
>
> "When points are defined by an array, in OpenGL ES 1.0 they all have
> the same size, defined by glPointSize{fx}. In OpenGL ES 1.1 it is
> possible to give each point its own size (see Section 8.1.2), and the
> point sizes may be attenuated by the distance between each
> point and the camera."
> -
> Could it be that the new HTC and LG devices only have OpenGL ES 1.0?
> Devices with names like HTC HD and LG Optimus. I don't see anything HD
> or optimus about them if they support an old OpenGL ES standard.
>
> I don't have any HTC or LG devices, so I can't test
> glGet(GL_POINT_SIZE_RANGE), but it would be interesting to so.
>
> Do you know if there is any other way to make space animations with
> shining star objects on LG and HTC devices? I have produced 2 apps
> with 3D space effects, but I can't release them for LG and HTC. It is
> the same thing for SonyEricsson, by the way. My space apps work
> exactly like they should on Samsung and most other Android devices,
> but I would really like to release them for LG, HTC and SonyEricsson
> also.
>
> On Sep 28, 1:03 am, Indicator Veritatis wrote:
>
> > Now that I know what you are doing with the point attentuation, I see
> > that you are not using it for anti-aliasing, so that comment turned
> > out to lead to a dead end. As for why it is not supported, yes, it is
> > in the Open GL standard, but is it in ES? ES doesn't support
> > everything. And what do you get on those phones when you query
> > glGet(GL_POINT_SIZE_RANGE) and glGet(GL_POINT_SIZE_GRANULARITY) or
> > GL_SMOOTH_POINT_SIZE_RANGE and GL_SMOOTH_POINT_SIZE_GRANULARITY?
>
> > On Sep 27, 12:26 am, MobileVisuals wrote:
>
> > > I need Point attenuation to produce space animations with shining
> > > particles, which look like stars. How can I achieve that effect
> > > without using Point attenuation?
> > > Do you mean that I should make small rectangular polygons with
> > > transparent textures instead? I have tried that before on M3G and it
> > > didn't look as good as Point attenuation.
>
> > > Anti-Aliasing is a method of fooling the eye that a jagged edge is
> > > really smooth.Will that really be enough to get the same effect as
> > > Point attenuation? Could you please be more specific in which OpenGL
> > > technique I should use to make it work on HTC and LG?
>
> > > Isn't Point attenuation a part of the Android OpenGL standard?
> > > Shouldn't HTC and LG support it in that case?
>
> > > On Sep 27, 3:34 am, Indicator Veritatis wrote:
>
> > > > Short answer: no. Longer: why do you need point attenuation? There are
> > > > other ways to do anti-aliasing, and some really cool graphics have
> > > > been done for Android phones using that instead of point attenuation.
>
> > > > On Sep 26, 6:26 am, MobileVisuals wrote:
>
> > > > > I have found that everything implemented with Point attenuation will
> > > > > look like a blurry mess on devices from HTC and LG. This happens on
> > > > > even the newest devices from HTC, like HTC Desire HD. Why is it like
> > > > > this? Haven't they implemented Android in the right way?
>
> > > > > Point attenuation works like it should on most Android devices, like
> > > > > those from Samsung. I have implemented Point attenuation according to
> > > > > the Android specification in two of my company's apps.I have worked
> > > > > with Point attenuation on Symbian and C++ before, so I am quite sure
> > > > > that I have implemented it the right way. It is about the same code
> > > > > implementation in all OpenGL.
>
> > > > > Shouldn't all new Android devices support Point attenuation? It works
> > > > > on IPhone, so I think Point attenuation should work on all new Android
> > > > > devices too.
--
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
[android-developers] Re: HTC and LG haven't implemented Android in the right way
Yes, it is in the OpenGL ES standard according to the book "Mobile 3D
Graphics with OpenGL ES and M3G" by Morgan Kaufmann. Here are 3 quotes
from that book:
--
"OpenGL ES 1.0 supports the geometric primitives shown in Figure 3.3:
points, lines, and
triangles. OpenGL ES 1.1 amends this list with point sprites."
"OpenGL ES 1.1 provides features for points that are especially useful
for particle effects:
point sprites, point size arrays, and point size attenuation."
"When points are defined by an array, in OpenGL ES 1.0 they all have
the same size, defined by glPointSize{fx}. In OpenGL ES 1.1 it is
possible to give each point its own size (see Section 8.1.2), and the
point sizes may be attenuated by the distance between each
point and the camera."
-
Could it be that the new HTC and LG devices only have OpenGL ES 1.0?
Devices with names like HTC HD and LG Optimus. I don't see anything HD
or optimus about them if they support an old OpenGL ES standard.
I don't have any HTC or LG devices, so I can't test
glGet(GL_POINT_SIZE_RANGE), but it would be interesting to so.
Do you know if there is any other way to make space animations with
shining star objects on LG and HTC devices? I have produced 2 apps
with 3D space effects, but I can't release them for LG and HTC. It is
the same thing for SonyEricsson, by the way. My space apps work
exactly like they should on Samsung and most other Android devices,
but I would really like to release them for LG, HTC and SonyEricsson
also.
On Sep 28, 1:03 am, Indicator Veritatis wrote:
> Now that I know what you are doing with the point attentuation, I see
> that you are not using it for anti-aliasing, so that comment turned
> out to lead to a dead end. As for why it is not supported, yes, it is
> in the Open GL standard, but is it in ES? ES doesn't support
> everything. And what do you get on those phones when you query
> glGet(GL_POINT_SIZE_RANGE) and glGet(GL_POINT_SIZE_GRANULARITY) or
> GL_SMOOTH_POINT_SIZE_RANGE and GL_SMOOTH_POINT_SIZE_GRANULARITY?
>
> On Sep 27, 12:26 am, MobileVisuals wrote:
>
> > I need Point attenuation to produce space animations with shining
> > particles, which look like stars. How can I achieve that effect
> > without using Point attenuation?
> > Do you mean that I should make small rectangular polygons with
> > transparent textures instead? I have tried that before on M3G and it
> > didn't look as good as Point attenuation.
>
> > Anti-Aliasing is a method of fooling the eye that a jagged edge is
> > really smooth.Will that really be enough to get the same effect as
> > Point attenuation? Could you please be more specific in which OpenGL
> > technique I should use to make it work on HTC and LG?
>
> > Isn't Point attenuation a part of the Android OpenGL standard?
> > Shouldn't HTC and LG support it in that case?
>
> > On Sep 27, 3:34 am, Indicator Veritatis wrote:
>
> > > Short answer: no. Longer: why do you need point attenuation? There are
> > > other ways to do anti-aliasing, and some really cool graphics have
> > > been done for Android phones using that instead of point attenuation.
>
> > > On Sep 26, 6:26 am, MobileVisuals wrote:
>
> > > > I have found that everything implemented with Point attenuation will
> > > > look like a blurry mess on devices from HTC and LG. This happens on
> > > > even the newest devices from HTC, like HTC Desire HD. Why is it like
> > > > this? Haven't they implemented Android in the right way?
>
> > > > Point attenuation works like it should on most Android devices, like
> > > > those from Samsung. I have implemented Point attenuation according to
> > > > the Android specification in two of my company's apps.I have worked
> > > > with Point attenuation on Symbian and C++ before, so I am quite sure
> > > > that I have implemented it the right way. It is about the same code
> > > > implementation in all OpenGL.
>
> > > > Shouldn't all new Android devices support Point attenuation? It works
> > > > on IPhone, so I think Point attenuation should work on all new Android
> > > > devices too.
--
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
[android-developers] Re: HTC and LG haven't implemented Android in the right way
Now that I know what you are doing with the point attentuation, I see that you are not using it for anti-aliasing, so that comment turned out to lead to a dead end. As for why it is not supported, yes, it is in the Open GL standard, but is it in ES? ES doesn't support everything. And what do you get on those phones when you query glGet(GL_POINT_SIZE_RANGE) and glGet(GL_POINT_SIZE_GRANULARITY) or GL_SMOOTH_POINT_SIZE_RANGE and GL_SMOOTH_POINT_SIZE_GRANULARITY? On Sep 27, 12:26 am, MobileVisuals wrote: > I need Point attenuation to produce space animations with shining > particles, which look like stars. How can I achieve that effect > without using Point attenuation? > Do you mean that I should make small rectangular polygons with > transparent textures instead? I have tried that before on M3G and it > didn't look as good as Point attenuation. > > Anti-Aliasing is a method of fooling the eye that a jagged edge is > really smooth.Will that really be enough to get the same effect as > Point attenuation? Could you please be more specific in which OpenGL > technique I should use to make it work on HTC and LG? > > Isn't Point attenuation a part of the Android OpenGL standard? > Shouldn't HTC and LG support it in that case? > > On Sep 27, 3:34 am, Indicator Veritatis wrote: > > > Short answer: no. Longer: why do you need point attenuation? There are > > other ways to do anti-aliasing, and some really cool graphics have > > been done for Android phones using that instead of point attenuation. > > > On Sep 26, 6:26 am, MobileVisuals wrote: > > > > I have found that everything implemented with Point attenuation will > > > look like a blurry mess on devices from HTC and LG. This happens on > > > even the newest devices from HTC, like HTC Desire HD. Why is it like > > > this? Haven't they implemented Android in the right way? > > > > Point attenuation works like it should on most Android devices, like > > > those from Samsung. I have implemented Point attenuation according to > > > the Android specification in two of my company's apps.I have worked > > > with Point attenuation on Symbian and C++ before, so I am quite sure > > > that I have implemented it the right way. It is about the same code > > > implementation in all OpenGL. > > > > Shouldn't all new Android devices support Point attenuation? It works > > > on IPhone, so I think Point attenuation should work on all new Android > > > devices too. -- 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
[android-developers] Re: HTC and LG haven't implemented Android in the right way
Yes, that is exactly what I am doing. I am using point sprites with size attenuation for my space animations, like the Morphing Galaxy live wallpaper. But what is the use of point sprites if the size attenuation do not work? The size attenuation is not supported on devices from HTC and LG. This is what I mean with size attenuation: http://www.opengl.org/sdk/docs/man/xhtml/glPointSize.xml All the point sprites get the same size if the size attenuation do not work, which results in a blurry mess. It looks like it should on most Android devices, but not those from HTC and LG. On Sep 27, 7:11 pm, Nightwolf wrote: > Point sprites can be used to display stars in space. > > On 27 сен, 11:26, MobileVisuals wrote: > > > I need Point attenuation to produce space animations with shining > > particles, which look like stars. How can I achieve that effect > > without using Point attenuation? > > Do you mean that I should make small rectangular polygons with > > transparent textures instead? I have tried that before on M3G and it > > didn't look as good as Point attenuation. > > > Anti-Aliasing is a method of fooling the eye that a jagged edge is > > really smooth.Will that really be enough to get the same effect as > > Point attenuation? Could you please be more specific in which OpenGL > > technique I should use to make it work on HTC and LG? > > > Isn't Point attenuation a part of the Android OpenGL standard? > > Shouldn't HTC and LG support it in that case? > > > On Sep 27, 3:34 am, Indicator Veritatis wrote: > > > > Short answer: no. Longer: why do you need point attenuation? There are > > > other ways to do anti-aliasing, and some really cool graphics have > > > been done for Android phones using that instead of point attenuation. > > > > On Sep 26, 6:26 am, MobileVisuals wrote: > > > > > I have found that everything implemented with Point attenuation will > > > > look like a blurry mess on devices from HTC and LG. This happens on > > > > even the newest devices from HTC, like HTC Desire HD. Why is it like > > > > this? Haven't they implemented Android in the right way? > > > > > Point attenuation works like it should on most Android devices, like > > > > those from Samsung. I have implemented Point attenuation according to > > > > the Android specification in two of my company's apps.I have worked > > > > with Point attenuation on Symbian and C++ before, so I am quite sure > > > > that I have implemented it the right way. It is about the same code > > > > implementation in all OpenGL. > > > > > Shouldn't all new Android devices support Point attenuation? It works > > > > on IPhone, so I think Point attenuation should work on all new Android > > > > devices too. -- 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
[android-developers] Re: HTC and LG haven't implemented Android in the right way
Point sprites can be used to display stars in space. On 27 сен, 11:26, MobileVisuals wrote: > I need Point attenuation to produce space animations with shining > particles, which look like stars. How can I achieve that effect > without using Point attenuation? > Do you mean that I should make small rectangular polygons with > transparent textures instead? I have tried that before on M3G and it > didn't look as good as Point attenuation. > > Anti-Aliasing is a method of fooling the eye that a jagged edge is > really smooth.Will that really be enough to get the same effect as > Point attenuation? Could you please be more specific in which OpenGL > technique I should use to make it work on HTC and LG? > > Isn't Point attenuation a part of the Android OpenGL standard? > Shouldn't HTC and LG support it in that case? > > On Sep 27, 3:34 am, Indicator Veritatis wrote: > > > > > Short answer: no. Longer: why do you need point attenuation? There are > > other ways to do anti-aliasing, and some really cool graphics have > > been done for Android phones using that instead of point attenuation. > > > On Sep 26, 6:26 am, MobileVisuals wrote: > > > > I have found that everything implemented with Point attenuation will > > > look like a blurry mess on devices from HTC and LG. This happens on > > > even the newest devices from HTC, like HTC Desire HD. Why is it like > > > this? Haven't they implemented Android in the right way? > > > > Point attenuation works like it should on most Android devices, like > > > those from Samsung. I have implemented Point attenuation according to > > > the Android specification in two of my company's apps.I have worked > > > with Point attenuation on Symbian and C++ before, so I am quite sure > > > that I have implemented it the right way. It is about the same code > > > implementation in all OpenGL. > > > > Shouldn't all new Android devices support Point attenuation? It works > > > on IPhone, so I think Point attenuation should work on all new Android > > > devices too. -- 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
[android-developers] Re: HTC and LG haven't implemented Android in the right way
I need Point attenuation to produce space animations with shining particles, which look like stars. How can I achieve that effect without using Point attenuation? Do you mean that I should make small rectangular polygons with transparent textures instead? I have tried that before on M3G and it didn't look as good as Point attenuation. Anti-Aliasing is a method of fooling the eye that a jagged edge is really smooth.Will that really be enough to get the same effect as Point attenuation? Could you please be more specific in which OpenGL technique I should use to make it work on HTC and LG? Isn't Point attenuation a part of the Android OpenGL standard? Shouldn't HTC and LG support it in that case? On Sep 27, 3:34 am, Indicator Veritatis wrote: > Short answer: no. Longer: why do you need point attenuation? There are > other ways to do anti-aliasing, and some really cool graphics have > been done for Android phones using that instead of point attenuation. > > On Sep 26, 6:26 am, MobileVisuals wrote: > > > I have found that everything implemented with Point attenuation will > > look like a blurry mess on devices from HTC and LG. This happens on > > even the newest devices from HTC, like HTC Desire HD. Why is it like > > this? Haven't they implemented Android in the right way? > > > Point attenuation works like it should on most Android devices, like > > those from Samsung. I have implemented Point attenuation according to > > the Android specification in two of my company's apps.I have worked > > with Point attenuation on Symbian and C++ before, so I am quite sure > > that I have implemented it the right way. It is about the same code > > implementation in all OpenGL. > > > Shouldn't all new Android devices support Point attenuation? It works > > on IPhone, so I think Point attenuation should work on all new Android > > devices too. -- 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
[android-developers] Re: HTC and LG haven't implemented Android in the right way
Short answer: no. Longer: why do you need point attenuation? There are other ways to do anti-aliasing, and some really cool graphics have been done for Android phones using that instead of point attenuation. On Sep 26, 6:26 am, MobileVisuals wrote: > I have found that everything implemented with Point attenuation will > look like a blurry mess on devices from HTC and LG. This happens on > even the newest devices from HTC, like HTC Desire HD. Why is it like > this? Haven't they implemented Android in the right way? > > Point attenuation works like it should on most Android devices, like > those from Samsung. I have implemented Point attenuation according to > the Android specification in two of my company's apps.I have worked > with Point attenuation on Symbian and C++ before, so I am quite sure > that I have implemented it the right way. It is about the same code > implementation in all OpenGL. > > Shouldn't all new Android devices support Point attenuation? It works > on IPhone, so I think Point attenuation should work on all new Android > devices too. -- 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
