Re: [android-developers] Re: HTC and LG haven't implemented Android in the right way

2011-10-14 Thread Latimerius 
On Wed, Oct 12, 2011 at 7:09 PM, MobileVisuals eyv...@astralvisuals.com 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

2011-10-11 Thread Latimerius 
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
eyv...@astralvisuals.com 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

2011-10-11 Thread Latimerius 
On Tue, Oct 11, 2011 at 8:38 PM, MobileVisuals eyv...@astralvisuals.com wrote:
 I see, now I understand the color4f method. I can't sort the
 transparent sprites back-to-front,because they are all in one vertex
 array. It would be much slower if I had one vertex array for each
 quad, because it would be so many drawArray calls.

Think about your problem from the depth sorting perspective.  Again, I
don't know what exactly you are doing but your geometry looks quite
regular to me - perhaps the depth sorting, once established, never
changes?

If you're drawing everything in a single glDrawArrays() call then all
of your quads share the same transformation (the same values you pass
to glTranslate()/glRotate()/glScale()).  If that's the case your
geometry is likely pre-transformed (you transform vertices of each
quad before putting them into the array) - could you sort the quads as
you transform them?

Try to take advantage of any problem-specific knowledge you have (and
I don't).  In my experience it's rather unlikely that you're unable to
do the required depth sorting.

 I will only use one layer of quads from now on. But the particles in
 the animation are morphed, so one particle will sometimes be placed
 above another.
 Do you mean that this will always result in black quads?

Unfortunately yes.  When using translucency with depth buffering I
don't know of any other solution, in general.

To understand this consider you draw a partially transparent quad,
just like one of yours.  Its transparent pixels will not change the
frame buffer since they are transparent - the corresponding frame
buffer pixels will stay at your clear colour.  However, the quad also
writes into the depth buffer.

Now, consider another quad comes that (partially) overlaps with the
first one and should be visible where the first quad had transparent
parts.  Also consider that this second quad can be further away from
the camera which can well happen since your quads are *not*
back-to-front sorted.  The second quad will be prevented by depth test
from writing to any pixels touched by the first quad.  This means your
clear colour remains where the first sprite was
transparent/translucent.  Hence your black rectangle - a quad close to
camera comes first and blocks other quads further away from the camera
from writing over it.

I'm afraid you will have to figure out how to depth-sort your geometry
properly.  As I said before, it shouldn't be *that* tough. ;-)

 I will only use star1.png for testing,since you said that image was
 correct. I used this guide to add the alpha channel:
 http://fabiovisentin.com/tutorial/gimp_transparent_image/gimp_how_to_make_transparent_image.asp

That is a fine tutorial, however you will notice the example image has
(perhaps apart from some anti-aliasing) sharp edges.  The process they
describe there is appropriate for that sort of images.  However, your
stuff is supposed to smoothly blend into its surroundings, with no
defined edge, pretty much.  The process from the tutorial is not well
suited for this kind of image.

Consider getting rid of the black component in your art for instance
by loading it into Gimp, then going to Colours-Colour to Alpha... and
setting the colour to black.  I checked and even star1.png seems to
have more black in it than would look right ...

Only you know what you're trying to achieve so this might or might not
be an appropriate fix.  To me, your art fixed like this looks about
right and ready for some serious blending. ;-)

-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

Re: [android-developers] Re: HTC and LG haven't implemented Android in the right way

2011-10-07 Thread Kostya Vasilyev 
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 Vasilyevkmans...@gmail.com  wrote:

29.09.2011 23:01, MobileVisuals ?:


I claim that HTC HD doesn't support OpenGL ES 2.0, because size
attenuation is a part of OpenGL ES 1.1 and it is not supported.

Quite possibly, you're right...


So HTC hasn't implemented the things that they say in the
specification, but why not?

Who knows?

You could contact their support, but even if they provide a plausible
answer (and that's a big if), it's not going to magically fix all the
HTC devices out there...


Thanks for the idea, do you mean like this?
Scale to small size if the sprite is far away.
Scale to medium size if the sprite is medium distance.
Scale to big size if the sprite is close.

More or less - you are currently doing continuous range scaling of your
sprites (I presume). If you replace them with texture mapped quads, you
could always use the same image, or pick one of the ones predefined at
various scale factors, to improve the image quality and performance.
Sort of like mip-mapping.

But that's not the core idea - the main thing is to replace attenuated
points with texture mapped quads.


That could work for other animations, but it would be very slow for my
star cluster animations. There are hundreds of stars in each cluster.
As it is now, I draw each star cluster in one single glDrawArrays
call. That makes it fast.

Hundreds doesn't sound too bad - at those poly counts, it's the fill
rate (overdraw) that can kill performance. But since sprites are
typically small, it probably won't be an issue.


Wouldn't I have to make one glDrawArrays call for each one of the
stars if I had to scale them in different sizes? That would mean
hundreds of glDrawArrays calls instead of one.

Not the way I'm reading the docs (mind you, my GL is more than a little
rusty - last time I worked with 3D was more than 10 years ago)

But it seems like you should be able to draw all quads that use the same
texture in one call, using GL_TRIANGLES or GL_QUADS (not _STRIP or _FAN,
because those are always joined). This can product transparency
artifacts depending on their z-order, so you'd need to sort the quads
according to their texture and z-order both.

Or just forgo the mipmapping for initial tests, then there's be one less
thing to worry about with respect to sorting.


A point sprite is a screen-aligned element of variable size that is
defined by a single point. Would it really be a sprite if it was
mapped to a quad polygon?

If it looks like a sprite, and quacks like a sprite...

--
Kostya Vasilyev


--
Kostya Vasilyev

--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

Re: [android-developers] Re: HTC and LG haven't implemented Android in the right way

2011-09-29 Thread Kostya Vasilyev 
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 eyv...@astralvisuals.com

 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 eyv...@astralvisuals.com 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 mej1...@yahoo.com 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 eyv...@astralvisuals.com 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 mej1...@yahoo.com 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 eyv...@astralvisuals.com
 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

Re: [android-developers] Re: HTC and LG haven't implemented Android in the right way

2011-09-29 Thread Kostya Vasilyev 


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