Thanks for that stampson! Wow - so quickly did I skim through the pyglet programmer's guide section on sprites that that I didn't know they could be rotated.
I'm actually using Pymunk too. (Intention is for something like 'Oids' or 'Thrust' with rigid-body physics.) There's a small degree of camera zooming in and out going on, but even so, this might be a handy idea, especially for the sorts of 'special effects' like smoke that I mention above. On Apr 20, 3:39 pm, stampson <[email protected]> wrote: > Last year I did a lot of experimenting with pymunk (ctypes bindings > for chipmunk physics) and pyglet. I was doing little demos with > randomly spawned shapes - circles, triangles, rectangles, 'sticks', > various regular polys. I hit upon the idea of rendering the shapes to > textures, and animating them as sprites rather than redrawing them. > If you're not morphing the geometries, just drawing them in different > colors, orientations, positions, and scale this works well. I was > able to greatly increase the number of shapes (now sprites) on the > screen at once. > > Then, I realized a lot of time was being wasted in multiple calls to > the sprite module - if you are updating sprites position, scale, and > orientation every frame, you can save a lot of time by making a new > sprite function to update all three at once. This second change more > than doubled the number of shapes I could draw while maintaining > target fps. > > So there might be a simple way to take advantage of sprite batches, > even if you're working with geometries . > > -price > > On 19 apr, 12:54, Jonathan Hartley <[email protected]> wrote: > > > Hi all, > > > I've just started reading through the Orange OpenGL Shader book, and > > thought I'd post my thoughts here so people can correct or confirm for > > me, thanks! > > > I'd avoided shaders until now, thinking they would be an *extra* layer > > of complexity that I didn't need while I was still getting to grips > > with OpenGL. I think they might solve a lot the problems I've been > > happily wrestling with for a while now. So now I wish I'd read the > > book and got to grips with shaders ages ago. > > > It seems that the traditional OpenGL API I've been using is a bit of > > an anti-pattern these days - especially calling it from Python. If you > > have many independently positioned and oriented meshes, then you have > > to render each one with a separate glDrawArrays (or whatever) call, > > and change the model-view matrix between each call. Making these > > multiple function calls, passing through ctypes parameter wrangling > > each time, then changing opengl state, seem to form a significant > > performance overhead. > > > As I understand it, using pyglet batches takes a *lot* of the headache > > out of this, but it still requires me to make these modelview changes > > between each batch - under the scenes is it doing the same thing as > > above? I think so but obviously would love to hear if I'm wrong. > > > Plus, it seems, support for the traditional API is often implemented > > as a shader on modern graphics hardware, and these shaders have to > > handle *all* the byzantine features of OpenGL, regardless of whether > > you're actually using those features, so these shaders used for the > > traditional API are quite large and inefficient. > > > My use case is this: I have a bunch of simple 2D geometries (~20 to > > 100 verts each) and I want to render a lot of them all over the place > > at various positions, sizes, orientations. I'm not using textures, and > > I'm not using lighting. It's all very simple. > > > Upon reading about shaders, it seems a good idea to me to create a > > single large vertex array containing modelspace co-ords for every > > entity that I want to render, and add a custom vertex attribute which > > is an index into a second array of model transformations. My vertex > > shader would retrieve the desired model transformation by indexing > > into this second array (maybe as a matrix, maybe simply as a 2D offset > > and rotation) apply the transform to generate the gl_Position output. > > It could do this on every vertex in my scene in a single call to > > glDrawArrays(), thus circumventing the function-call overhead I incur > > using the traditional API. > > > I still have to update the values in the second 'transforms' array. If > > every mesh in my scene was moving all the time, and I had to update > > each transform individually, going through ctypes every time, then I > > might just be right back where I started. But if only a few of my > > meshes are moving around at once (many in-game objects were just > > resting on the ground where they lay), or if I can update the whole > > transform matrix as a single update (maybe as the output from some > > numpy wrangling) then this might not be so bad. > > > Do people think this is a useful idea, or am I misunderstanding how > > things work? > > > Thanks for any comments, rock on everybody. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
