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
