Is it possible to pause the animation with the shader solution?
On Sep 26, 4:45 pm, "Casey Duncan" <[EMAIL PROTECTED]> wrote:
> On Fri, Sep 26, 2008 at 3:37 AM, Alex Holkner <[EMAIL PROTECTED]> wrote:
>
> > On 9/26/08, Ragzouken <[EMAIL PROTECTED]> wrote:
>
> >> Is it any more efficient to change only the y coords of a vertex
> >> list's texture coords rather than both x and y if you know that frames
> >> of the same animation are vertically aligned?
>
> > In general, yes; though the logic in iterating past every second (or
> > third) float in a vertex list may outweigh the benefit. Note that
> > using a slice with a step effectively implements the same operation,
> > though pyglet handles the iteration for you (probably slower than you
> > could have done, due to generality).
>
> I don't know if this was suggested before (I skimmed the thread and
> didn't see mention), but it is possible to animate the vertex
> coordinate without changing the vertex list itself by using a shader.
> A possible method would be to store the tile type for each vertex as
> an additional vertex attribute and pass a varying "time" value from
> your application to the shader program to control the animation. The
> shader would then alter the texture coordinates (perhaps shifting them
> along the Y or Z for a 3D texture) according to the vertex attribute
> (for instance leaving the coords alone for non-animated tiles) and the
> time value. The major downside to this approach is it requires opengl
> 2.0, which may be a non-starter. The upside is zero CPU cost for
> shaders running in the hardware.
>
> Alternately, you could divide your vertex list into animated and
> non-animated tiles and draw them separately. In one pass you could lay
> down the non-animated tiles, and in a second the animated ones. So
> long as the latter does not overdraw the non-animated tiles, it will
> look the same and allow you to have the non-animated tiles have a
> static vertex list. Thus you update a significantly smaller vertex
> list to animate. This assumes that a large fraction of the tiles are
> not animated, however.
>
> Yet another approach would be to switch the base texture rather than
> the texture coordinates. Rather than putting every possible tile type
> over time in a single texture, only put ones that will be shown at the
> same time. Then switch which texture is active to animate. If many or
> most tiles are not animated, you can combine this idea with the above
> and keep the non-animated texture completely separate, thus removing
> redundant tile textures to save space. The downside to this is that
> all animated textures would have to operate in lock-step (have the
> same texture at the same time), which may not look as good. But you
> could get around this by having multiple water types at the cost of
> larger textures.
>
> Still another approach would be to abandon updating the vertex list in
> python (assuming doing that is the bottleneck) and write some C code
> to generate it on the fly. You'll probably find yourself limited by
> transfer bandwidth to the video card with this approach, In
> native-code you can build a very large vertex array in short order.
>
> The shader solution is probably the most ideal. I would probably go
> for that and either disable animations when shaders are not available
> or fallback to one of the other compromise solutions above.
>
> hth,
>
> -Casey
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"pyglet-users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pyglet-users?hl=en
-~----------~----~----~----~------~----~------~--~---
