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 <mikh...@gmail.com> 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 <eyv...@astralvisuals.com> 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 <eyv...@astralvisuals.com> 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 <l4t1m3r...@googlemail.com> wrote:
>
> > > > 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
