pyopengl-users — Discussion of all PyOpenGL matters.

Re: [PyOpenGL-Users] constructing a VBO containing mixture of floats, ubytes, etc

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

On Thu, Feb 3, 2011 at 4:49 AM, Jonathan Hartley <ta...@ta...>wrote:

> My problem is that I want to try out converting the colors to unsigned
> bytes instead of floats. When I was using vertex arrays instead of VBOs,
> using unsigned bytes gave me something like 25% better framerates on my
> hardware (2004 era laptop with ATI), purely from increased rendering
> speeds.
>
> Does it sound likely that I'll see this sort of improvement on other
> hardware too? Or should I just stick with using colors as floats
> throughout?
>
Because vertex arrays transfer data across the (fairly slow) graphics bus
each frame, I suspect most, if not all of this performance gain is due to
passing across ~1/4 of the bits for color.

As far as I know, the GPU will convert everything to floating point before
rendering (with the only exception being (possibly?) textures).  For
example, glTranslated(...) is no more accurate than glTranslatef(...),
because the matrix stack is ultimately in floating point (and the values of
the transformation matrix are truncated before being multiplied in
hardware).  I'm fairly sure that when drawing, the rasterizer converts
everything to floating point, including color.

I.e., don't bother.  the speed increase you're getting is due to less data
transfer to the GPU.  With vertex buffer objects, this data transfer
nominally happens exactly once (from your usage, GL_STATIC_DRAW, yes,
exactly once).  If you somehow made an interleaved VBO with different data
types, it sounds like you'd gain perhaps a fraction of a second of loading
time (not counting the extra computation to make it client-side first), but
nothing more.

Ian

Re: [PyOpenGL-Users] constructing a VBO containing mixture of floats, ubytes, etc

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

> If I do go ahead, I'm not certain how to construct the vbo containing 
> mixed types like this. Is there anything in OpenGL.arrays that might 
> help, or do I need to brush up on my ctypes-fu to construct an array of 
> structs manually?



Maybe the script below may help you (it needs numpy).

Nicolas



import sys
import ctypes
import numpy as np
import OpenGL
import OpenGL.GL as gl
import OpenGL.GLU as glu
import OpenGL.GLUT as glut


# -----------------------------------------------------------------------------
class VertexAttribute(object):
    def __init__(self, count, gltype, stride, offset):
        self.count  = count
        self.gltype = gltype
        self.stride = stride
        self.offset = ctypes.c_void_p(offset)

# -----------------------------------------------------------------------------
class VertexAttribute_color(VertexAttribute):
    def __init__(self, count, gltype, stride, offset):
        assert count in (3, 4), \
            'Color attributes must have count of 3 or 4'
        VertexAttribute.__init__(self, count, gltype, stride, offset)
    def enable(self):
        gl.glColorPointer(self.count, self.gltype, self.stride, self.offset)
        gl.glEnableClientState(gl.GL_COLOR_ARRAY)

# -----------------------------------------------------------------------------
class VertexAttribute_edge_flag(VertexAttribute):
    def __init__(self, count, gltype, stride, offset):
        assert count == 1, \
            'Edge flag attribute must have a size of 1'
        assert gltype in (gl.GL_BYTE, gl.GL_UNSIGNED_BYTE, gl.GL_BOOL), \
            'Edge flag attribute must have boolean type'
        VertexAttribute.__init__(self, 1, gltype, stride, offset)
    def enable(self):
        gl.glEdgeFlagPointer(self.stride, self.offset)
        gl.glEnableClientState(gl.GL_EDGE_FLAG_ARRAY)

# -----------------------------------------------------------------------------
class VertexAttribute_fog_coord(VertexAttribute):
    def __init__(self, count, gltype, stride, offset):
        VertexAttribute.__init__(self, count, gltype, stride, offset)
    def enable(self):
        gl.glFogCoordPointer(self.count, self.gltype, self.stride, self.offset)
        gl.glEnableClientState(gl.GL_FOG_COORD_ARRAY)

# -----------------------------------------------------------------------------
class VertexAttribute_normal(VertexAttribute):
    def __init__(self, count, gltype, stride, offset):
        assert count == 3, \
            'Normal attribute must have a size of 3'
        assert gltype in (gl.GL_BYTE, gl.GL_SHORT,
                          gl.GL_INT, gl.GL_FLOAT, gl.GL_DOUBLE), \
                                'Normal attribute must have signed type'
        VertexAttribute.__init__(self, 3, gltype, stride, offset)
    def enable(self):
        gl.glNormalPointer(self.gltype, self.stride, self.offset)
        gl.glEnableClientState(gl.GL_NORMAL_ARRAY)

# -----------------------------------------------------------------------------
class VertexAttribute_secondary_color(VertexAttribute):
    def __init__(self, count, gltype, strude, offset):
        assert count == 3, \
            'Secondary color attribute must have a size of 3'
        VertexAttribute.__init__(self, 3, gltype, stride, offset)
    def enable(self):
        gl.glSecondaryColorPointer(3, self.gltype, self.stride, self.offset)
        gl.glEnableClientState(gl.GL_SECONDARY_COLOR_ARRAY)

# -----------------------------------------------------------------------------
class VertexAttribute_tex_coord(VertexAttribute):
    def __init__(self, count, gltype, stride, offset):
        assert gltype in (gl.GL_SHORT, gl.GL_INT, gl.GL_FLOAT, gl.GL_DOUBLE), \
            'Texture coord attribute must have non-byte signed type'
        VertexAttribute.__init__(self, count, gltype, stride, offset)
    def enable(self):
        gl.glTexCoordPointer(self.count, self.gltype, self.stride, self.offset)
        gl.glEnableClientState(gl.GL_TEXTURE_COORD_ARRAY)

# -----------------------------------------------------------------------------
class VertexAttribute_position(VertexAttribute):
    def __init__(self, count, gltype, stride, offset):
        assert count > 1, \
            'Vertex attribute must have count of 2, 3 or 4'
        assert gltype in (gl.GL_SHORT, gl.GL_INT, gl.GL_FLOAT, gl.GL_DOUBLE), \
            'Vertex attribute must have signed type larger than byte'
        VertexAttribute.__init__(self, count, gltype, stride, offset)
    def enable(self):
        gl.glVertexPointer(self.count, self.gltype, self.stride, self.offset)
        gl.glEnableClientState(gl.GL_VERTEX_ARRAY)

# -----------------------------------------------------------------------------
class VertexBufferException(Exception):
    pass

class VertexBuffer(object):
    def __init__(self, vertices, indices=None):
        gltypes = { 'float32': gl.GL_FLOAT,
                    'float'  : gl.GL_DOUBLE, 'float64': gl.GL_DOUBLE,
                    'int8'   : gl.GL_BYTE,   'uint8'  : gl.GL_UNSIGNED_BYTE,
                    'int16'  : gl.GL_SHORT,  'uint16' : gl.GL_UNSIGNED_SHORT,
                    'int32'  : gl.GL_INT,    'uint32' : gl.GL_UNSIGNED_INT }
        dtype = vertices.dtype
        names = dtype.names or []
        stride = vertices.itemsize
        offset = 0
        self.attributes = {}
        if indices is None:
            indices = np.arange(vertices.size,dtype=np.uint32)
        for name in names:
            gtype = str(dtype[name].subdtype[0])
            count = reduce(lambda x,y:x*y, dtype[name].shape)
            if gtype not in gltypes.keys():
                raise VertexBufferException
            gltype = gltypes[gtype]
            vclass = 'VertexAttribute_%s' % name
            self.attributes[name[0]] = eval(vclass)(count,gltype,stride,offset)
            offset += dtype[name].itemsize

        self.vertices = vertices
        self.vertices_id = gl.glGenBuffers(1)
        gl.glBindBuffer( gl.GL_ARRAY_BUFFER, self.vertices_id )
        gl.glBufferData( gl.GL_ARRAY_BUFFER, self.vertices, gl.GL_STATIC_DRAW )
        gl.glBindBuffer( gl.GL_ARRAY_BUFFER, 0 )

        self.indices = indices
        self.indices_id = gl.glGenBuffers(1)
        gl.glBindBuffer( gl.GL_ELEMENT_ARRAY_BUFFER, self.indices_id )
        gl.glBufferData( gl.GL_ELEMENT_ARRAY_BUFFER, self.indices, gl.GL_STATIC_DRAW )
        gl.glBindBuffer( gl.GL_ELEMENT_ARRAY_BUFFER, 0 )


    def render(self, mode=gl.GL_QUADS, what='pnctesf'):
        gl.glPushClientAttrib( gl.GL_CLIENT_VERTEX_ARRAY_BIT )
        gl.glBindBuffer( gl.GL_ARRAY_BUFFER, self.vertices_id )
        gl.glBindBuffer( gl.GL_ELEMENT_ARRAY_BUFFER, self.indices_id )
        for c in self.attributes.keys():
            if c in what: self.attributes[c].enable()
        gl.glDrawElements( gl.GL_QUADS, self.indices.size, gl.GL_UNSIGNED_INT, None)
        gl.glBindBuffer( gl.GL_ELEMENT_ARRAY_BUFFER, 0 )
        gl.glBindBuffer( gl.GL_ARRAY_BUFFER, 0 )
        gl.glPopClientAttrib( )




# -----------------------------------------------------------------------------
def on_display():
    global cube, theta, phi, frame, time, timebase

    frame += 1
    time = glut.glutGet( glut.GLUT_ELAPSED_TIME )
    if (time - timebase > 1000):
        print frame*1000.0/(time-timebase)
        timebase = time;		
        frame = 0;

    gl.glClear(gl.GL_COLOR_BUFFER_BIT | gl.GL_DEPTH_BUFFER_BIT)

    gl.glPushMatrix()
    gl.glRotatef(theta, 0,0,1)
    gl.glRotatef(phi, 0,1,0)

    gl.glDisable( gl.GL_BLEND )
    gl.glEnable( gl.GL_LIGHTING )
    gl.glEnable( gl.GL_DEPTH_TEST )
    gl.glEnable( gl.GL_POLYGON_OFFSET_FILL )
    gl.glPolygonMode( gl.GL_FRONT_AND_BACK, gl.GL_FILL )
    cube.render( gl.GL_QUADS, 'pnc' )
        
    gl.glDisable( gl.GL_POLYGON_OFFSET_FILL )
    gl.glEnable( gl.GL_BLEND )
    gl.glDisable( gl.GL_LIGHTING )
    gl.glPolygonMode( gl.GL_FRONT_AND_BACK, gl.GL_LINE )
    gl.glDepthMask( gl.GL_FALSE )
    gl.glColor( 0.0, 0.0, 0.0, 0.5 )
    cube.render( gl.GL_QUADS, 'p' )
    gl.glDepthMask( gl.GL_TRUE )
    gl.glPopMatrix()
    glut.glutSwapBuffers()
    
def on_reshape(width, height):
    gl.glViewport(0, 0, width, height)
    gl.glMatrixMode( gl.GL_PROJECTION )
    gl.glLoadIdentity( )
    glu.gluPerspective( 45.0, float(width)/float(height), 2.0, 10.0 )
    gl.glMatrixMode( gl.GL_MODELVIEW )
    gl.glLoadIdentity( )
    gl.glTranslatef( 0.0, 0.0, -5.0 )

def on_keyboard(key, x, y):
    if key == '\033':
        sys.exit()

def on_timer(value):
    global theta, phi
    theta += 0.25
    phi += 0.25
    glut.glutPostRedisplay()
    glut.glutTimerFunc(10, on_timer, 0)

def on_idle():
    global theta, phi
    theta += 0.25
    phi += 0.25
    glut.glutPostRedisplay()


if __name__ == '__main__':
    p = ( ( 1, 1, 1), (-1, 1, 1), (-1,-1, 1), ( 1,-1, 1),
          ( 1,-1,-1), ( 1, 1,-1), (-1, 1,-1), (-1,-1,-1) )
    n = ( ( 0, 0, 1), (1, 0, 0), ( 0, 1, 0),
          (-1, 0, 1), (0,-1, 0), ( 0, 0,-1) );
    c = ( ( 1, 1, 1), ( 1, 1, 0), ( 1, 0, 1), ( 0, 1, 1),
          ( 1, 0, 0), ( 0, 0, 1), ( 0, 1, 0), ( 0, 0, 0) );
    vertices = np.array(
        [ (p[0],n[0],c[0]), (p[1],n[0],c[1]), (p[2],n[0],c[2]), (p[3],n[0],c[3]),
          (p[0],n[1],c[0]), (p[3],n[1],c[3]), (p[4],n[1],c[4]), (p[5],n[1],c[5]),
          (p[0],n[2],c[0]), (p[5],n[2],c[5]), (p[6],n[2],c[6]), (p[1],n[2],c[1]),
          (p[1],n[3],c[1]), (p[6],n[3],c[6]), (p[7],n[3],c[7]), (p[2],n[3],c[2]),
          (p[7],n[4],c[7]), (p[4],n[4],c[4]), (p[3],n[4],c[3]), (p[2],n[4],c[2]),
          (p[4],n[5],c[4]), (p[7],n[5],c[7]), (p[6],n[5],c[6]), (p[5],n[5],c[5]) ], 
        dtype = [('position','f4',(3,)), ('normal','f4',3), ('color','f4',3)] )

    glut.glutInit(sys.argv)
    glut.glutInitDisplayMode(glut.GLUT_DOUBLE | glut.GLUT_RGB | glut.GLUT_DEPTH)
    glut.glutCreateWindow("Python VBO")
    glut.glutReshapeWindow(400, 400)
    glut.glutDisplayFunc(on_display)
    glut.glutReshapeFunc(on_reshape)
    glut.glutKeyboardFunc(on_keyboard)
    glut.glutTimerFunc(10, on_timer, 0)
    #glut.glutIdleFunc(on_idle)

    gl.glPolygonOffset( 1, 1 )
    gl.glClearColor(1,1,1,1);
    gl.glEnable( gl.GL_DEPTH_TEST )
    gl.glEnable( gl.GL_COLOR_MATERIAL )
    gl.glColorMaterial(gl.GL_FRONT_AND_BACK, gl.GL_AMBIENT_AND_DIFFUSE)
    gl.glBlendFunc( gl.GL_SRC_ALPHA, gl.GL_ONE_MINUS_SRC_ALPHA )
    gl.glEnable( gl.GL_LIGHT0 )
    gl.glLight( gl.GL_LIGHT0, gl.GL_DIFFUSE,  (1.0,1.0,1.0,1.0) )
    gl.glLight( gl.GL_LIGHT0, gl.GL_AMBIENT,  (0.1,0.1,0.1,1.0) )
    gl.glLight( gl.GL_LIGHT0, gl.GL_SPECULAR, (0.0,0.0,0.0,1.0) )
    gl.glLight( gl.GL_LIGHT0, gl.GL_POSITION, (0.0,1.0,2.0,1.0) )
    gl.glEnable( gl.GL_LINE_SMOOTH )

    theta, phi = 0, 0
    frame, time, timebase = 0, 0, 0
    cube = VertexBuffer(vertices)
    glut.glutMainLoop()

[PyOpenGL-Users] constructing a VBO containing mixture of floats, ubytes, etc

[Jonathan H. <ta...@ta...>]

Hey,

I am using vbo.VBO, constructed using a single array of (position, 
color, normal) - all floats. This looks like:

         self.vbo = vbo.VBO( array( list(
                     list(chain(v, c, n))
                     for v, c, n in zip(verts, colors, normals)
                 ),
                 'f'
             ),
             usage='GL_STATIC_DRAW'
         )

where verts, colors, normals are each generator expressions containing 
named tuples of (x, y, z) or (r, g, b), etc.

My problem is that I want to try out converting the colors to unsigned 
bytes instead of floats. When I was using vertex arrays instead of VBOs, 
using unsigned bytes gave me something like 25% better framerates on my 
hardware (2004 era laptop with ATI), purely from increased rendering speeds.

Does it sound likely that I'll see this sort of improvement on other 
hardware too? Or should I just stick with using colors as floats throughout?

If I do go ahead, I'm not certain how to construct the vbo containing 
mixed types like this. Is there anything in OpenGL.arrays that might 
help, or do I need to brush up on my ctypes-fu to construct an array of 
structs manually?

I'm happy that I do understand how to assign the vertex attribute 
pointers once the vbo is constructed.

     Jonathan

--
Jonathan Hartley      Made of meat.      http://tartley.com
ta...@ta...   +44 7737 062 225   twitter/skype: tartley

[PyOpenGL-Users] glBeginTransformFeedback missing function

[Stephen H. <sho...@us...>]

I've been trying to get this feature to work for days. There are no examples
on the internet and its not in the documentation. I have checked the opengl
features of my graphics card and it supports this.

I've tried importing multiple modules/various combinations but nothing seems
to work. If you do a search in files of glBeginTransformFeedback you will
see that it exists in the OpenGL 3.0 foldr and the NV extension folder.
However every time I try and use any of these functions they say the
function is not defined. When i do print glBeginTransformFeedback, it prints
an object reference.

Can anyone help or suggest another feature similar? I need to store a list
of vertex data on the shader and the shader needs to spit back out a new
list of vertex data that is to be pipelined back into the shader the next
iteration.

Thanks

Re: [PyOpenGL-Users] NullFunctionError when calling glGenVertexArrays

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

Hi,

I always recommend using the OpenGL.arrays package:

from OpenGL.arrays import vbo
#...
myVbo = vbo.VBO(numpy.array(n_by_3_list,"f"),usage='GL_STATIC_DRAW')
#...
glVertexPointerf(myVbo)

Ian

[PyOpenGL-Users] Freetype python bindings available

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

Hi all,

I've coded python bindings for the freetype library (high-level API only, using ctypes) and made an example to show text rendering using OpenGL.
(http://code.google.com/p/freetype-py/)

Get the sources from:
svn checkout http://freetype-py.googlecode.com/svn/trunk/ freetype-py-read-only

 
Install it and then you can test "opengl.py" from the examples directory.

Nicolas

Re: [PyOpenGL-Users] mixing C++ and python w/ opengl

[Mike C. F. <mcf...@vr...>]

On 11-01-25 06:48 PM, Philip Winston wrote:
...
>
>     > Rather than pull it into Python and then push it
>     > back with pyopengl, it seems like we could just draw it from C,
>     if that
>     > is allowed.
>
>     well, I don't know that I'd do it for this reason -- if you pull/push
>     the data as numpy arrays, you can do all that without data copying, so
>     keeping it in Python may be fine.
>
>
> You might be right.
>
> How do you completely avoid the copy?  I do something really 
> simple/dumb when right now when I need to return an array from C to 
> Python.  I do use numpy, but I do the allocation in Python and then 
> hand the empty array to C to copy the values into.
By default, numpy arrays only copy if they need to have their 
data-format changed.  There's a flag in OpenGL.__init__ which, if set on 
import, will raise errors when that copying occurs.  You can do the same 
by registering an array data-format handler for your C-provided types, 
but Numpy is probably a better/easier option.  Under the covers, 
PyOpenGL is examining the type of the numpy array and, if it is 
compatible, just pulling out the data-pointer from the underlying memory 
area.  Your data-array class could do the same thing, but again, it is 
probably easier to just use Numpy for this kind of work.
>
> I saw some stuff about defining an allocator but it looked complicated.
>
> I wonder if my simplistic approach if the copy would hurt me.  I 
> wonder if I should be using a better no-copy approach instead.
Moving the drawing to C/C++ is certainly supported and easy if you 
already have the C/C++ rendering code.  Avoiding copying is *always* a 
good approach to speeding things up.
> Anyway probably I should start by keeping drawing in Python and 
> if/when I measure a real performance problem consider pushing it to C. 
>  This is how we operate with other stuff, resorting to C only to solve 
> a specific performance issue.
Sounds like a good plan.  Good luck,
Mike

-- 
________________________________________________
   Mike C. Fletcher
   Designer, VR Plumber, Coder
   http://www.vrplumber.com
   http://blog.vrplumber.com

Re: [PyOpenGL-Users] glVertexAttribPointer Problem

[Thomas <p_t...@gm...>]

Thank you very much! Problem solved.
If you look too long at a piece of code ...

On 01/30/2011 08:27 PM, Alejandro Segovia wrote:
> Hello Thomas,
>
> On Jan 30, 2011, at 3:19 PM, Thomas<p_t...@gm...>  wrote:
>
>> Hello,
>>
>> I'm trying to use glVertexAttribPointer and interleaved vertex data.
>>
>> // simple coordinate cross: vertex0, color0, ...
>> data = [0.0, 0.0, 0.0, 1.0, 0.0, 0.0, # x0
>>               1.0, 0.0, 0.0, 1.0, 0.0, 0.0, # x1
>>               0.0, 0.0, 0.0, 0.0, 1.0, 0.0, # y0
>>               0.0, 1.0, 0.0, 0.0, 1.0, 0.0, # y1
>>               0.0, 0.0, 0.0, 0.0, 0.0, 1.0, # z0
>>               0.0, 0.0, 1.0, 0.0, 0.0, 1.0] # z1
>>
>> buffer = glGenBuffers(1)
>> glBindBuffer(GL_ARRAY_BUFFER, buffer)
>> glBufferData(GL_ARRAY_BUFFER, numpy.array(cross, numpy.float32),
>> GL_STATIC_DRAW)
>>
>> # attributes are queried by glGetAttribLocation after shaders are linked
>> glVertexAttribPointer(attributes['coord'], GLint(3), GL_FLOAT, GL_FALSE,
>> GLsizei(6 * 4), ctypes.c_void_p(0))
>> glVertexAttribPointer(attributes['color'], GLint(3), GL_FLOAT, GL_FALSE,
>> GLsizei(6 * 4), ctypes.c_void_p(3))
> I'm not 100% sure, but shouldn't this last call to c_void_p receive 3*4 instead of 3? Please check whether a byte offset is expected here by OpenGL.
>
> Good luck,
> Alejandro.-
>
>> for index in attributes.values():
>>              glEnableVertexAttribArray(index)
>>
>> In my vertex shader I have:
>> attribute vec3 coord;
>> attribute vec3 color;
>>
>> Vertex data is correct, but "vec3 color" is always (0.0, 0.0, 0.0)
>>
>> Is it a problem with pyopengl or did I miss something in my setup?
>>
>> -Thomas
>>
>> ------------------------------------------------------------------------------
>> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
>> Finally, a world-class log management solution at an even better price-free!
>> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
>> February 28th, so secure your free ArcSight Logger TODAY!
>> http://p.sf.net/sfu/arcsight-sfd2d
>> _______________________________________________
>> PyOpenGL Homepage
>> http://pyopengl.sourceforge.net
>> _______________________________________________
>> PyOpenGL-Users mailing list
>> PyO...@li...
>> https://lists.sourceforge.net/lists/listinfo/pyopengl-users

Re: [PyOpenGL-Users] glVertexAttribPointer Problem

[Alejandro S. <as...@gm...>]

Hello Thomas,

On Jan 30, 2011, at 3:19 PM, Thomas <p_t...@gm...> wrote:

> Hello,
> 
> I'm trying to use glVertexAttribPointer and interleaved vertex data.
> 
> // simple coordinate cross: vertex0, color0, ...
> data = [0.0, 0.0, 0.0, 1.0, 0.0, 0.0, # x0
>              1.0, 0.0, 0.0, 1.0, 0.0, 0.0, # x1
>              0.0, 0.0, 0.0, 0.0, 1.0, 0.0, # y0
>              0.0, 1.0, 0.0, 0.0, 1.0, 0.0, # y1
>              0.0, 0.0, 0.0, 0.0, 0.0, 1.0, # z0
>              0.0, 0.0, 1.0, 0.0, 0.0, 1.0] # z1
> 
> buffer = glGenBuffers(1)
> glBindBuffer(GL_ARRAY_BUFFER, buffer)
> glBufferData(GL_ARRAY_BUFFER, numpy.array(cross, numpy.float32), 
> GL_STATIC_DRAW)
> 
> # attributes are queried by glGetAttribLocation after shaders are linked
> glVertexAttribPointer(attributes['coord'], GLint(3), GL_FLOAT, GL_FALSE, 
> GLsizei(6 * 4), ctypes.c_void_p(0))
> glVertexAttribPointer(attributes['color'], GLint(3), GL_FLOAT, GL_FALSE, 
> GLsizei(6 * 4), ctypes.c_void_p(3))

I'm not 100% sure, but shouldn't this last call to c_void_p receive 3*4 instead of 3? Please check whether a byte offset is expected here by OpenGL. 

Good luck,
Alejandro.-

> 
> for index in attributes.values():
>             glEnableVertexAttribArray(index)
> 
> In my vertex shader I have:
> attribute vec3 coord;
> attribute vec3 color;
> 
> Vertex data is correct, but "vec3 color" is always (0.0, 0.0, 0.0)
> 
> Is it a problem with pyopengl or did I miss something in my setup?
> 
> -Thomas
> 
> ------------------------------------------------------------------------------
> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> Finally, a world-class log management solution at an even better price-free!
> Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
> February 28th, so secure your free ArcSight Logger TODAY! 
> http://p.sf.net/sfu/arcsight-sfd2d
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users

[PyOpenGL-Users] glVertexAttribPointer Problem

[Thomas <p_t...@gm...>]

Hello,

I'm trying to use glVertexAttribPointer and interleaved vertex data.

// simple coordinate cross: vertex0, color0, ...
data = [0.0, 0.0, 0.0, 1.0, 0.0, 0.0, # x0
              1.0, 0.0, 0.0, 1.0, 0.0, 0.0, # x1
              0.0, 0.0, 0.0, 0.0, 1.0, 0.0, # y0
              0.0, 1.0, 0.0, 0.0, 1.0, 0.0, # y1
              0.0, 0.0, 0.0, 0.0, 0.0, 1.0, # z0
              0.0, 0.0, 1.0, 0.0, 0.0, 1.0] # z1

buffer = glGenBuffers(1)
glBindBuffer(GL_ARRAY_BUFFER, buffer)
glBufferData(GL_ARRAY_BUFFER, numpy.array(cross, numpy.float32), 
GL_STATIC_DRAW)

# attributes are queried by glGetAttribLocation after shaders are linked
glVertexAttribPointer(attributes['coord'], GLint(3), GL_FLOAT, GL_FALSE, 
GLsizei(6 * 4), ctypes.c_void_p(0))
glVertexAttribPointer(attributes['color'], GLint(3), GL_FLOAT, GL_FALSE, 
GLsizei(6 * 4), ctypes.c_void_p(3))

for index in attributes.values():
             glEnableVertexAttribArray(index)

In my vertex shader I have:
attribute vec3 coord;
attribute vec3 color;

Vertex data is correct, but "vec3 color" is always (0.0, 0.0, 0.0)

Is it a problem with pyopengl or did I miss something in my setup?

-Thomas

Re: [PyOpenGL-Users] mixing C++ and python w/ opengl

[Dirk R. <dir...@gm...>]

	Hi All,

On 01/26/2011 08:40 AM, Alejandro Segovia wrote:
>
> I definitely recommend it. I used Cython to expose the core classes of an
> in-house render engine I was developing in C++ to Python code and I can say it
> was a breeze.
>
> All you have to do is write a simple wrapper around your C/C++ code and a pyx
> file that will compile your wrapper into a shared object. You can then import
> the compiled .so from Python.
>
> Wrapping C++ was a little more complicated than pure C, as objects had to be
> used as opaque types in version 0.12, but now that version 0.13 is out, C++
> support has been vastly improved.
>
> Once you have your Cython module compiled, you can create an OpenGL window/panel
> from Python code and the draw calls in your C/C++ code will automagically work :)

to throw another option in the mix: we've done similar things using 
boost::python. We have a set of core rendering classes that do the slow stuff 
(iterate through long loops and pass the data to OpenGL) and the UI (PyQT) and 
OpenGL setups are done in Python.

Mixing PyOpenGL and C/C++ is no problem at all and works very well. I haven't 
used the C++ interface for Cython, but boost::python is very, very easy to use.

Just my $.02

	Dirk

Re: [PyOpenGL-Users] mixing C++ and python w/ opengl

[Alejandro S. <as...@gm...>]

On Tue, Jan 25, 2011 at 9:48 PM, Philip Winston <pwi...@gm...> wrote:

> You may want to try using Cython, rather than raw C.
>
>
> We've been meaning to investigate Cython.  We use C/C++ libraries and
> ctypes today.  One advantage of C is that other C/C++ programs can use the
> libraries.  But I'm interested in trying Cython just to learn about it.
>

I definitely recommend it. I used Cython to expose the core classes of an
in-house render engine I was developing in C++ to Python code and I can say
it was a breeze.

All you have to do is write a simple wrapper around your C/C++ code and a
pyx file that will compile your wrapper into a shared object. You can then
import the compiled .so from Python.

Wrapping C++ was a little more complicated than pure C, as objects had to be
used as opaque types in version 0.12, but now that version 0.13 is out, C++
support has been vastly improved.

Once you have your Cython module compiled, you can create an OpenGL
window/panel from Python code and the draw calls in your C/C++ code will
automagically work :)

Good luck!
Alejandro.-


>
> ------------------------------------------------------------------------------
> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> Finally, a world-class log management solution at an even better
> price-free!
> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> February 28th, so secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsight-sfd2d
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>
>


-- 
Alejandro Segovia Azapian
Director, Algorithmia: Visualization & Acceleration
http://web.algorithmia.net

Re: [PyOpenGL-Users] mixing C++ and python w/ opengl

[Philip W. <pwi...@gm...>]

>
> You may want to try using Cython, rather than raw C.


We've been meaning to investigate Cython.  We use C/C++ libraries and ctypes
today.  One advantage of C is that other C/C++ programs can use the
libraries.  But I'm interested in trying Cython just to learn about it.

> Rather than pull it into Python and then push it
> > back with pyopengl, it seems like we could just draw it from C, if that
> > is allowed.
>
> well, I don't know that I'd do it for this reason -- if you pull/push
> the data as numpy arrays, you can do all that without data copying, so
> keeping it in Python may be fine.
>

You might be right.

How do you completely avoid the copy?  I do something really simple/dumb
when right now when I need to return an array from C to Python.  I do use
numpy, but I do the allocation in Python and then hand the empty array to C
to copy the values into.

I saw some stuff about defining an allocator but it looked complicated.

I wonder if my simplistic approach if the copy would hurt me.  I wonder if I
should be using a better no-copy approach instead.

Anyway probably I should start by keeping drawing in Python and if/when I
measure a real performance problem consider pushing it to C.  This is how we
operate with other stuff, resorting to C only to solve a specific
performance issue.

-Philip

Re: [PyOpenGL-Users] mixing C++ and python w/ opengl

[Christopher B. <Chr...@no...>]

On 1/25/11 2:22 PM, Philip Winston wrote:
> Is it okay to draw stuff with pyopengl then call into C/C++ with ctypes
> and then draw from there, directly with opengl C API?

yep -- you can do this.

You may want to try using Cython, rather than raw C. Some googling 
should tern up some notes on this. In particular I believe Sturla Molden 
put out a *.pxi file for OPenGL:

http://groups.google.com/group/cython-users/browse_thread/thread/adc1495342da0779

In fact, at least some of PyOpenGL is written with Cython.

> Rather than pull it into Python and then push it
> back with pyopengl, it seems like we could just draw it from C, if that
> is allowed.

well, I don't know that I'd do it for this reason -- if you pull/push 
the data as numpy arrays, you can do all that without data copying, so 
keeping it in Python may be fine.

-Chris


-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

[PyOpenGL-Users] mixing C++ and python w/ opengl

[Philip W. <pwi...@gm...>]

Is it okay to draw stuff with pyopengl then call into C/C++ with ctypes and
then draw from there, directly with opengl C API?  Any gotchas as far as
mixing things up like this?  Does anyone does this, did it work for you?

The reason we are considering this is we have a Python/Tk app.  It draws a
bunch of geometry/textures with pyopengl.  The Python app has a C extension
which contains a bunch of data in C.  Now we want to start drawing this
geometry.  Rather than pull it into Python and then push it back with
pyopengl, it seems like we could just draw it from C, if that is allowed.

Let me know if this seems like a bad idea in general!  Thanks.

-Philip

[PyOpenGL-Users] Recall: Fastest way to draw many spheres

[Kam C. <kc...@co...>]

Kam Chana would like to recall the message, "[PyOpenGL-Users] Fastest way to
draw many spheres".

Re: [PyOpenGL-Users] Fastest way to draw many spheres

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

On Tue, Jan 25, 2011 at 11:04 AM, Mads Ipsen <mad...@gm...> wrote:

> Can you direct me to some pointers for getting started on this type of
> approach. I am pretty new to shaders so it probably has to be pretty simple
> as a starter.
>
Not really.  It's probably too complicated that, if you can't get it from
that description, it's not practical to try to implement.  It's not really a
thing there are tutorials on either.

If you're new to shaders, then I recommend choice A.  It will run a little
bit faster (no texture samplers), and you won't really even need a shader.
If you need more speed after this (you probably will), then implement point
sprites (for good results, you will need a shader, but there are tutorials
on that).

Ian

Re: [PyOpenGL-Users] Fastest way to draw many spheres

[Mads I. <mad...@gm...>]

Ian Mallett wrote:
> On Tue, Jan 25, 2011 at 9:56 AM, Mads Ipsen <mad...@gm... 
> <mailto:mad...@gm...>> wrote:
>
>     Hi,
>
>     We are developing a molecular modeling application which basically
>     boils
>     down to drawing of the order 10000-60000 spheres when viewing the
>     larger
>     system. So far we render spheres by adding a unit gluSphere to a
>     display
>     list and then scaling and positioning this appropriately for each atom
>     in the system.
>
>     I am aware that display lists are old-school. So my questions
>     boils down
>     to this: What is the defacto fastest way of rendering a sphere in a
>     modern OpenGL framework?
>
>     Best regards,
>
>     Mads
>
> There's nothing wrong with display lists.  It's just that they're 
> technically deprecated in future version of OpenGL.  However, because 
> so much code uses display lists, and because it's overall a very good 
> way of doing things, I predict support for them won't drop for at 
> least another decade.  Display lists can also have beer performance 
> than vertex buffer objects (VBOs), which are the current standard.
>
> VBOs are almost as fast as display lists, but also support a number of 
> fun features, especially dynamically changing just *sections* of the 
> data. 
>
> However, what you're doing is suboptimal to begin with.  10,000-60,000 
> spheres is a lot of geometry.  Even if you only had 12 vertices per 
> sphere (icosahedron), that's still around 120,000-720,000 vertices, 
> which is . . . doable, but only just.  Transforming each sphere to the 
> right position will take FAR too long individually (10,000-60,000 
> glTranslate and 10,000-60,000 glScale calls each draw will really eat 
> your framerate). 
>
> As I see it, you have two general solutions:
>
> A) Load a single display list (or VBO) containing ALL the spheres 
> positioned and scaled correctly. 
> B) Store the desired positions and scalars of each atom as single 
> pixels in a texture.  For each sphere, give each of its vertice a 
> vertex attribute corresponding to the sphere's position/scale in the 
> texture.  Draw your 10,000-60,000 spheres in the same place (probably 
> with a DL or VBO), and then a shader will take care of moving them to 
> the correct place and scaling them appropriately, based on the 
> information stored in the texture. 
Can you direct me to some pointers for getting started on this type of 
approach. I am pretty new to shaders so it probably has to be pretty 
simple as a starter.
>
> The second option has the advantage that, by changing the texture, you 
> can move the atoms around--you might even write a shader to do this, 
> and have a full molecular simulation running on the GPU!
>
> Finally, for an extra speed kick, you can use impostors (i.e., point 
> sprites with an image of a sphere on them).  This will cut the number 
> of vertices per sphere to 1, which will VASTLY improve performance.  
> If you write a shader to output depth, and discard fragments outside 
> the sphere, intersection with other objects will work exactly the way 
> it would if the atoms where actual spheres.  Note that doing this 
> procedure is applicable to both A and B. 
>
> Ian


-- 
+--------------------------------------------------------------+
| Mads Ipsen, Scientific developer                             |
+-------------------------------+------------------------------+
| QuantumWise A/S               | phone:          +45-29716388 |
| Nørre Søgade 27A              | www:     www.quantumwise.com |
| DK-1370 Copenhagen K, Denmark | email:  mad...@gm... |
+-------------------------------+------------------------------+

Re: [PyOpenGL-Users] Fastest way to draw many spheres

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

On Tue, Jan 25, 2011 at 9:56 AM, Mads Ipsen <mad...@gm...> wrote:

> Hi,
>
> We are developing a molecular modeling application which basically boils
> down to drawing of the order 10000-60000 spheres when viewing the larger
> system. So far we render spheres by adding a unit gluSphere to a display
> list and then scaling and positioning this appropriately for each atom
> in the system.
>
> I am aware that display lists are old-school. So my questions boils down
> to this: What is the defacto fastest way of rendering a sphere in a
> modern OpenGL framework?
>
> Best regards,
>
> Mads
>
There's nothing wrong with display lists.  It's just that they're
technically deprecated in future version of OpenGL.  However, because so
much code uses display lists, and because it's overall a very good way of
doing things, I predict support for them won't drop for at least another
decade.  Display lists can also have beer performance than vertex buffer
objects (VBOs), which are the current standard.

VBOs are almost as fast as display lists, but also support a number of fun
features, especially dynamically changing just *sections* of the data.

However, what you're doing is suboptimal to begin with.  10,000-60,000
spheres is a lot of geometry.  Even if you only had 12 vertices per sphere
(icosahedron), that's still around 120,000-720,000 vertices, which is . . .
doable, but only just.  Transforming each sphere to the right position will
take FAR too long individually (10,000-60,000 glTranslate and 10,000-60,000
glScale calls each draw will really eat your framerate).

As I see it, you have two general solutions:

A) Load a single display list (or VBO) containing ALL the spheres positioned
and scaled correctly.
B) Store the desired positions and scalars of each atom as single pixels in
a texture.  For each sphere, give each of its vertice a vertex attribute
corresponding to the sphere's position/scale in the texture.  Draw your
10,000-60,000 spheres in the same place (probably with a DL or VBO), and
then a shader will take care of moving them to the correct place and scaling
them appropriately, based on the information stored in the texture.

The second option has the advantage that, by changing the texture, you can
move the atoms around--you might even write a shader to do this, and have a
full molecular simulation running on the GPU!

Finally, for an extra speed kick, you can use impostors (i.e., point sprites
with an image of a sphere on them).  This will cut the number of vertices
per sphere to 1, which will VASTLY improve performance.  If you write a
shader to output depth, and discard fragments outside the sphere,
intersection with other objects will work exactly the way it would if the
atoms where actual spheres.  Note that doing this procedure is applicable to
both A and B.

Ian

[PyOpenGL-Users] Fastest way to draw many spheres

[Mads I. <mad...@gm...>]

Hi,

We are developing a molecular modeling application which basically boils 
down to drawing of the order 10000-60000 spheres when viewing the larger 
system. So far we render spheres by adding a unit gluSphere to a display 
list and then scaling and positioning this appropriately for each atom 
in the system.

I am aware that display lists are old-school. So my questions boils down 
to this: What is the defacto fastest way of rendering a sphere in a 
modern OpenGL framework?

Best regards,

Mads

-- 
+--------------------------------------------------------------+
| Mads Ipsen, Scientific developer                             |
+-------------------------------+------------------------------+
| QuantumWise A/S               | phone:          +45-29716388 |
| Nørre Søgade 27A              | www:     www.quantumwise.com |
| DK-1370 Copenhagen K, Denmark | email:  mad...@gm... |
+-------------------------------+------------------------------+

Re: [PyOpenGL-Users] Pyopengl - slow performance using

[Mike C. F. <mcf...@vr...>]

On 11-01-18 03:31 PM, Christopher Barker wrote:
> On 1/17/11 8:50 PM, Mike C. Fletcher wrote:
>> The most effective speedup I can think of would be to pre-render the
>> static geometry into (mostly transparent) image-maps and then using a
>> single textured quad to present it.  Modern cards handle large image
>> maps pretty well, and a single textured quad should render pretty fast.
> Wow, I"m surprised -- it seems OpenGL should be well suited to this kind
> of thing (that is, simple vector drawing). But I suppose what you're
> talking about is basically double buffering, which is an age-old technique.
>
> However, if you've going to go that route, you might want to pre-render
> much prettier rasters with Mapnik or MapServer, and then use those.
OpenGL is reasonably well suited to this kind of thing, but modern 
graphics cards focus more on textured throughput than pushing huge 
numbers of vertices.  On my GeForce 7600 I get ~90fps for the kind of 
data-set we are talking about (from VBOs with a single call to 
glMultiDrawArrays).  With regular (numpy) arrays that tops out at 
~40fps.  With the Mesa software renderer, 2fps.  Workstation drivers 
will tend to be better at optimizing this kind of thing, but it's still 
a heck of a lot of geometry to push through the pipeline.  A single 
textured quad only generates 6 vertices (though, of course, it generates 
a fragment per pixel)...
>> If you're letting users do a lot of zooming you'll want your zoom-UI to
>> be regenerating the texture according to some heuristic regarding how
>> different the current zoom is from that used to generate the texture.
>> On "release" of the zoom widget you'd regenerate again for the final zoom.
> hmmm... that does let you get the zooming and double buffering, both.
> I"ll need to consider this for some of our stuff, though vector rending
> as been working well for us so far.
Honestly I don't do this kind of stuff myself as my playing tends to be 
focused on "wandering around in 3D", where caching generally works 
better at the pre-computed geometry level.
>> Even with 350,000 vertices, using VBOs for the indices and the vertices
>> should produce an almost-C-speed render.  That is, define a vertex
>> array, an index array that says which vertices to render, and then use a
>> single call to render the whole set.  If your card can pull that much
>> geometry, I'm guessing that should be faster than 50,000 calls to render.
> much, I think -- this approach is working well for us.
Which reminds me, we have a long-standing wart that glMultiDrawElements 
is implemented in Python at the moment... really should revisit that 
issue (pointer type auto-wrapping didn't work very well there).

Have fun,
Mike

-- 
________________________________________________
   Mike C. Fletcher
   Designer, VR Plumber, Coder
   http://www.vrplumber.com
   http://blog.vrplumber.com

Re: [PyOpenGL-Users] Pyopengl - slow performance using

[Christopher B. <Chr...@no...>]

On 1/17/11 8:50 PM, Mike C. Fletcher wrote:
> The most effective speedup I can think of would be to pre-render the
> static geometry into (mostly transparent) image-maps and then using a
> single textured quad to present it.  Modern cards handle large image
> maps pretty well, and a single textured quad should render pretty fast.

Wow, I"m surprised -- it seems OpenGL should be well suited to this kind 
of thing (that is, simple vector drawing). But I suppose what you're 
talking about is basically double buffering, which is an age-old technique.

However, if you've going to go that route, you might want to pre-render 
much prettier rasters with Mapnik or MapServer, and then use those.

> If you're letting users do a lot of zooming you'll want your zoom-UI to
> be regenerating the texture according to some heuristic regarding how
> different the current zoom is from that used to generate the texture.
> On "release" of the zoom widget you'd regenerate again for the final zoom.

hmmm... that does let you get the zooming and double buffering, both. 
I"ll need to consider this for some of our stuff, though vector rending 
as been working well for us so far.

> Even with 350,000 vertices, using VBOs for the indices and the vertices
> should produce an almost-C-speed render.  That is, define a vertex
> array, an index array that says which vertices to render, and then use a
> single call to render the whole set.  If your card can pull that much
> geometry, I'm guessing that should be faster than 50,000 calls to render.

much, I think -- this approach is working well for us.

-Chris



-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

Re: [PyOpenGL-Users] Pyopengl - slow performance using

[Christopher B. <Chr...@no...>]

On 1/17/11 2:24 PM, Jonathan Hartley wrote:
> Personally I use ctypes arrays instead of numpy arrays.
 > But for what it's worth, the ctypes code is quite
> simple. From memory, assuming 3D vertices:
>
>       from OpenGL import GL as gl
>
>       # prepare the arrays once at application start-up or model load:
>
>       verts = [ (1.0, 2.0, 3.0), (4.0, 5.0, 6.0)... ]
>       length = len(verts) * 3 # each vertex has three ordinates, (x, y, z)
>       arraytype = gl.GLfloat * length
>       glverts = arraytype(*verts)

sure but compare that to:

        verts = [ (1.0, 2.0, 3.0), (4.0, 5.0, 6.0)... ]
        glverts = np.array(verts, dtype=np.float32)

but if you're not using numpy for anything else, ctypes arrays are a 
fine option.

> If anyone anyone else's response contradicts the above, they are almost
> certainly more correct. :-)

Maybe, but that was really helpful info and pointers, thanks!

-Chris



-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

Re: [PyOpenGL-Users] Pyopengl - slow performance using

[Mike C. F. <mcf...@vr...>]

On 11-01-13 06:29 AM, pm...@gm... wrote:
...
> - Do you have any hints how to improve the performance dramatically and make it usable? I tried several options but none worked out. For instance I tried to replace python list with numpy arrays but the performance was not significantly changed.
The most effective speedup I can think of would be to pre-render the
static geometry into (mostly transparent) image-maps and then using a
single textured quad to present it.  Modern cards handle large image
maps pretty well, and a single textured quad should render pretty fast. 
If you're letting users do a lot of zooming you'll want your zoom-UI to
be regenerating the texture according to some heuristic regarding how
different the current zoom is from that used to generate the texture. 
On "release" of the zoom widget you'd regenerate again for the final zoom.
> - Do I need execute the OpenGL code in C? Altough I could do this, I still need to use python as scripting language due to other dependencies of the implementation.
Even with 350,000 vertices, using VBOs for the indices and the vertices
should produce an almost-C-speed render.  That is, define a vertex
array, an index array that says which vertices to render, and then use a
single call to render the whole set.  If your card can pull that much
geometry, I'm guessing that should be faster than 50,000 calls to render.

HTH,
Mike

-- 
________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://www.vrplumber.com
  http://blog.vrplumber.com

Re: [PyOpenGL-Users] Pyopengl - slow performance using

[Jonathan H. <ta...@ta...>]

I sent this a few days ago, but don't see it in my news feed of the 
group. Apologies if anyone else has seen it twice.


On 14/01/2011 20:22, Pedro Miranda wrote:
 > 1) Numpy arrays
 > ---------------

Personally I use ctypes arrays instead of numpy arrays. Numpy may be a 
better option, because then you have the option to use the fancy numpy 
operators on the data. But for what it's worth, the ctypes code is quite 
simple. From memory, assuming 3D vertices:

     from OpenGL import GL as gl

     # prepare the arrays once at application start-up or model load:

     verts = [ (1.0, 2.0, 3.0), (4.0, 5.0, 6.0)... ]
     length = len(verts) * 3 # each vertex has three ordinates, (x, y, z)
     arraytype = gl.GLfloat * length
     glverts = arraytype(*verts)

     # then later in your render loop:

     gl.glVertexPointer(
         3, # each vertex has three ordinates
         gl.GL_FLOAT,
         0,
         glverts
     )


 > ... But is someone sure that the proposed strategy to use NaN to
 > separate different road segments is viable?

I have never personally used NaN in my vertex array, so can't speak 
directly about that, but I have done very similar things using 
'primitive restarts', which seem to be the same idea but for indexed 
vertex arrays. Indexed vertex arrays may be a good idea in any case, 
once you have fixed whatever your current performance problem is. If you 
fancy primitive restarts, see glEnable(GL_PRIMITIVE_RESTART) and 
glPrimitiveRestartIndex(), plus the detailed description in the OpenGL 
SuperBible, under 'Advanced Geometry Management / Drawing a lot of 
Geometry Efficiently / Combining Geometry Using Primitive Restart' (p494 
of the fifth edition.)

Alternatively, and possibly simpler, you may be able to achieve the same 
thing as primitive restart or NaN vertices, by using glMultiDrawArrays 
or similar. Again, this would require converting to use indexed arrays, 
but it will allow you to draw many primitives using a single call. 
SuperBible says that for some drivers this sacrifices a smidge of 
performance, since internally it is literally converted into a series of 
glDrawArrays calls, but I'd guess that should be a small problem 
compared to the performance issues of calling from Python in the first 
place.


 > Is there any upper limit to maximum number of vertices a vertex array
 > can contain?

Experimenting with my own code right now (which is rubbish on almost all 
axes) with a single vertex array full of GL_TRIANGLES, I get:

triangles   fps
   168,000    60
1,440,000     5
3,840,000     memory error

This is on a modest pre-2005 era laptop, with color and normal arrays as 
well as vertex arrays. The memory error is in my own code at application 
start-up, creating intermediate lists before creating the vertex arrays 
- presumably the vertex arrays could be larger if my start-up code 
wasn't so lame.

Regarding the performance of the above, my scene isn't culled in any 
way, and my triangles are fairly large, so I have tremendous overdraw in 
my scene, and am therefore fill-rate limited  - presumably this will be 
less of an issue for you since roads are thin and 2D data doesn't have 
so much overdraw.


 > c) profiling
 > ------------
 >  the majority of the time (almost 11 seconds or 60% of the time) was
 > spent in function "as...@li..."

You don't explicitly say whether this fixes your performance problem, or 
just gives you some good info. Are you still at 20 seconds per frame? In 
particular, I don't think you should need to be calling asArray at all 
after models are loaded. Have I misunderstood?


 > Do someone know any good tutorial to use VBO in dynamic scenarios?

One tutorial idea is the shaders tutorial in the PyOpenGL documentation. 
This starts out by explaining and setting up VBOs:
http://pyopengl.sourceforge.net/context/tutorials/index.xhtml

However, it uses the PyOpenGL VBO class, which handles all the low-level 
work for you. If you want to know what's going on under the covers, see 
the source of class VBO class, somewhere in the middle of:
http://bazaar.launchpad.net/~mcfletch/pyopengl/trunk/view/head:/OpenGL/arrays/vbo.py
So then you could continue using PyOpenGL.VBO class in your own code, or 
you could write your own equivalent if you didn't want the dependency on 
all of PyOpenGL.


If anyone anyone else's response contradicts the above, they are almost 
certainly more correct. :-)

     Jonathan

-- 
Jonathan Hartley      Made of meat.      http://tartley.com
ta...@ta...   +44 7737 062 225   twitter/skype: tartley