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
