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