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:
3, # each vertex has three ordinates
> ... 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
> 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:
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 "asArray@..."
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:
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:
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 Hartley Made of meat. http://tartley.com
tartley@... +44 7737 062 225 twitter/skype: tartley