Hey Tristam, Thanks very much for the feedback. I just ten minutes ago subscribed to your blog, upon discovering your pyglet experimental shader module! :-) *That's* certainly going to save me some (not inconsiderable, for me) effort.
I've currently planned the game design around the couple of hundred meshes I seem to be able to get using the traditional API on relatively modest hardware. I was thinking that any extra meshes I could get on top of that would be handy for adding relatively superfluous (but cool!) special effects (fancier explosions, blowing smoke, rendered in a retro-styled vector manner.) On Apr 19, 6:30 pm, Tristam MacDonald <[email protected]> wrote: > 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 MacDonaldhttp://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 -~----------~----~----~----~------~----~------~--~---
