Ah, so the batch methods work on top of vertex arrays / vertex buffers. Awesome; I will check out all of these.
On Nov 4, 4:22 pm, Jonathan Hartley <[EMAIL PROTECTED]> wrote: > As I understand it, the pyglet docs are referring to all the members > of pyglet.gl, which are automatically generated python bindings to all > the OpenGL functions. They are not necessarily the most convenient, > Pythonic or efficient ways you could imagine calling OpenGL from > Python. They are mostly intended for internal use by the rest of > pyglet, although there's no harm in using them yourself too. > > However, the real intent is for you to use the alternative functions > that pyglet provides, under pyglet.graphics, and sprites (everything > NOT in pyglet.gl.) These are designed to be both convenient to use, > and super fast. > > For example, pyglet.graphics.batch as josch mentions, uses OpenGL's > super-fast vertex arrays stored in vertex buffer objects, without us > having to worry about that underlying details *too* much. > > On Nov 4, 4:02 pm, Lunpa <[EMAIL PROTECTED]> wrote: > > > Interesting. I'm looking at the 'graphics' section in the programing > > guide and it says this: "using the OpenGL interface directly for > > drawing graphics is difficult and inefficient". Why is that? (and is > > there a better one to use?) > > > On Nov 4, 3:37 am, Jonathan Hartley <[EMAIL PROTECTED]> wrote: > > > > This may or may not prove to be significant for you, but I found > > > better performance on my hardware using batches of indexed > > > GL_TRIANGLES, rather than GL_TRIANGLE_STRIPS or GL_TRIANGLE_FANS. I > > > didn't try GL_QUADS though. > > > > The fewer batches you can render, the better - so if your cubes don't > > > move or rotate independently of each other, then rendering them all in > > > a single batch object will be much faster. > > > > On Nov 4, 5:34 am, Lunpa <[EMAIL PROTECTED]> wrote: > > > > > I've been teaching myself opengl recently, and I've hit a wall, which > > > > is what to do with bottlenecks, or let alone, figure out what is > > > > causing them. > > > > > I wrote a short program (based off of the pyglet "hene" port of the > > > > nehe lesson1 base case) to illustrate what is vexing me, or atleast as > > > > best as I can pin it down; > > > > > I have a function called "call", which is called from the on_draw > > > > event of the window, and the function contains the following code: > > > > > def call(self): > > > > if not self.__compiled: > > > > glNewList(self.__dl, GL_COMPILE) > > > > > r = 5 > > > > ci = 0 > > > > span = range(r*-4, (r*4)+1, 4) > > > > for x in span: > > > > for y in span: > > > > draw_cube(x, 0, y, ci) > > > > ci +=1 > > > > if ci > 1: > > > > ci = 0 > > > > glEndList() > > > > self.__compiled = True > > > > > glCallList(self.__dl) > > > > > the "draw_cube" function just calls a glBegin(GL_QUADS), 24 > > > > glVertex3f's, and the glEnd() > > > > > When I run this program with just the basecode (eg, I have the call > > > > function commented out), > > > > the thing can do well over 60 fps (spikes over 100, sporadically). > > > > > When I have the function in the code, the code plummets to an average > > > > of 20fps. > > > > > What do I need to do to be able to draw more than a handful of > > > > polygons without dramatic slowdowns??? > > > > > ps: my gpu is an intel 945gm; not exactly a powerhouse, but the code > > > > has been tested on other machines with similar results. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
