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 -~----------~----~----~----~------~----~------~--~---
