pyopengl-users — Discussion of all PyOpenGL matters.

Re: [PyOpenGL-Users] shader errors

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

Hi,

You'll probably want:

#Might work.  If not, I can give you ctypes code that should
print glGetShaderInfoLog(VertexShader)
print glGetShaderInfoLog(FragmentShader)

#Will work
glGetInfoLogARB(program)

Ian

[PyOpenGL-Users] shader errors

[Michael L. <mic...@gm...>]

Hi! i have some very strange behaviour with my shader.
the code i took here:
http://www.geeks3d.com/20091013/shader-library-phong-shader-with-multiple-
lights-glsl/

[CODE]
program = compileProgram(
        ['''
varying vec3 normal, eyeVec;
#define MAX_LIGHTS 8
varying vec3 lightDir[MAX_LIGHTS];
varying vec2 texture_coordinate;
uniform int numLights;
void main()
{
  gl_Position = ftransform();
  normal = gl_NormalMatrix * gl_Normal;
  vec4 vVertex = gl_ModelViewMatrix * gl_Vertex;
  eyeVec = -vVertex.xyz;
  int i;
  texture_coordinate = vec2(gl_MultiTexCoord0);
  for (i=0; i<numLights; ++i)
    lightDir[i] = vec3(gl_LightSource[i].position.xyz - vVertex.xyz);
}
        ''',],
        ['''
varying vec3 normal, eyeVec;
#define MAX_LIGHTS 8
varying vec3 lightDir[MAX_LIGHTS];
varying vec2 texture_coordinate;
uniform sampler2D my_color_texture;
uniform int numLights;
void main (void)
{
  vec4 final_color = gl_FrontLightModelProduct.sceneColor;
  vec4 texel = texture2D(my_color_texture, texture_coordinate);
  vec3 N = normalize(normal);
  int i;
  for (i=0; i<numLights; ++i)
  {
    vec3 L = normalize(lightDir[i]);
    float lambertTerm = dot(N,L);
    if (lambertTerm > 0.0)
    {
      final_color +=
        gl_LightSource[i].diffuse *
        gl_FrontMaterial.diffuse *
        lambertTerm;
      vec3 E = normalize(eyeVec);
      vec3 R = reflect(-L, N);
      float specular = pow(max(dot(R, E), 0.0),
                           gl_FrontMaterial.shininess);
      final_color +=
        gl_LightSource[i].specular *
        gl_FrontMaterial.specular *
        specular;
    }
  }
  gl_FragColor = final_color*texel;
}
        ''',])

#after this ->
if program:
                glUseProgramObjectARB(program)
                num_lights = glGetUniformLocationARB(program, "numLights")
                glUniform1iARB(num_lights, 4)
[/CODE]
######################################################

it's ok at work but at home it crashes (win x64, geforce 7600 GT). Other shaders 
work fine - i found that it crashes somewhere near for-loop
for (i=0; i<numLights; ++i)
    lightDir[i] = vec3(gl_LightSource[i].position.xyz - vVertex.xyz);
The main question is can i somehow debug shader and print some log what's going 
on?
and how it can be that everything is ok at one machine and invalidOperation at 
other?..
thank you!

Re: [PyOpenGL-Users] Missing VBO function

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

It makes perfectly sens.

Thank you,


Roland.

Le 07/18/10 22:10, Gijs a écrit :
> There certainly won't be any memory leak or corruption. This is the 
> default operation of most, if not all, commands of OpenGL. OpenGL 
> works like a big giant state-machine. You set something, and it'll 
> stay set until you change it or you pop/push states/settings. In your 
> case, a VBO buffer can be bound so that it is made active, and then 
> the commands that use VBO's will use the binded VBO buffer you've set 
> before. If you never unset it, then OpenGL will simply assume that you 
> still want the VBO buffer to be active.
>
> An easier to understand example is when you want to draw a green 
> triangle for instance. If you need to draw a green triangle, and never 
> have to draw a different color, then you can simply set the color to 
> be green before the drawing function. Then call the drawing function, 
> and the color will remain green throughout the entire drawing 
> function. You can call the drawing function again and again, without 
> ever having to set the color to be green. (well, unless you are 
> popping and pushing states which erases states/settings you've set 
> before).
>
> If you understand this concept, you can make quite efficient code, 
> since you know you don't have to call certain functions again and 
> again, simply because they don't (have to) change. And OpenGL usually 
> doesn't change settings for you. There's only one exception to this 
> afaik. When you make an FBO active, it replaces the current settings 
> with the settings of the FBO you made active. Not all of your 
> settings, but the ones that have to do with the colorbuffer and 
> viewport. If you're not sure what settings are set at a certain point 
> in your code, you can get the settings with functions like 
> glGetBooleanv, glGetDoublev, glGetFloatv, glGetIntegerv.
>
> Hope this helps and makes some sense :)
> Kind regards,
> Gijs
>    
>
> On 18-7-2010 19:16, Roland Everaert wrote:
>> Thanks after a few try and error I was able to convert my code to use 
>> that class.
>>
>> I have anyway a question regarding VBO usage in general.
>>
>> What is the effect of not unbinding a VBO buffer after drawing and 
>> calling the drawing process again and again?
>>
>> memory leak?
>>
>> memory corruption?
>>
>> nothing?
>>
>>
>> Thanks,
>>
>>
>> Roland.
>>
>>
>> Le 07/16/10 20:48, Ian Mallett a écrit :
>>> That /was/ a complete example of how to use the functions :-)
>>>
>>> Here, I've added enough surrounding code to be self-explanatory.
>>>
>>> #Import it:
>>> from OpenGL.arrays import vbo
>>> import numpy as np
>>> ...
>>> #Create a vertex buffer object
>>> vertices = [  [0,0,0],[0,1,0],[1,0,0],  [2,0,0],[0,3,0],[4,9,6],  
>>> [7,8,1],...]
>>> vertex_buffer_object = 
>>> vbo.VBO(np.array(vertices,"f"),usage='GL_STATIC_DRAW')
>>> ...
>>> #Draw VBO
>>> glEnableClientState(GL_VERTEX_ARRAY); 
>>> glVertexPointerf(vertex_buffer_object)
>>> glDrawArrays(GL_TRIANGLES,0,len(vertices)/3)
>>> glDisableClientState(GL_VERTEX_ARRAY);
>>> glBindBuffer(GL_ARRAY_BUFFER,0)
>>>
>>> Normal, and texture VBOs work very similarly.  Vertex attribute VBOs 
>>> require you to specify a shader, but you'll only need those for 
>>> things like normal mapping, etc.
>>>
>>> If you need more explanation, try: 
>>> http://pyopengl.sourceforge.net/context/tutorials/shader_1.xhtml, or 
>>> Google: "from OpenGL.arrays import vbo".  My implementation is here: 
>>> http://www.pygame.org/project-glLib+Reloaded-1326-.html, in 
>>> glLib/glLibObjects.py (class glLibObject) but it's probably too 
>>> convoluted for a tutorial.
>>>
>>> Ian
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by Sprint
>> What will you do first with EVO, the first 4G phone?
>> Visit sprint.com/first --http://p.sf.net/sfu/sprint-com-first
>>
>>
>> _______________________________________________
>> PyOpenGL Homepage
>> http://pyopengl.sourceforge.net
>> _______________________________________________
>> PyOpenGL-Users mailing list
>> PyO...@li...
>> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>>    

Re: [PyOpenGL-Users] Missing VBO function

[Gijs <in...@bs...>]

There certainly won't be any memory leak or corruption. This is the 
default operation of most, if not all, commands of OpenGL. OpenGL works 
like a big giant state-machine. You set something, and it'll stay set 
until you change it or you pop/push states/settings. In your case, a VBO 
buffer can be bound so that it is made active, and then the commands 
that use VBO's will use the binded VBO buffer you've set before. If you 
never unset it, then OpenGL will simply assume that you still want the 
VBO buffer to be active.

An easier to understand example is when you want to draw a green 
triangle for instance. If you need to draw a green triangle, and never 
have to draw a different color, then you can simply set the color to be 
green before the drawing function. Then call the drawing function, and 
the color will remain green throughout the entire drawing function. You 
can call the drawing function again and again, without ever having to 
set the color to be green. (well, unless you are popping and pushing 
states which erases states/settings you've set before).

If you understand this concept, you can make quite efficient code, since 
you know you don't have to call certain functions again and again, 
simply because they don't (have to) change. And OpenGL usually doesn't 
change settings for you. There's only one exception to this afaik. When 
you make an FBO active, it replaces the current settings with the 
settings of the FBO you made active. Not all of your settings, but the 
ones that have to do with the colorbuffer and viewport. If you're not 
sure what settings are set at a certain point in your code, you can get 
the settings with functions like glGetBooleanv, glGetDoublev, 
glGetFloatv, glGetIntegerv.

Hope this helps and makes some sense :)

Kind regards,
Gijs


On 18-7-2010 19:16, Roland Everaert wrote:
> Thanks after a few try and error I was able to convert my code to use 
> that class.
>
> I have anyway a question regarding VBO usage in general.
>
> What is the effect of not unbinding a VBO buffer after drawing and 
> calling the drawing process again and again?
>
> memory leak?
>
> memory corruption?
>
> nothing?
>
>
> Thanks,
>
>
> Roland.
>
>
> Le 07/16/10 20:48, Ian Mallett a écrit :
>> That /was/ a complete example of how to use the functions :-)
>>
>> Here, I've added enough surrounding code to be self-explanatory.
>>
>> #Import it:
>> from OpenGL.arrays import vbo
>> import numpy as np
>> ...
>> #Create a vertex buffer object
>> vertices = [  [0,0,0],[0,1,0],[1,0,0],  [2,0,0],[0,3,0],[4,9,6],  
>> [7,8,1],...]
>> vertex_buffer_object = 
>> vbo.VBO(np.array(vertices,"f"),usage='GL_STATIC_DRAW')
>> ...
>> #Draw VBO
>> glEnableClientState(GL_VERTEX_ARRAY); 
>> glVertexPointerf(vertex_buffer_object)
>> glDrawArrays(GL_TRIANGLES,0,len(vertices)/3)
>> glDisableClientState(GL_VERTEX_ARRAY);
>> glBindBuffer(GL_ARRAY_BUFFER,0)
>>
>> Normal, and texture VBOs work very similarly.  Vertex attribute VBOs 
>> require you to specify a shader, but you'll only need those for 
>> things like normal mapping, etc.
>>
>> If you need more explanation, try: 
>> http://pyopengl.sourceforge.net/context/tutorials/shader_1.xhtml, or 
>> Google: "from OpenGL.arrays import vbo".  My implementation is here: 
>> http://www.pygame.org/project-glLib+Reloaded-1326-.html, in 
>> glLib/glLibObjects.py (class glLibObject) but it's probably too 
>> convoluted for a tutorial.
>>
>> Ian
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
>
>
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>    

Re: [PyOpenGL-Users] Missing VBO function

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

Hi,

As long as the only thing you're doing is VBO and array drawing, I
*think*it should be all right.  If you do anything else, it might not
work
properly.  Best practice is just to include it.

Ian

Re: [PyOpenGL-Users] Missing VBO function

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

Thanks after a few try and error I was able to convert my code to use 
that class.

I have anyway a question regarding VBO usage in general.

What is the effect of not unbinding a VBO buffer after drawing and 
calling the drawing process again and again?

memory leak?

memory corruption?

nothing?


Thanks,


Roland.


Le 07/16/10 20:48, Ian Mallett a écrit :
> That /was/ a complete example of how to use the functions :-)
>
> Here, I've added enough surrounding code to be self-explanatory.
>
> #Import it:
> from OpenGL.arrays import vbo
> import numpy as np
> ...
> #Create a vertex buffer object
> vertices = [  [0,0,0],[0,1,0],[1,0,0],  [2,0,0],[0,3,0],[4,9,6],  
> [7,8,1],...]
> vertex_buffer_object = 
> vbo.VBO(np.array(vertices,"f"),usage='GL_STATIC_DRAW')
> ...
> #Draw VBO
> glEnableClientState(GL_VERTEX_ARRAY); 
> glVertexPointerf(vertex_buffer_object)
> glDrawArrays(GL_TRIANGLES,0,len(vertices)/3)
> glDisableClientState(GL_VERTEX_ARRAY);
> glBindBuffer(GL_ARRAY_BUFFER,0)
>
> Normal, and texture VBOs work very similarly.  Vertex attribute VBOs 
> require you to specify a shader, but you'll only need those for things 
> like normal mapping, etc.
>
> If you need more explanation, try: 
> http://pyopengl.sourceforge.net/context/tutorials/shader_1.xhtml, or 
> Google: "from OpenGL.arrays import vbo".  My implementation is here: 
> http://www.pygame.org/project-glLib+Reloaded-1326-.html, in 
> glLib/glLibObjects.py (class glLibObject) but it's probably too 
> convoluted for a tutorial.
>
> Ian

Re: [PyOpenGL-Users] Missing VBO function

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

That *was* a complete example of how to use the functions :-)

Here, I've added enough surrounding code to be self-explanatory.

#Import it:
from OpenGL.arrays import vbo
import numpy as np
...
#Create a vertex buffer object
vertices = [  [0,0,0],[0,1,0],[1,0,0],  [2,0,0],[0,3,0],[4,9,6],
[7,8,1],...]
vertex_buffer_object =
vbo.VBO(np.array(vertices,"f"),usage='GL_STATIC_DRAW')
...
#Draw VBO
glEnableClientState(GL_VERTEX_ARRAY); glVertexPointerf(vertex_buffer_object)
glDrawArrays(GL_TRIANGLES,0,len(vertices)/3)
glDisableClientState(GL_VERTEX_ARRAY);
glBindBuffer(GL_ARRAY_BUFFER,0)

Normal, and texture VBOs work very similarly.  Vertex attribute VBOs require
you to specify a shader, but you'll only need those for things like normal
mapping, etc.

If you need more explanation, try:
http://pyopengl.sourceforge.net/context/tutorials/shader_1.xhtml, or Google:
"from OpenGL.arrays import vbo".  My implementation is here:
http://www.pygame.org/project-glLib+Reloaded-1326-.html, in
glLib/glLibObjects.py (class glLibObject) but it's probably too convoluted
for a tutorial.

Ian

Re: [PyOpenGL-Users] Missing VBO function

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

Ok, but is there any documentation about it, I was not able to found one 
on the pyopengl web site and I do not find a lot of complete example of 
its usage :(

Roland.

Le 07/15/10 22:37, Ian Mallett a écrit :
> Hi,
>
> Again, I recommend the array class for VBOs.  It handles everything 
> for you and is exceedingly easy to use.
>
> from OpenGL.arrays import vbo
> ...
> vertex_buffer_object = 
> vbo.VBO(np.array(vertices,"f"),usage='GL_STATIC_DRAW')
> ...
> glVertexPointerf(vertex_buffer_object)
>
> Ian

Re: [PyOpenGL-Users] Missing VBO function

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

Hi,

Again, I recommend the array class for VBOs.  It handles everything for you
and is exceedingly easy to use.

from OpenGL.arrays import vbo
...
vertex_buffer_object =
vbo.VBO(np.array(vertices,"f"),usage='GL_STATIC_DRAW')
...
glVertexPointerf(vertex_buffer_object)

Ian

Re: [PyOpenGL-Users] Missing VBO function

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

I am also using glGenBuffers and stuff, but glGenVertexArray and co. are 
supposed to allow to save the states of the vertex so I have not to call 
glVertexPointer and other vertex array related function for every frame.

Another thing, with glBindBuffer(), if I use a constant like the one 
defined in the documentation, python doesn't know it, I have to postfix 
them with _ARB?

Below is an example:

glBindBuffer(GL_ARRAY_BUFFER_ARB, self.buffers[0])

Could it be that with my hardware this is an extension?


Regards,


Roland.

Le 07/15/10 17:56, Alejandro Segovia a écrit :
> Hi Roland,
>
> I don't know precisely about those specific 3.0 functions, but in my 
> code I'm using glGenBuffers, glBindBuffer and glBufferData to populate 
> my VBO's (PyOpenGL version 3.0.1b). I think these are core in OpenGL 2.0.
>
> Alejandro.-
>
> On Thu, Jul 15, 2010 at 10:37 AM, Roland Everaert 
> <r.e...@gm... <mailto:r.e...@gm...>> wrote:
>
>     Hi,
>
>
>     I am currently trying to use VBOs, but it seems that pyOpenGL 3.0.1 is
>     lacking the functions glGenVertexArrays(), glBindVertexArray() and I
>     suppose glDeleteVertexArray().
>
>     Below is the error I get:
>
>     NameError: global name 'glGenVertexArrays' is not defined
>
>
>     According to the OpenGL Programming Guide (the red book) seventh
>     edition
>     and some document I found on the official site of OpenGL, those
>     functions exists since OpenGL 3.0.
>
>     The basic question is, does pyOpenGL 3.0.1 belongs to OpenGL 3.0
>     or not?
>
>     If yes, could it be related to the implementation for my platform
>     or my
>     graphics hardware?
>
>     If not, to which version of OpenGL does pyOpenGL 3.0.1 belongs?
>
>
>     Regards,
>
>
>     Roland.
>
>     ------------------------------------------------------------------------------
>     This SF.net email is sponsored by Sprint
>     What will you do first with EVO, the first 4G phone?
>     Visit sprint.com/first <http://sprint.com/first> --
>     http://p.sf.net/sfu/sprint-com-first
>     _______________________________________________
>     PyOpenGL Homepage
>     http://pyopengl.sourceforge.net
>     _______________________________________________
>     PyOpenGL-Users mailing list
>     PyO...@li...
>     <mailto:PyO...@li...>
>     https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>
>
>
>
> -- 
> Alejandro Segovia Azapian
> Director, Algorithmia: Visualization & Acceleration
> http://web.algorithmia.net

Re: [PyOpenGL-Users] Missing VBO function

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

Hi Roland,

I don't know precisely about those specific 3.0 functions, but in my code
I'm using glGenBuffers, glBindBuffer and glBufferData to populate my VBO's
(PyOpenGL version 3.0.1b). I think these are core in OpenGL 2.0.

Alejandro.-

On Thu, Jul 15, 2010 at 10:37 AM, Roland Everaert <r.e...@gm...>wrote:

> Hi,
>
>
> I am currently trying to use VBOs, but it seems that pyOpenGL 3.0.1 is
> lacking the functions glGenVertexArrays(), glBindVertexArray() and I
> suppose glDeleteVertexArray().
>
> Below is the error I get:
>
> NameError: global name 'glGenVertexArrays' is not defined
>
>
> According to the OpenGL Programming Guide (the red book) seventh edition
> and some document I found on the official site of OpenGL, those
> functions exists since OpenGL 3.0.
>
> The basic question is, does pyOpenGL 3.0.1 belongs to OpenGL 3.0 or not?
>
> If yes, could it be related to the implementation for my platform or my
> graphics hardware?
>
> If not, to which version of OpenGL does pyOpenGL 3.0.1 belongs?
>
>
> Regards,
>
>
> Roland.
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> 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

[PyOpenGL-Users] Missing VBO function

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

Hi,


I am currently trying to use VBOs, but it seems that pyOpenGL 3.0.1 is 
lacking the functions glGenVertexArrays(), glBindVertexArray() and I 
suppose glDeleteVertexArray().

Below is the error I get:

NameError: global name 'glGenVertexArrays' is not defined


According to the OpenGL Programming Guide (the red book) seventh edition 
and some document I found on the official site of OpenGL, those 
functions exists since OpenGL 3.0.

The basic question is, does pyOpenGL 3.0.1 belongs to OpenGL 3.0 or not?

If yes, could it be related to the implementation for my platform or my 
graphics hardware?

If not, to which version of OpenGL does pyOpenGL 3.0.1 belongs?


Regards,


Roland.

Re: [PyOpenGL-Users] size limit of vertex array?

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

Hi,

Your problem is that vertex arrays are, by nature, slow.

Imagine trying to specify your plane via glVertex3f and glNormal3f calls.
If you're familiar with these, you know that they're fairly slow.  This is
because ALL of the geometry and normal data for the entire object must be
passed over the graphics bus to the graphics card each frame.  Not speedy.

Vertex arrays act similarly.  The gl_____Pointer commands, when used like
this, pass all the data over the graphics bus.  Again, = slow.

Two solutions: display lists or VBOs.  VBOs are newer, and therefore are
recommended.  They're also more complicated.  I recommend PyOpenGL's
built-in VBO class, available with "from OpenGL.arrays import vbo".  Display
lists are notably simpler, but they're technically deprecated (though I
predict they won't be removed for at least another 15 years) and not as
flexible (most notably, they can't be dynamically updated).  Google should
provide you with implementation specific for each.

Ian

Re: [PyOpenGL-Users] size limit of vertex array?

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

Concenring the high CPU usage after some thought and a test, it is 
mainly due to the while loop in which the OpenGL code run.


Roland.

Le 07/14/10 14:19, Roland Everaert a écrit :
> Hi,
>
> Its me again still playing with vertex array.
>
> Using the code showed previously, I have tried to display a plane of 
> 60 rows and 44 columns. With lighting disabled, no material properties 
> defined and no normals provided, the rendering of such plane is 
> performed at 10 FPS.
>
> In addition, one of the core of the CPU is used at 100% by python what 
> ever the size of the plane or the number of "objects" rendered.
>
> Is it normal that python uses so much CPU?
>
> Does 60 * 44 * 4, hence, 10560 vertices such big for an interactive 
> application or should I use other techniques (VBO maybe) to render 
> such amount of vertices or less vertices for such object? (I know that 
> it depends, mainly, on what I want to do with the plane)
>
> When using glGetString() to get information on the hardware here are 
> the information I got:
>
> NVIDIA Corporation
> GeForce 8800 GTX/PCI/SSE2
> 3.2.0 NVIDIA 190.42
>
> So it seems that the program is using the graphics card at some point.
>
> The CPU of the machine is an AMD 64 X2 DualCore 5200+.
>
>
>
> Thanks for any advise,
>
>
> Roland
>
>
>
> Le 07/14/10 11:49, Roland Everaert a écrit :
>> Hi,
>>
>> With glDrawArrays it works, I had anyway to change the example from:
>>
>> glDrawArrays(GL_QUADS,0,len(self.vertices))
>>
>> To:
>>
>> glDrawArrays(GL_QUADS,0,len(self.vertices) / 3)
>>
>>
>> Thanks,
>>
>>
>> Roland.
>>
>> Le 07/13/10 23:48, Alejandro Segovia a écrit :
>>> Hi Roland,
>>>
>>> I completely agree with Ian on this one. glDrawArrays seems more 
>>> appropriate for the way you are composing your arrays. IMO, this 
>>> should not be setting any constraints on how many vertices you can 
>>> supply to the GL tough.
>>>
>>> How much RAM does your video card have?
>>>
>>> Alejandro.-
>>>
>>> On Tue, Jul 13, 2010 at 1:22 PM, Ian Mallett <geo...@gm... 
>>> <mailto:geo...@gm...>> wrote:
>>>
>>>     My recommendation: use glDrawArrays(...).
>>>
>>>     #Init:
>>>
>>>     self.vertices = []
>>>     self.normals = []
>>>     self.nbrindices = 0
>>>     unit = 1.0
>>>     y = 0.0
>>>     rows = 2
>>>     columns = 8
>>>     z_center_delta = unit * (float(rows) / 2.0)
>>>     x_center_delta = unit * (float(columns) / 2.0)
>>>     for i in range(rows):
>>>         delta_z = (unit * float(i)) - z_center_delta
>>>         for j in range(columns):
>>>             delta_x = (unit * float(j)) - x_center_delta
>>>             self.vertices += [[0.0 + delta_x, y, 0.0 + delta_z],
>>>                               [0.0 + delta_x, y, unit + delta_z],
>>>                               [unit + delta_x, y, unit + delta_z],
>>>                               [unit + delta_x, y, 0.0 + delta_z]]
>>>             self.normals += [[0.0, +1.0, 0.0],
>>>                              [0.0, +1.0, 0.0],
>>>                              [0.0, +1.0, 0.0],
>>>                              [0.0, +1.0, 0.0]]
>>>
>>>     #Draw:
>>>     glPolygonMode(GL_FRONT_AND_BACK,GL_LINE)
>>>
>>>
>>>     glEnableClientState(GL_VERTEX_ARRAY)
>>>     glEnableClientState(GL_NORMAL_ARRAY)
>>>
>>>     glVertexPointer(3, GL_FLOAT, 0, self.vertices) # Specify the
>>>     vertex list to be used to draw the object
>>>     glNormalPointer(GL_FLOAT, 0, self.normals) # Specify the normals
>>>     list to be used to draw the object
>>>
>>>     glDrawArrays(GL_QUADS,0,len(self.vertices))
>>>
>>>
>>>     glDisableClientState(GL_VERTEX_ARRAY)
>>>     glDisableClientState(GL_NORMAL_ARRAY)
>>>
>>>     Ian
>>>
>>>     ------------------------------------------------------------------------------
>>>     This SF.net email is sponsored by Sprint
>>>     What will you do first with EVO, the first 4G phone?
>>>     Visit sprint.com/first <http://sprint.com/first> --
>>>     http://p.sf.net/sfu/sprint-com-first
>>>     _______________________________________________
>>>     PyOpenGL Homepage
>>>     http://pyopengl.sourceforge.net
>>>     _______________________________________________
>>>     PyOpenGL-Users mailing list
>>>     PyO...@li...
>>>     <mailto:PyO...@li...>
>>>     https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>>>
>>>
>>>
>>>
>>> -- 
>>> Alejandro Segovia Azapian
>>> Director, Algorithmia: Visualization & Acceleration
>>> http://web.algorithmia.net

Re: [PyOpenGL-Users] size limit of vertex array?

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

Hi,

Its me again still playing with vertex array.

Using the code showed previously, I have tried to display a plane of 60 
rows and 44 columns. With lighting disabled, no material properties 
defined and no normals provided, the rendering of such plane is 
performed at 10 FPS.

In addition, one of the core of the CPU is used at 100% by python what 
ever the size of the plane or the number of "objects" rendered.

Is it normal that python uses so much CPU?

Does 60 * 44 * 4, hence, 10560 vertices such big for an interactive 
application or should I use other techniques (VBO maybe) to render such 
amount of vertices or less vertices for such object? (I know that it 
depends, mainly, on what I want to do with the plane)

When using glGetString() to get information on the hardware here are the 
information I got:

NVIDIA Corporation
GeForce 8800 GTX/PCI/SSE2
3.2.0 NVIDIA 190.42

So it seems that the program is using the graphics card at some point.

The CPU of the machine is an AMD 64 X2 DualCore 5200+.



Thanks for any advise,


Roland



Le 07/14/10 11:49, Roland Everaert a écrit :
> Hi,
>
> With glDrawArrays it works, I had anyway to change the example from:
>
> glDrawArrays(GL_QUADS,0,len(self.vertices))
>
> To:
>
> glDrawArrays(GL_QUADS,0,len(self.vertices) / 3)
>
>
> Thanks,
>
>
> Roland.
>
> Le 07/13/10 23:48, Alejandro Segovia a écrit :
>> Hi Roland,
>>
>> I completely agree with Ian on this one. glDrawArrays seems more 
>> appropriate for the way you are composing your arrays. IMO, this 
>> should not be setting any constraints on how many vertices you can 
>> supply to the GL tough.
>>
>> How much RAM does your video card have?
>>
>> Alejandro.-
>>
>> On Tue, Jul 13, 2010 at 1:22 PM, Ian Mallett <geo...@gm... 
>> <mailto:geo...@gm...>> wrote:
>>
>>     My recommendation: use glDrawArrays(...).
>>
>>     #Init:
>>
>>     self.vertices = []
>>     self.normals = []
>>     self.nbrindices = 0
>>     unit = 1.0
>>     y = 0.0
>>     rows = 2
>>     columns = 8
>>     z_center_delta = unit * (float(rows) / 2.0)
>>     x_center_delta = unit * (float(columns) / 2.0)
>>     for i in range(rows):
>>         delta_z = (unit * float(i)) - z_center_delta
>>         for j in range(columns):
>>             delta_x = (unit * float(j)) - x_center_delta
>>             self.vertices += [[0.0 + delta_x, y, 0.0 + delta_z],
>>                               [0.0 + delta_x, y, unit + delta_z],
>>                               [unit + delta_x, y, unit + delta_z],
>>                               [unit + delta_x, y, 0.0 + delta_z]]
>>             self.normals += [[0.0, +1.0, 0.0],
>>                              [0.0, +1.0, 0.0],
>>                              [0.0, +1.0, 0.0],
>>                              [0.0, +1.0, 0.0]]
>>
>>     #Draw:
>>     glPolygonMode(GL_FRONT_AND_BACK,GL_LINE)
>>
>>
>>     glEnableClientState(GL_VERTEX_ARRAY)
>>     glEnableClientState(GL_NORMAL_ARRAY)
>>
>>     glVertexPointer(3, GL_FLOAT, 0, self.vertices) # Specify the
>>     vertex list to be used to draw the object
>>     glNormalPointer(GL_FLOAT, 0, self.normals) # Specify the normals
>>     list to be used to draw the object
>>
>>     glDrawArrays(GL_QUADS,0,len(self.vertices))
>>
>>
>>     glDisableClientState(GL_VERTEX_ARRAY)
>>     glDisableClientState(GL_NORMAL_ARRAY)
>>
>>     Ian
>>
>>     ------------------------------------------------------------------------------
>>     This SF.net email is sponsored by Sprint
>>     What will you do first with EVO, the first 4G phone?
>>     Visit sprint.com/first <http://sprint.com/first> --
>>     http://p.sf.net/sfu/sprint-com-first
>>     _______________________________________________
>>     PyOpenGL Homepage
>>     http://pyopengl.sourceforge.net
>>     _______________________________________________
>>     PyOpenGL-Users mailing list
>>     PyO...@li...
>>     <mailto:PyO...@li...>
>>     https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>>
>>
>>
>>
>> -- 
>> Alejandro Segovia Azapian
>> Director, Algorithmia: Visualization & Acceleration
>> http://web.algorithmia.net

Re: [PyOpenGL-Users] size limit of vertex array?

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

Hi,

With glDrawArrays it works, I had anyway to change the example from:

glDrawArrays(GL_QUADS,0,len(self.vertices))

To:

glDrawArrays(GL_QUADS,0,len(self.vertices) / 3)


Thanks,


Roland.

Le 07/13/10 23:48, Alejandro Segovia a écrit :
> Hi Roland,
>
> I completely agree with Ian on this one. glDrawArrays seems more 
> appropriate for the way you are composing your arrays. IMO, this 
> should not be setting any constraints on how many vertices you can 
> supply to the GL tough.
>
> How much RAM does your video card have?
>
> Alejandro.-
>
> On Tue, Jul 13, 2010 at 1:22 PM, Ian Mallett <geo...@gm... 
> <mailto:geo...@gm...>> wrote:
>
>     My recommendation: use glDrawArrays(...).
>
>     #Init:
>
>     self.vertices = []
>     self.normals = []
>     self.nbrindices = 0
>     unit = 1.0
>     y = 0.0
>     rows = 2
>     columns = 8
>     z_center_delta = unit * (float(rows) / 2.0)
>     x_center_delta = unit * (float(columns) / 2.0)
>     for i in range(rows):
>         delta_z = (unit * float(i)) - z_center_delta
>         for j in range(columns):
>             delta_x = (unit * float(j)) - x_center_delta
>             self.vertices += [[0.0 + delta_x, y, 0.0 + delta_z],
>                               [0.0 + delta_x, y, unit + delta_z],
>                               [unit + delta_x, y, unit + delta_z],
>                               [unit + delta_x, y, 0.0 + delta_z]]
>             self.normals += [[0.0, +1.0, 0.0],
>                              [0.0, +1.0, 0.0],
>                              [0.0, +1.0, 0.0],
>                              [0.0, +1.0, 0.0]]
>
>     #Draw:
>     glPolygonMode(GL_FRONT_AND_BACK,GL_LINE)
>
>
>     glEnableClientState(GL_VERTEX_ARRAY)
>     glEnableClientState(GL_NORMAL_ARRAY)
>
>     glVertexPointer(3, GL_FLOAT, 0, self.vertices) # Specify the
>     vertex list to be used to draw the object
>     glNormalPointer(GL_FLOAT, 0, self.normals) # Specify the normals
>     list to be used to draw the object
>
>     glDrawArrays(GL_QUADS,0,len(self.vertices))
>
>
>     glDisableClientState(GL_VERTEX_ARRAY)
>     glDisableClientState(GL_NORMAL_ARRAY)
>
>     Ian
>
>     ------------------------------------------------------------------------------
>     This SF.net email is sponsored by Sprint
>     What will you do first with EVO, the first 4G phone?
>     Visit sprint.com/first <http://sprint.com/first> --
>     http://p.sf.net/sfu/sprint-com-first
>     _______________________________________________
>     PyOpenGL Homepage
>     http://pyopengl.sourceforge.net
>     _______________________________________________
>     PyOpenGL-Users mailing list
>     PyO...@li...
>     <mailto:PyO...@li...>
>     https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>
>
>
>
> -- 
> Alejandro Segovia Azapian
> Director, Algorithmia: Visualization & Acceleration
> http://web.algorithmia.net

Re: [PyOpenGL-Users] size limit of vertex array?

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

Hi Roland,

I completely agree with Ian on this one. glDrawArrays seems more appropriate
for the way you are composing your arrays. IMO, this should not be setting
any constraints on how many vertices you can supply to the GL tough.

How much RAM does your video card have?

Alejandro.-

On Tue, Jul 13, 2010 at 1:22 PM, Ian Mallett <geo...@gm...> wrote:

> My recommendation: use glDrawArrays(...).
>
> #Init:
>
> self.vertices = []
> self.normals = []
> self.nbrindices = 0
> unit = 1.0
> y = 0.0
> rows = 2
> columns = 8
> z_center_delta = unit * (float(rows) / 2.0)
> x_center_delta = unit * (float(columns) / 2.0)
> for i in range(rows):
>     delta_z = (unit * float(i)) - z_center_delta
>     for j in range(columns):
>         delta_x = (unit * float(j)) - x_center_delta
>         self.vertices += [[0.0 + delta_x, y, 0.0 + delta_z],
>                           [0.0 + delta_x, y, unit + delta_z],
>                           [unit + delta_x, y, unit + delta_z],
>                           [unit + delta_x, y, 0.0 + delta_z]]
>         self.normals += [[0.0, +1.0, 0.0],
>                          [0.0, +1.0, 0.0],
>                          [0.0, +1.0, 0.0],
>                          [0.0, +1.0, 0.0]]
>
> #Draw:
> glPolygonMode(GL_FRONT_AND_BACK,GL_LINE)
>
>
> glEnableClientState(GL_VERTEX_ARRAY)
> glEnableClientState(GL_NORMAL_ARRAY)
>
> glVertexPointer(3, GL_FLOAT, 0, self.vertices) # Specify the vertex list to
> be used to draw the object
> glNormalPointer(GL_FLOAT, 0, self.normals) # Specify the normals list to be
> used to draw the object
>
> glDrawArrays(GL_QUADS,0,len(self.vertices))
>
>
> glDisableClientState(GL_VERTEX_ARRAY)
> glDisableClientState(GL_NORMAL_ARRAY)
>
> Ian
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> 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] size limit of vertex array?

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

My recommendation: use glDrawArrays(...).

#Init:
self.vertices = []
self.normals = []
self.nbrindices = 0
unit = 1.0
y = 0.0
rows = 2
columns = 8
z_center_delta = unit * (float(rows) / 2.0)
x_center_delta = unit * (float(columns) / 2.0)
for i in range(rows):
    delta_z = (unit * float(i)) - z_center_delta
    for j in range(columns):
        delta_x = (unit * float(j)) - x_center_delta
        self.vertices += [[0.0 + delta_x, y, 0.0 + delta_z],
                          [0.0 + delta_x, y, unit + delta_z],
                          [unit + delta_x, y, unit + delta_z],
                          [unit + delta_x, y, 0.0 + delta_z]]
        self.normals += [[0.0, +1.0, 0.0],
                         [0.0, +1.0, 0.0],
                         [0.0, +1.0, 0.0],
                         [0.0, +1.0, 0.0]]

#Draw:
glPolygonMode(GL_FRONT_AND_BACK,GL_LINE)

glEnableClientState(GL_VERTEX_ARRAY)
glEnableClientState(GL_NORMAL_ARRAY)

glVertexPointer(3, GL_FLOAT, 0, self.vertices) # Specify the vertex list to
be used to draw the object
glNormalPointer(GL_FLOAT, 0, self.normals) # Specify the normals list to be
used to draw the object

glDrawArrays(GL_QUADS,0,len(self.vertices))

glDisableClientState(GL_VERTEX_ARRAY)
glDisableClientState(GL_NORMAL_ARRAY)

Ian

Re: [PyOpenGL-Users] size limit of vertex array?

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

Ian,

Here is the code to create the list of vertices:

         self.vertices = []
         self.normals = []
         self.nbrindices = 0
         unit = 1.0
         y = 0.0
         rows = 8
         columns = 8
         z_center_delta = unit * (float(rows) / 2.0)
         x_center_delta = unit * (float(columns) / 2.0)
         for i in range(rows):
             delta_z = (unit * float(i)) - z_center_delta
             for j in range(columns):
                 delta_x = (unit * float(j)) - x_center_delta
                 self.vertices += [0.0 + delta_x, y, 0.0 + delta_z,
                                   0.0 + delta_x, y, unit + delta_z,
                                   unit + delta_x, y, unit + delta_z,
                                   unit + delta_x, y, 0.0 + delta_z]
                 self.normals += [0.0, +1.0, 0.0, 0.0, +1.0, 0.0, 0.0, 
+1.0, 0.0, 0.0, +1.0, 0.0]

         self.nbrindices = len(self.vertices) / 3
         self.indices = range(self.nbrindices)


In addition to creating the squares, the code try also to center the 
plane on the origin.

Next is the code used for the rendering:

         glPolygonMode(GL_FRONT_AND_BACK, GL_FILL)

         glEnableClientState(GL_VERTEX_ARRAY)
         glEnableClientState(GL_NORMAL_ARRAY)

         glVertexPointer(3, GL_FLOAT, 0, self.vertices) # Specify the 
vertex list to be used to draw the object
         glNormalPointer(GL_FLOAT, 0, self.normals) # Specify the 
normals list to be used to draw the object

         glDrawElements(GL_QUADS, self.nbrindices, GL_UNSIGNED_BYTE, 
self.indices)

         glDisableClientState(GL_VERTEX_ARRAY)
         glDisableClientState(GL_NORMAL_ARRAY)



Thanks for the help,


Roland.




Le 07/13/10 16:39, Ian Mallett a écrit :
> Hi,
>
> The bounds of a vertex array or VBO object should ultimately be 
> constrained by the amount of RAM and video memory you have.  I've 
> personally used vertex arrays of larger size than 64*4*3, so 
> something's wrong.
>
> What specifically goes wrong when you add more?  Can we see some code?
>
> Ian

Re: [PyOpenGL-Users] size limit of vertex array?

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

Hi,

The bounds of a vertex array or VBO object should ultimately be constrained
by the amount of RAM and video memory you have.  I've personally used vertex
arrays of larger size than 64*4*3, so something's wrong.

What specifically goes wrong when you add more?  Can we see some code?

Ian

[PyOpenGL-Users] size limit of vertex array?

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

Hello,


I would like to know if there is supposed to be a limit in the number of 
elements in a list given to glVertexPointer()?

I am using a vertex array to create a plane composed of small squares, 
after some experiment, it seems the vertex array cannot contains more 
than 64 squares whatever the size of the squares.

I have not tried to optimize the number of vertices I need to draw the 
plane, so for each square there is 4 vertices in the array. Thus the 
total number of elements in the list considered by opengl is 64 * 4 * 3, 
even if there is more than 64 squares defined in the array.


I know there is surely better way to draw such object, but this is not 
what I was interested in. I am currently playing with lighting and I 
wanted to study how to handle normal vectors, and how the color of the 
material is affected by the light and the normals.


Regards,



Roland.

Re: [PyOpenGL-Users] Building an interleaved buffer for pyopengl

[Dan H. <Dan...@no...>]

On 06/30/2010 05:53 PM, Nick Sonneveld wrote:
> Hello, thanks for your response!
>
> On Thu, Jul 1, 2010 at 4:40 AM, Dan Helfman<Dan...@no...>  wrote:
>> I think the answer to improving performance here is actually in one of
>> the responses to the stackoverflow question you posted: "The real
>> savings will be realized by a recasting of the render routine so that
>> you don't have to create a python object for every value that ends up
>> being placed in the buffer."
>
> I believe the point the poster bpowah on stackoverflow was making was
> just that I should reduce the number of objects (eg pregenerating
> texture coord lists)?  At least I guess that's how I interpreted it.

Regardless of what the poster meant, pre-generating texture coords is a 
good idea if you can get away with it.

>> In other words, don't create a separate object for each sprite, and
>> don't call a render() function once for each sprite. Structure your code
>> so that it's more data oriented rather than object oriented: Fill up a
>> NumPy array all at once with all of your sprites, trying to avoid any
>> looping in Python. Then send that array (interleaved or not) to a
>> PyOpenGL VBO.
>
> The problem is that I can't really see how to do things such as
> collision detection and response without doing at least one loop
> through all sprite objects. (I step through each sprite individually
> and do sprite movement and collision response to ensure no overlapping
> sprites).  Wouldn't things such as updating sprite position and
> adjusting for collision response mean the vertices change on every
> update? I can fill up a numpy array but it seems that modifying the
> array is slower than just creating a new numpy array from a python
> list.

A couple of ideas that may or may not be applicable to your program:

First, try to vectorize your use of NumPy arrays whenever possible. For 
instance, let's say you've got an array containing all sprite positions. 
You can create another array of movement/velocity vectors for all 
sprites. (An example of one velocity vector might be [ +10, -5 ].) And 
then each frame just do: sprite_positions += sprite_velocities to move 
the sprites in bulk without having to loop. For many sprites, velocities 
will only change occasionally, so you won't have to update all of them 
at once.

Second, if you really must loop over something, do it in C or Cython 
rather than pure Python. And for many cases, you can avoid having to do 
this by replacing a loop with a single NumPy operator or function call 
as described above.

> The random() methods may be a red herring.  Testing with a dummy
> method (that doesn't add data to a list) shows that render() in the
> example does take a while to run.  It doesn't quite explain why
> generating a new numpy array from a list is quicker than just
> modifying a preallocated numpy array though.

I'm not sure why that's happening, but ideally you'd be able to avoid 
generating a new list or a new array every frame. If you can generate an 
array once and then reuse it for as long as possible, that would be 
preferable.

Dan

Re: [PyOpenGL-Users] Recommendations for font rendering

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

Derakon wrote:
> It seems likely I'd need an
> approach that allows for each character to be on its own textured quad
> that I can toss anywhere as needed.

One approach is to render all the characters into a big
surface in a 16x16 grid or something like that, make a texture
out of it, and then render characters from it using appropriate
texture coordinates.

Another is to use a separate texture for each character,
although that may have more overhead, both in graphics
memory usage and rendering time.

-- 
Greg

Re: [PyOpenGL-Users] Recommendations for font rendering

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

On Wed, Jun 30, 2010 at 10:19 PM, Derakon <de...@gm...> wrote:

> Oh dear, I knew I forgot to mention something. I was using PyGame
> before, but I'm switching to OpenGL for performance reasons, which of
> course prevents direct blitting to the screen using PyGame. I tried
> using a "blit text to surface and convert to quad and draw" approach,
> but with text that changes frequently that means making a ton of new
> surfaces and it just doesn't perform well at all (in particular, my
> in-game console was unusably slow). It seems likely I'd need an
> approach that allows for each character to be on its own textured quad
> that I can toss anywhere as needed.
>
Hi,

Yes, I've run into that problem too.  My two cents on still using PyGame:

My solution is to make an OpenGL character set out of PyGame as a texture
atlas.  The text to be rendered can then just be converted to a list of
indices into the texture atlas and the individual characters drawn on
individual quads using the proper subimage.  I've used this technique for
framerate counters in several (unreleased) games (situations where the text
changes continuously).

If for some reason even that is too slow (because of the extra geometry; I
can only imagine this being an issue if you're trying to render thousands of
characters at a time), you can cram those quads into a display list or VBO
and cache the result for arbitrary use.  A VBO will also let you update
individual sections of the geometry, so you can still change section(s) of
the cached text to whatever you want at the computational cost of updating *
only* the changes.  A more advanced technique would be to create words just
by compositing character textures via glCopyTex______ functions.  That will
give you a single texture (a "word" texture atlas, if you will) that you can
cache and draw on a single quad as you please.

Of course, if the result of the font rendering is cached, the result only
need be generated once--and there will be no drop in framerate, no matter
how it was generated in the first place (direct rendering, texture atlas,
glCopyWhatever() compositing, etc.).  I've used this in conjunction with
direct rendering for several games (ex: the now somewhat old Spacewar
Multi<http://www.pygame.org/project-Spacewar+Multi-1025-.html>,
whose code may help you) where I was too lazy to set up a proper character
set (texture atlas).

Ian

Re: [PyOpenGL-Users] Recommendations for font rendering

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

You can use pyftgl that binds the FTGL library (Freetype OpenGL) and is
pretty standard. If you do not use too much fonts, you can also create
some font bitmaps and load them as texture.

Nicolas


On Wed, 2010-06-30 at 22:19 -0700, Derakon wrote:
> Oh dear, I knew I forgot to mention something. I was using PyGame
> before, but I'm switching to OpenGL for performance reasons, which of
> course prevents direct blitting to the screen using PyGame. I tried
> using a "blit text to surface and convert to quad and draw" approach,
> but with text that changes frequently that means making a ton of new
> surfaces and it just doesn't perform well at all (in particular, my
> in-game console was unusably slow). It seems likely I'd need an
> approach that allows for each character to be on its own textured quad
> that I can toss anywhere as needed.
> 
> On Wed, Jun 30, 2010 at 10:16 PM, Ian Mallett <geo...@gm...> wrote:
> > Hi,
> >
> > I use PyGame, which is cross-platform, and can load standard font types.
> > The font is rendered as a "surface", which can be changed to a texture and
> > mapped your polygon(s).
> >
> > Ian
> >
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users