On Sun, Apr 19, 2009 at 12:54 PM, Jonathan Hartley <[email protected]>wrote:
> 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. Your understanding is correct on all these points. > 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. How many of these objects do you expect to draw in a single frame? Less than 75-100 should be perfectly fine, using a draw call each. 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? > The technique you are describing sounds like a logical extension of NVidia's technique to fake instanced geometry, on cards without instancing. As such, it should work, although I am not sure how much of a performance benefit you will see. -- Tristam MacDonald http://swiftcoder.wordpress.com/ --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
