Sure, if you don't change the time varying passed to the shader it would stop.
-Casey On Fri, Sep 26, 2008 at 10:14 AM, Ragzouken <[EMAIL PROTECTED]> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
