pyopengl-users — Discussion of all PyOpenGL matters.

Re: [PyOpenGL-Users] culling with tétrahedron

[Roland E. <r.e...@gm...>]

Ian,

After some experiment based on what you say about the winding, I figure 
the problem, and now I have the correct behavior. But that still doesn't 
explain why GL_CULL_FACE is doing something, when using GL_LINE.

Roland.

Le 05/15/10 21:52, Roland Everaert a écrit :
> So how to explain that a spinning cube gives me what I want (the 
> verteces not seen by the camera are hidden)?
>
> The code is the same, but where GL_TRIANGLES is replaced by GL_QUADS, 
> the vertices and indices lists are filled accordingly and the 2nd 
> argument of glDrawElements replaced by the len of the indices list. 
> And there is no test on the depth.
>
>
> Thanks,
>
>
> Roland.
>
> Le 05/14/10 23:36, Ian Mallett a écrit :
>> Well, for one thing, you're drawing the tetrahedron in line mode.  
>> GL_CULL_FACE does nothing for GL_LINE.
>>
>> You might also try culling the front faces glCullFace(GL_FRONT).  If 
>> the results are expected, then reverse the winding order of the 
>> polygons (i.e., polygon [v1,v2,v3] specify as [v1,v3,v2]) and cull 
>> the back as before.
>>
>> Ian

Re: [PyOpenGL-Users] culling with tétrahedron

[Roland E. <r.e...@gm...>]

So how to explain that a spinning cube gives me what I want (the 
verteces not seen by the camera are hidden)?

The code is the same, but where GL_TRIANGLES is replaced by GL_QUADS, 
the vertices and indices lists are filled accordingly and the 2nd 
argument of glDrawElements replaced by the len of the indices list. And 
there is no test on the depth.


Thanks,


Roland.

Le 05/14/10 23:36, Ian Mallett a écrit :
> Well, for one thing, you're drawing the tetrahedron in line mode.  
> GL_CULL_FACE does nothing for GL_LINE.
>
> You might also try culling the front faces glCullFace(GL_FRONT).  If 
> the results are expected, then reverse the winding order of the 
> polygons (i.e., polygon [v1,v2,v3] specify as [v1,v3,v2]) and cull the 
> back as before.
>
> Ian

Re: [PyOpenGL-Users] VBOs question

[Duong D. <dan...@gm...>]

Hi again,

I actually tried the same code on other distros (Ubuntu with Intel GPU and
Gentoo with ATI GPU), my scene was rendered fine there.

Only on the first one (Fedora 12, Nvidia Quadro FX580, proprietary drivers),
that I had the problem. Is there any known distro/graphics card specific
issues? Thanks again!

D

On Fri, May 14, 2010 at 10:36 PM, Ian Mallett <geo...@gm...> wrote:

> Hi,
>
> This code looks fine to me.
>
> Someone else had this exact same problem, and the issue turned out to be
> that glClear(...) was being called every time an object was drawn--just in
> case, have you done anything of that sort in your source?
>
> Ian
>

Re: [PyOpenGL-Users] culling with tétrahedron

[Ian M. <geo...@gm...>]

Well, for one thing, you're drawing the tetrahedron in line mode.
GL_CULL_FACE does nothing for GL_LINE.

You might also try culling the front faces glCullFace(GL_FRONT).  If the
results are expected, then reverse the winding order of the polygons (i.e.,
polygon [v1,v2,v3] specify as [v1,v3,v2]) and cull the back as before.

Ian

Re: [PyOpenGL-Users] VBOs question

[Ian M. <geo...@gm...>]

Hi,

This code looks fine to me.

Someone else had this exact same problem, and the issue turned out to be
that glClear(...) was being called every time an object was drawn--just in
case, have you done anything of that sort in your source?

Ian

Re: [PyOpenGL-Users] darwinplatform -- no VBOs?

[Ian M. <geo...@gm...>]

Hi,
Not sure, but I recommend using the vbo class:
from OpenGL.arrays import vbo
Ian

[PyOpenGL-Users] culling with tétrahedron

[Roland E. <r.e...@gm...>]

Hi,

I am currently trying culling with a tetrahedron, but when I make it 
spin, some vertices disappear while they shouldn't, following the point 
of view of the camera.

Below is the code of the class I use to handle the object:

class Tetrahedron(Polyhedron):

     def __init__(self, size):

         self.vertices = [0.0, 0.0, float(size),
                          (float(size))*math.sin(120), 0.0, 
-(float(size))*math.cos(120),
                          -(float(size))*math.sin(240), 0.0, 
-(float(size))*math.cos(240),
                          0.0, float(size), 0.0]
         self.indices = [0, 1, 2,
                         0, 3, 2,
                         0, 3, 1,
                         1, 3, 2]

         Polyhedron.__init__(self)

     def render(self):

         glPolygonMode(GL_FRONT_AND_BACK, GL_LINE)
         glEnableClientState(GL_VERTEX_ARRAY)
         glVertexPointer(3, GL_FLOAT, 0, self.vertices) # Specify the 
vertex list to be used to draw the object

         glEnable(GL_CULL_FACE)
         glCullFace(GL_BACK)

         glColor3f(*self.color)
         glTranslatef (*self.position)
         glRotatef (self.x_angle, 1.0, 0.0, 0.0)
         glRotatef (self.y_angle, 0.0, 1.0, 0.0)
         glRotatef (self.z_angle, 0.0, 0.0, 1.0)
         glScalef (*self.scaling)

         glDrawElements(GL_TRIANGLES, 12, GL_UNSIGNED_BYTE, self.indices)

         glDisable(GL_CULL_FACE)

         glDisableClientState(GL_VERTEX_ARRAY)



What am I missing?

I did not face that problem with a Cube using the same code for method 
render (except for 1st and 2nd parameters of glDrawElements)

The superclass polyhedron only contains the variables used for the 
transformation and a few convenience method to set them.

I am running the code on Linux AMD 64 with pygame to get the window and 
interacting with the user.

Thanks for your help,


Roland.

[PyOpenGL-Users] VBOs question

[Duong D. <dan...@gm...>]

Hi there,

I'm rendering a scene consisting of multiple VBO objects. I basically did
the following in my callback function. But only the very last object in the
list shows up. Am I missing something?

Any help will be greatly appreciated!!

Thanks,
D

class vboObjects:
     def __init__(arg):
           self.vertex_vboId
           self.normal_vboId
           self.index_vboId
           self.count
           ....generate ids, register data into OpenGL

     def updatePositionsInScene():
          .....

def GLcallBack():
     update positions of all vbo objects
     for all vbo objects:
           glPushMatrix()
           glTranslatef(new position)

           glEnableClientState(GL_NORMAL_ARRAY);
           glEnableClientState(GL_VERTEX_ARRAY);
           glEnableClientState(GL_INDEX_ARRAY);

           glBindBufferARB(GL_ARRAY_BUFFER_ARB, vbo.vertex_vboId);
           glVertexPointer( 3, GL_FLOAT, 0, None );

           glBindBufferARB(GL_ARRAY_BUFFER_ARB, vbo.normal_vboId);
           glNormalPointer(GL_FLOAT, 0,None);

           glBindBufferARB(GL_ELEMENT_ARRAY_BUFFER_ARB, vbo.index_vboId);
           glColorPointer(3,GL_FLOAT, 0, None);

           glDrawElements(GL_TRIANGLES, vbo.count, GL_UNSIGNED_SHORT, None);

           glDisableClientState(GL_VERTEX_ARRAY);
           glDisableClientState(GL_NORMAL_ARRAY);
           glDisableClientState(GL_INDEX_ARRAY);
           glBindBufferARB(GL_ARRAY_BUFFER_ARB, 0);
           glPopMatrix()

     glutSwapBuffers()
     return True

[PyOpenGL-Users] darwinplatform -- no VBOs?

[Jackson H. L. <nbs...@lo...>]

It seems like the functions are there --

In [7]: OpenGL.platform.PLATFORM.GL.glGenBuffers
Out[7]: <_FuncPtr object at 0x10580b600>

but pyopengl doesn't see it?

In [8]: bool(OpenGL.GL.glGenBuffers)
Out[8]: False

Is my install broken?  Is this just not supported?  Running OSX
10.6.3, same results on System Python or on macports python.  Pyopengl
installed via easy_install.

Thanks!

Hoy

Re: [PyOpenGL-Users] Accessing Displays and Colors

[Ian M. <geo...@gm...>]

Seems like just a simple glColor call hangs in the main too.

[PyOpenGL-Users] Accessing Displays and Colors

[Ian M. <geo...@gm...>]

Hi,

So, I've made an OpenGL library that lets one do very complicated operations
very easily.  The project, available
here<http://www.pygame.org/project-glLib+Reloaded-1326-.html>,
normally works excellently.

On one of a user's computers, the function
glLib/glLibMisc.py/glLibAlpha(alpha) hangs.

After some deliberation, it was found that only certain functions cause the
problem.  By now, we think that the problem may occur only when OpenGL's
color-related functions are accessed.

These operations in the function cause a hang:
     glGet*(GL_CURRENT_COLOR) #Tries to access the current color
     glColor4f(...) #changes the GL color
     quit()
     sys.exit() #exits, of course
     pygame.quit() #closes the display

These (and related things) don't:
     glGetDoublev(GL_MODELVIEW_MATRIX) #doesn't access any colors
     len('abc') #nothing to do with OpenGL

A proper context has been set up with PyGame.

Any idea what's going on?

Thanks,
Ian

Re: [PyOpenGL-Users] VBO help and performance

[Wakefield, R. <rjw...@en...>]

I'm at a loss as how to fix things, please help if you can.

I just can't figure out how to get glBufferSubData to work with the built-in VBO class from GL.arrays.vbo.  Without the VBO class, I can't get anything to display at all; I guess I'm missing how to do the calls.  

My understanding was that glBindBuffer() would cause subsequent pointer calls (ex. glVertexPointer) to work as an offset from the bound buffer, so offset 0 would be the start of the buffer.  However, using the VBO class, I have to pass it to get the correct offset, e.g.

vbo.bind()
...
glEnableClientState(GL_VERTEX_ARRAY)
glVertexPointer(2, GL_FLOAT, 0, vbo + self.voffset) # would expect '0 + self.voffset' would work, but if I do that, result is that nothing draws, same as above

If I try to use glBufferData, how would I even get a pointer like this?  I don't really understand what's going on behind the scenes well enough to fix it, but I've tried everything I can think of fiddling around with the VBO class and other code samples.

I've attached my actual code, which I've stripped of everything that could possibly interfere.  Before trying to run the code, please note:
1.) I've built the basic GUI on pygame and use numpy arrays for the VBO submission, so you'll need those libs to run
2.) the PNG should be placed in a folder 'gfx', 1 level down from the .py files
3.) the use of IBO or VBO only is controlled by the default parameter to the VBO_dat wrapper class, if useIBO is false, we use VBO only and glDrawArrays.  Without the culling step, it's actually faster than the IBO version due to less glBindBuffer calls (at least on my machine).
4.) the calculation of the visible region works fine, and in fact on large maps (256*256 tiles = 4096*4096 pixels) immediate-mode performance is notably better than non-culling methods.  Still slower than I'd like though.

Many thanks in advance!

Re: [PyOpenGL-Users] VBO help and performance

[Greg E. <gre...@ca...>]

On 07/05/10 13:17, Wakefield, Robert wrote:
>I suspect the issue is that I transfer the data from the CPU either way 
(a screen
> worth of indices).

Don't do that. Transfer all the indices into an IBO once, and use 
glDrawRangeElements to draw the subranges needed to cover the screen.

-- 
Greg

Re: [PyOpenGL-Users] VBO help and performance

[Ian M. <geo...@gm...>]

If your game is 2D, there will be no distortions with a Ortho matrix.  Plus,
you'll be able to use actual screen pixel coordinates, like PyGame, (if you
use that) but it's not flipped.  You can set your characters at z = 0, and
the foreground and background at 1 and -1.

Personally, I don't know how well OpenGL handles very small floats.  My
guess would be a truncation.  In any case, the Z-buffer doesn't have a
resolution fine enough to handle that except under very specific
circumstances (like your near plane is 0.00001 and your far plane is
0.00003.  I don't recommend that.

The essentials of my 2D view class system, for Ortho projections.  You clear
screen, use .set_view(), and draw:
class glLibInternal_glLibView():
    def __init__(self,rect):
        self.rect = list(rect)
        self.x = rect[0]
        self.y = rect[1]
        self.width = rect[2]
        self.height = rect[3]
        self.size = [rect[2],rect[3]]
class glLibView2D(glLibInternal_glLibView):
    def __init__(self,rect):
        glLibInternal_glLibView.__init__(self,rect)
    def set_view(self):
        glViewport(*self.rect)
        glMatrixMode(GL_PROJECTION)
        glLoadIdentity()

gluOrtho2D(self.rect[0],self.rect[0]+self.rect[2],self.rect[1],self.rect[1]+self.rect[3])
        glMatrixMode(GL_MODELVIEW)
        glLoadIdentity()

Ian

Re: [PyOpenGL-Users] VBO help and performance

[Wakefield, R. <rjw...@en...>]

Thanks Ian, that really helps.  Have you ever had any issues with very small float values in pyOpenGL?  I can get a good savings by bunching all backgrounds/foregrounds in 1 render call, but to do that I'll need to put a visually indistinguishable z-distance between the two middle layers (ex. 0.00002), so the player sprite can be placed between them without visual distortions.  I'll try the IBO combined with that and see how it goes.
________________________________________
From: Ian Mallett [geo...@gm...]
Sent: Thursday, May 06, 2010 9:30 PM
To: Wakefield, Robert
Cc: Greg Ewing; pyo...@li...
Subject: Re: [PyOpenGL-Users] VBO help and performance

On Thu, May 6, 2010 at 6:17 PM, Wakefield, Robert <rjw...@en...<mailto:rjw...@en...>> wrote:
The issue I see is that I send much less net data (a few pointers and sizes instead of a full index array), but I'd also need to make ~20 or so calls per frame.
What you'll really want to avoid is binding and unbinding VBOs as much as possible.  For objects with multiple materials, my object class uses separate VBOs.  For objects with around 10 materials, that's quite a few operations.  I'm going to have to convert the VBOs to an interleaved VBO to raise performance.  Long story short, I reiterate: try to minimize VBO binding.
Ian

Re: [PyOpenGL-Users] VBO help and performance

[Ian M. <geo...@gm...>]

On Thu, May 6, 2010 at 6:17 PM, Wakefield, Robert
<rjw...@en...>wrote:

> The issue I see is that I send much less net data (a few pointers and sizes
> instead of a full index array), but I'd also need to make ~20 or so calls
> per frame.
>
What you'll really want to avoid is binding and unbinding VBOs as much as
possible.  For objects with multiple materials, my object class uses
separate VBOs.  For objects with around 10 materials, that's quite a few
operations.  I'm going to have to convert the VBOs to an interleaved VBO to
raise performance.  Long story short, I reiterate: try to minimize VBO
binding.
Ian

Re: [PyOpenGL-Users] VBO help and performance

[Wakefield, R. <rjw...@en...>]

How do you get openGL to cull offscreen triangles?  In performance tests, if I don't cull myself the framerate drops proportionate to mapsize.  

My IBO is already contiguous by row, with (screenheight/tileheight)+1 rows used to cover the screen, the screen IBO.  At each frame I make one call to glDrawElements with the screen IBO or an index array in immediate mode.  Speed is about the same for either, and I suspect the issue is that I transfer the data from the CPU either way (a screen worth of indices).  If I could speed this up a bit I think I'd be okay.  Do you know if glBufferSubData would help?  The issue I see is that I send much less net data (a few pointers and sizes instead of a full index array), but I'd also need to make ~20 or so calls per frame.

I realize these issues would be lessened if I used a larger rectangle for the tile size, but that would be a last resort since it adds a lot of work on the mapping end (each permutation of 4/16/etc small tiles making up a large tile will need to be made into part of the texture atlas).
________________________________________
From: Greg Ewing [gre...@ca...]
Sent: Wednesday, May 05, 2010 7:36 PM
To: Wakefield, Robert
Cc: pyo...@li...
Subject: Re: [PyOpenGL-Users] VBO help and performance

Wakefield, Robert wrote:
> Now that I have a VBO working, I'm wondering what is the best way to speed up culling?

First of all, have you tried just drawing the whole map with one
big glDrawElements call and relying on OpenGL to cull the off-screen
triangles? Unless your map is really enormous, you may find that it's
fast enough.

If not, I'd suggest dividing the map up into rectangles, sized so
that a handful of them cover the screen at any given scrolling
position. Organize your indices so that each rectangle occupies
a contiguous range in the IBO. Then you can make one call for
each rectangle that overlaps the screen.

--
Greg

Re: [PyOpenGL-Users] VBO help and performance

[Ian M. <geo...@gm...>]

If it's a 2D map, you could just render it all to a giant texture and then
draw only one polygon.  If stuff changes, you could update the texture or
just draw another quad with the changes over your main one.

Re: [PyOpenGL-Users] VBO help and performance

[Wakefield, R. <rjw...@en...>]

Now that I have a VBO working, I'm wondering what is the best way to speed up culling?  My specific problem involves a 2D tilemap that is significantly larger than the screen, and the obvious solution is to calculate the indices of the on-screen vertices and use glDrawElements.  I did the index array in immediate mode and there's almost no performance gain, I suspect because of CPU to GPU communication.  To be clear, I have no buffer object for the indices, but the verts/textures are stored in a static VBO for the map.  If I can't get a decent gain by culling to view, tests show that I'm better off using a display list.

The best approach I can think of is to store the geometry data in a VBO like I do now, store the full list of Indices in another buffer object (IBO), and then have a third IBO for the data to be drawn, which will use GL_DYNAMIC_DRAW and have the appropriate memory copied from the full index with glBufferSubData calls, 1 per row of vertices (there are 20-30 rows on screen at once).  Is this a good way to do things, or am I overengineering?  Is there a better way to draw only the triangles appearing on-screen using some other function, perhaps glScissor?

Thanks in advance!

[PyOpenGL-Users] install problems

[horace g. <hor...@gm...>]

hi,

i have problems installing pyopengl on windows.

first i tried:

C:\Python26\Scripts>easy_install.exe PyOpenGL PyOpenGL-accelerate
Searching for PyOpenGL
Reading http://pypi.python.org/simple/PyOpenGL/
Reading http://pyopengl.sourceforge.net
Reading http://sourceforge.net/projects/pyopengl/files/PyOpenGL/
Reading https://sourceforge.net/project/showfiles.php?group_id=5988&package_id=6035
Reading http://pyopengl.sourceforge.net/ctypes/
Reading http://sourceforge.net/project/showfiles.php?group_id=5988
Best match: PyOpenGL 3.0.1
Downloading http://sourceforge.net/projects/pyopengl/files/PyOpenGL/3.0.1/PyOpenGL-3.0.1.win32.exe/download
Processing download
error: Couldn't find a setup script in
c:\docume~1\admini~1\locals~1\temp\easy_install-vm3zlo\download



then i found the installers on the pypi and installed them manually:
PyOpenGL-3.0.1.win32.exe
PyOpenGL-accelerate-3.0.1.win32-py2.6.exe

now if i try to run some of the demos (for example teapot.py) i get:

ERROR: PyOpenGL not installed properly.

if i run it again (from IDLE) it works though. isn't this strange?



some demos (for example nehe) don't run at all. i get this error:

ValueError: numpy.dtype does not appear to be the correct type object

numpy is installed though.



somehow my installation seems to be a bit messed up. :) can anyone
give me some hints how to correct this or tell me what i did wrong?

cheers,
horace

Re: [PyOpenGL-Users] VBO help and performance

[Ian M. <geo...@gm...>]

On Sun, May 2, 2010 at 12:31 AM, Wakefield, Robert
<rjw...@en...>wrote:

> I finally managed to get things working with the VBOs (big thanks to Ian
> Mallett for the tip on the VBO class), but I have one question left.  I
> noticed in the pyOpenGL spec that glVertexPointer (and the others) are
> deprecated and scheduled to be removed in the newer OpenGL versions.

I doubt it.  Do you mean glVertex*f, glNormal*f, etc.?  'Cause those are
scheduled to be deprecated . . . in fact they have in OpenGL 3.  Ditto for
display lists.

> Is the only replacement using a GLSL shader?

Shaders are how the geometry is drawn, not how it is defined.

> If not, what's the other option.
>
Vertex arrays and VBOs will be the only way to draw geometry.

My advice on the whole thing: don't worry about it.  It will be a very long
time before anything is not supported.

> I found a helpful example in the mail archive here:
> http://blog.gmane.org/gmane.comp.python.opengl.user/month=20090801 using
> that (also see vboattrib.py by clicking on '17 comments' for Josh Davis;
> you'll have to rename the bin file to .py), but I'm not really sure how to
> apply this to simple tiling.  What is the quickest way to set vloc/tloc so
> OpenGL know that these are the vertices/textures respectively so the code
> below works?
>
> # main body of drawVBO in the draw loop
>    vbo.bind()
>    glVertexAttribPointer(vloc, 2, GL_FLOAT, False, 0, vbo) # vertex
> location, start of VBO
>    glVertexAttribPointer(tloc, 2, GL_FLOAT, False, 0, vbo + (len(vbo)/2*4))
> #texture location, halfway through VBO
>    glEnableVertexAttribArray(vloc)
>    glEnableVertexAttribArray(tloc)
>    glDrawArrays(GL_TRIANGLES, 0, len(vbo)/2)
>    glDisableVertexAttribArray(vloc)
>    glDisableVertexAttribArray(tloc)
>    vbo.unbind()
>
> For reference, the working code I use with vertex pointers is below.  My
> earlier problem was apparently doing the glBufferData call wrong, and in
> case this helps anyone else the VBO class is a helpful way to outsource the
> job.  By the way, does interleaving data offer a good performance gain over
> a linear VBO (list of verts, then colors, then textures)?
>
Probably.  Might not be too significant right now.  I'd worry about
optimizing it later.  From experience, it's only when you have several
hundred VBOs that you're binding/unbinding that it becomes a problem.

>
> # in the initialization; vbo3 is passed to drawVBO later.
>    dat = verts[:] + textures[:] # a flat list works fine
>    vbo3 = VBO(numpy.asarray(dat, 'f'), GL_STATIC_DRAW, GL_ARRAY_BUFFER)
>
> def drawVBO(texid, vbo):
>    glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT)
>    glBindTexture( GL_TEXTURE_2D, texid)
>
>    vbo.bind()
>    glEnableClientState(GL_VERTEX_ARRAY)
>    glEnableClientState(GL_TEXTURE_COORD_ARRAY)
>    glVertexPointer(2, GL_FLOAT, 0, vbo)
>    glTexCoordPointer(2, GL_FLOAT, 0, vbo + (len(vbo)/2*4)) # the *4
> accounts for sizeof(float)
>    glDrawArrays(GL_TRIANGLES, 0, len(vbo)/2)
>    glDisableClientState(GL_TEXTURE_COORD_ARRAY)
>    glDisableClientState(GL_VERTEX_ARRAY)
>    vbo.unbind()
>
>    glFlush()
>    glFinish()
>    ''' I'm using pygame, so I pygame put it all on the screen; GLUT can do
> the same '''
>    pygame.display.flip()
>
Ian

Re: [PyOpenGL-Users] VBO help and performance

[Wakefield, R. <rjw...@en...>]

I finally managed to get things working with the VBOs (big thanks to Ian Mallett for the tip on the VBO class), but I have one question left.  I noticed in the pyOpenGL spec that glVertexPointer (and the others) are deprecated and scheduled to be removed in the newer OpenGL versions.  Is the only replacement using a GLSL shader?  If not, what's the other option.  

I found a helpful example in the mail archive here: http://blog.gmane.org/gmane.comp.python.opengl.user/month=20090801 using that (also see vboattrib.py by clicking on '17 comments' for Josh Davis; you'll have to rename the bin file to .py), but I'm not really sure how to apply this to simple tiling.  What is the quickest way to set vloc/tloc so OpenGL know that these are the vertices/textures respectively so the code below works?

# main body of drawVBO in the draw loop
    vbo.bind()
    glVertexAttribPointer(vloc, 2, GL_FLOAT, False, 0, vbo) # vertex location, start of VBO
    glVertexAttribPointer(tloc, 2, GL_FLOAT, False, 0, vbo + (len(vbo)/2*4)) #texture location, halfway through VBO
    glEnableVertexAttribArray(vloc)
    glEnableVertexAttribArray(tloc)
    glDrawArrays(GL_TRIANGLES, 0, len(vbo)/2)
    glDisableVertexAttribArray(vloc)
    glDisableVertexAttribArray(tloc)
    vbo.unbind()

For reference, the working code I use with vertex pointers is below.  My earlier problem was apparently doing the glBufferData call wrong, and in case this helps anyone else the VBO class is a helpful way to outsource the job.  By the way, does interleaving data offer a good performance gain over a linear VBO (list of verts, then colors, then textures)?

# in the initialization; vbo3 is passed to drawVBO later.  
    dat = verts[:] + textures[:] # a flat list works fine
    vbo3 = VBO(numpy.asarray(dat, 'f'), GL_STATIC_DRAW, GL_ARRAY_BUFFER)
    
def drawVBO(texid, vbo):
    glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT)
    glBindTexture( GL_TEXTURE_2D, texid)

    vbo.bind()
    glEnableClientState(GL_VERTEX_ARRAY)
    glEnableClientState(GL_TEXTURE_COORD_ARRAY)
    glVertexPointer(2, GL_FLOAT, 0, vbo)
    glTexCoordPointer(2, GL_FLOAT, 0, vbo + (len(vbo)/2*4)) # the *4 accounts for sizeof(float)
    glDrawArrays(GL_TRIANGLES, 0, len(vbo)/2)
    glDisableClientState(GL_TEXTURE_COORD_ARRAY)
    glDisableClientState(GL_VERTEX_ARRAY)
    vbo.unbind()

    glFlush()
    glFinish()
    ''' I'm using pygame, so I pygame put it all on the screen; GLUT can do the same '''
    pygame.display.flip()

Re: [PyOpenGL-Users] VBO help and performance

[Leo H. <leo...@gm...>]

I don't claim to be a PyOpenGL master so YMMV, but when I did something
similar a few years ago, I had to add a call to tostring() to prepare the
array for PyOpenGL.  I was using Numeric at the time, so the relevant code
fragments were:

        self.vertexPositions = Numeric.zeros((size*3,3),Numeric.Float32)
        self._vertexPositionStr = self.vertexPositions.tostring()
        glEnableClientState(GL_VERTEX_ARRAY)
        glVertexPointer(3,GL_FLOAT,0,self._vertexPositionStr)

I haven't actually used this code much in several years though.

Leo



On Sat, May 1, 2010 at 4:08 PM, Wakefield, Robert
<rjw...@en...>wrote:

> Hello,
>
> I've been using PyOpenGL to try to get faster graphics in pygame, and from
> what I've been able to find online VBOs are the best way to optimize in my
> case (2D sprites and tiled backgrounds).  However, for some reason they and
> the vertex arrays they're based on won't work.  In even the simplest
> example, nothing appears, while the corresponding display list or
> glBegin/End call works without a hitch.  Am I missing something, or could
> this be a technical issue?  Any other ideas as to what's wrong?  The code I
> have in the draw test is listed below (I also tried to generate/bind
> buffers, to no effect, but I think the problem is the array):
>
>    # shows nothing; also didn't work with GL_INT and integer types or
> typing in the '.0' for decimal.
>    vertices = numpy.array([0,0,  0,128,  128,128], dtype=numpy.float32)
>    glEnableClientState(GL_VERTEX_ARRAY)
>    glVertexPointer(2, GL_FLOAT, 0, vertices)
>    glDrawArrays(GL_TRIANGLES, 0, 3)
>    glDisableClientState(GL_VERTEX_ARRAY)
>
>    # this, however, works fine.  The data points and mode (GL_TRIANGLES)
> are both identical
>    glBegin(GL_TRIANGLES)
>    glVertex2f(0.0, 0.0)
>    glVertex2f(0.0, 128.0)
>    glVertex2f(128.0, 128.0)
>    glEnd()
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>

[PyOpenGL-Users] VBO help and performance

[Wakefield, R. <rjw...@en...>]

Hello,

I've been using PyOpenGL to try to get faster graphics in pygame, and from what I've been able to find online VBOs are the best way to optimize in my case (2D sprites and tiled backgrounds).  However, for some reason they and the vertex arrays they're based on won't work.  In even the simplest example, nothing appears, while the corresponding display list or glBegin/End call works without a hitch.  Am I missing something, or could this be a technical issue?  Any other ideas as to what's wrong?  The code I have in the draw test is listed below (I also tried to generate/bind buffers, to no effect, but I think the problem is the array):

    # shows nothing; also didn't work with GL_INT and integer types or typing in the '.0' for decimal.
    vertices = numpy.array([0,0,  0,128,  128,128], dtype=numpy.float32)
    glEnableClientState(GL_VERTEX_ARRAY)
    glVertexPointer(2, GL_FLOAT, 0, vertices)
    glDrawArrays(GL_TRIANGLES, 0, 3)
    glDisableClientState(GL_VERTEX_ARRAY)
    
    # this, however, works fine.  The data points and mode (GL_TRIANGLES) are both identical
    glBegin(GL_TRIANGLES)
    glVertex2f(0.0, 0.0)  
    glVertex2f(0.0, 128.0)
    glVertex2f(128.0, 128.0)
    glEnd()

Re: [PyOpenGL-Users] Problem accessing variosu function

[Nicolas R. <Nic...@lo...>]

After an update, the problem seems to be solved but I do not know what
happened in the first place.

Nicolas

On Wed, 2010-04-21 at 22:16 +1200, Greg Ewing wrote:
> > On Tue, 2010-04-20 at 10:46 -0700, Ian Mallett wrote:
> > 
> >>I'm not sure, but as I recall, a proper pygame/OpenGL context also
> >>requires a pygame.DOUBLEBUF flag.
> 
> I was playing with that recently, and if I remember correctly,
> you can use it with or without DOUBLEBUF. But if you're not
> double buffering, you have to remember to call glFlush before
> anything will appear on the screen.
>