pyopengl-users — Discussion of all PyOpenGL matters.

Re: [PyOpenGL-Users] py2exe stuff

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

. wrote:
> Well, I got past the 'win32' ImportError by adding 
> 'OpenGL.platform.win32' into the includes section of my custom py2exe 
> setup.py...
>
> But now I'm getting the following:
>
> TypeError: ("No array-type handler for type <type 'str'> (value: 
> '\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\) 
> registered", <OpenGL.GL.images.ImageInputConverter object at 0x00978CB0>)
>
> I read somewhere from Mike Fletcher that this has to do with the fact 
> PyOpenGL wasn't installed with setuptools but this is a py2exe setup here.
>
> How should I proceed? Thanks!
That's weird.  There's no need for setuptools any more.  The str handler 
is registered in the __init__ of OpenGL, so it should always be 
available.  Are you sure you're using the c1 release (or bzr head)?  Any 
chance there's an old copy of PyOpenGL in your py2exe build directory, 
or one on your pythonpath that's getting picked up before the c1 release?

Good luck,
Mike

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

[PyOpenGL-Users] py2exe stuff

[. <rem...@gm...>]

Well, I got past the 'win32' ImportError by adding 'OpenGL.platform.win32'
into the includes section of my custom py2exe setup.py...

But now I'm getting the following:

TypeError: ("No array-type handler for type <type 'str'> (value:
'\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\)
registered", <OpenGL.GL.images.ImageInputConverter object at 0x00978CB0>)

I read somewhere from Mike Fletcher that this has to do with the fact
PyOpenGL wasn't installed with setuptools but this is a py2exe setup here.

How should I proceed? Thanks!

Re: [PyOpenGL-Users] Shader linking problems...

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

On 3/18/09 3:32 PM, Nick Klepinger wrote:
>
>
> On Wed, Mar 18, 2009 at 7:15 AM, Mike C. Fletcher 
> <mcf...@vr... <mailto:mcf...@vr...>> wrote:
>
>     Gijs wrote:
>
>         On 3/18/09 2:36 PM, Nick Klepinger wrote:
>
>     ...
>
>             This is the what shows in the info log:
>
>             Fragment shader(s) failed to link,  vertex shader(s)
>             failed to link.
>             ERROR: 0:1: 'v' : syntax error parse error
>             ERROR:  compilation errors.  No code generated.
>
>     Definitely sounds like you're passing a string instead of a
>     list-of-strings.
>
>     Enjoy,
>
>     Mike
>
>     -- 
>     ________________________________________________
>      Mike C. Fletcher
>      Designer, VR Plumber, Coder
>     http://www.vrplumber.com
>     http://blog.vrplumber.com
>
>
>
> Sure enough, that did the trick.  Interesting it runs perfectly fine 
> on Linux.  Thanks for all the help everyone!
>
> -bodiddlie
Would be nice if PyOpenGL could warn us about it. The last time I had 
this problem, it took me almost 2 days to find the cause. Since it was 
running without any errors on Mac OS X and only begin to throw errors at 
me in WinXP when I upgraded my videocard/updated videocard driver. Linux 
didn't like it either. Since the error itself doesn't quite explain what 
is going on, I only found the problem after having checked every status 
of the compile/link/validate-step.

Regards, Gijs

Re: [PyOpenGL-Users] bug in glDrawBuffers?

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

On 3/20/09 7:44 AM, René Dudfield wrote:
> Hi,
>
> I tried with python2.5.2 (preinstalled python) and python2.5.4 on osx
> 10.5.6 and it fails with both.
>
> I made a small pyrex wrapper of the functions, and dropped them into
> the test, and they worked.   So I'm guessing it's a ctypes issue of
> some sort maybe.
>
>
> cu,
What kind of version do you have of PyOpenGL? I'm running Python 2.5.4 
and PyOpenGL 3.0.0c1 and that works perfectly without any extra work.

Re: [PyOpenGL-Users] bug in glDrawBuffers?

[René D. <re...@gm...>]

Hi,

I tried with python2.5.2 (preinstalled python) and python2.5.4 on osx
10.5.6 and it fails with both.

I made a small pyrex wrapper of the functions, and dropped them into
the test, and they worked.   So I'm guessing it's a ctypes issue of
some sort maybe.


cu,



On Mon, Feb 23, 2009 at 2:01 AM, Gijs <in...@bs...> wrote:
> On 2/22/09 5:43 AM, Mike C. Fletcher wrote:
>> Mike C. Fletcher wrote:
>>> Gijs wrote:
>> ...
>>> ...
>>>> ctypes.ArgumentError: argument 2: <type 'exceptions.TypeError'>:
>>>> wrong type
>>>>
>>>> I tend to cast everything that needs to be passed to OpenGL and is
>>>> returned from OpenGL functions (like the genTextures and
>>>> genFramebuffers function). Guess I kinda got used to it but I knew
>>>> it wasn't normal.
>>> Okay, that would seem to be final confirmation that we have bugs in
>>> handling of numpy uints on 32-bit platforms.  Luckily we now have a
>>> test-case I can run to provoke it :) .
>> Can you confirm that the machine exhibiting the problem is running
>> something less than Python 2.5.2?  I can duplicate the effect on my
>> 32-bit Vista machine *only* if I downgrade to 2.5.1.  Thinking back on
>> it, this must be the bug that we discovered which had us add the
>> ALLOW_NUMPY_SCALARS flag to the OpenGL.__init__ module.  Thomas had
>> said he was intending to fix it in ctypes, and it looks like he did
>> just that in 2.5.2.  2.5.4 does not exhibit the problem.
>>
>> Assuming that you can confirm it seems we'll either have to tell
>> people to use >= 2.5.2 and/or document the use of ALLOW_NUMPY_SCALARS
>> for those weird cases where for some reason someone needs to use an
>> older version.  Will need to test with Python 2.4 and/or stand-alone
>> ctypes to determine the versions to recommend.
>>
>> Thanks,
>> Mike
>>
> It's running Python 2.5.1. It is the standard version of Python that got
> delivered with Mac OS X 10.5. So unless people upgraded to a higher
> version of Python, it should affect everyone that's running Mac OS X 10.5.
>
> Regards, Gijs
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>

Re: [PyOpenGL-Users] Shadowmapping Strangeness

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

I seem to have solved both problems by transforming the texture matrix by
the object's transforms.  This is annoying, but it works.

[PyOpenGL-Users] PyGameSF meetup Tuesday March 24th 10th 6pm @ Main San Francisco Public Library

[Harry T. <Har...@di...>]

Hi All,
This months PyGameSF meet up is at the STONG conference room on the
first floor of the main San Francisco public library beside civic
center BART. The library closes at 8pm so we will be reconviening to
frjtz on hayes street for dinner/drinks afterwords.  This month's
presentations are:
 
    - Casey Duncan:  Going Low-level, A peek under the hood at the C
     implementation of the Lepton particle engine as an example of how
to
     develop for Python in C for ultimate performance. We'll take a peek
at
     Lepton itself and take a crack at extending it with C.
 
    - Harry Tormey:  Fast prototyping Word games with python and
      pyglet. An introduction to working with pyglet, the cross-platform
      windowing and multimedia library. This talk will cover how to
      structure a game with pyglet, how it differs from working with
pygame,
      best practices for using the pyglet event loop, working with
OpenGL
      vertex arrays to manipulate text and general tips on how not to go
      insane if you are an OpenGL newbie.
 

PyGame SF is an informal group meet up in San Francisco for Software
engineers interested in python, OpenGL, audio, pygame, SDL,
programming and generally anything to do with multimedia development.
The format of our meetings typically involve several people giving
presentations on projects they are developing followed by
group discussion and feedback.
 
If anyone else would like to give a micro presentation, show demos or
just talk about what they are doing or generally give examples of any
relevant software they are working on please feel free to head along.
 
To subscribe to the pygamesf mailing list simply email
pygame-sf+subscribe at unworkable.org
 
--
Harry Tormey
PyGameSF
http://pygamesf.org/ <BLOCKED::http://pygamesf.org/> 
P2P Research
http://p2presearch.com <BLOCKED::http://p2presearch.com> 
Blog
http://harrytormey.com <BLOCKED::http://harrytormey.com> 

Re: [PyOpenGL-Users] Shader linking problems...

[Nick K. <bod...@gm...>]

On Wed, Mar 18, 2009 at 7:15 AM, Mike C. Fletcher <mcf...@vr...>wrote:

> Gijs wrote:
>
>> On 3/18/09 2:36 PM, Nick Klepinger wrote:
>>
>>
> ...
>
>> This is the what shows in the info log:
>>>
>>> Fragment shader(s) failed to link,  vertex shader(s) failed to link.
>>> ERROR: 0:1: 'v' : syntax error parse error
>>> ERROR:  compilation errors.  No code generated.
>>>
>>>
>> Definitely sounds like you're passing a string instead of a
> list-of-strings.
>
> Enjoy,
>
> Mike
>
> --
> ________________________________________________
>  Mike C. Fletcher
>  Designer, VR Plumber, Coder
>  http://www.vrplumber.com
>  http://blog.vrplumber.com
>
>

Sure enough, that did the trick.  Interesting it runs perfectly fine on
Linux.  Thanks for all the help everyone!

-bodiddlie

Re: [PyOpenGL-Users] Shader linking problems...

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

Gijs wrote:
> On 3/18/09 2:36 PM, Nick Klepinger wrote:
>   
...
>> This is the what shows in the info log:
>>
>> Fragment shader(s) failed to link,  vertex shader(s) failed to link.
>> ERROR: 0:1: 'v' : syntax error parse error
>> ERROR:  compilation errors.  No code generated.
>>     
Definitely sounds like you're passing a string instead of a list-of-strings.

Enjoy,
Mike

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

Re: [PyOpenGL-Users] Shader linking problems...

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

Nick Klepinger wrote:
> Hi all,
>
> I've been having some problems getting some basic shaders to link when 
> loading from a file.  If I hard code the shaders as a python string, I 
> have no problems.  Here's how I'm loading the shaders.
Only thing that jumps out at me is that you're compiling a single 
string, while glShaderSource normally takes a list-of-strings.  I know 
I've seen that fail before.  Other big difference might be that you've 
got a unicode value popping up from somewhere, with a null-byte value 
terminating the string as far as OpenGL is concerned.

Good luck,
Mike

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

Re: [PyOpenGL-Users] Shader linking problems...

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

On 3/18/09 2:36 PM, Nick Klepinger wrote:
> On Wed, Mar 18, 2009 at 6:12 AM, Gijs <in...@bs... 
> <mailto:in...@bs...>> wrote:
>
>     On 3/17/09 11:58 PM, bod...@gm...
>     <mailto:bod...@gm...> wrote:
>
>         Maybe, but I'm thinking not. The shaders compile fine, then
>         error on linking.
>         -----Original Message-----
>         From: Ian Mallett<geo...@gm...
>         <mailto:geo...@gm...>>
>
>         Date: Tue, 17 Mar 2009 15:35:37
>         To: PyOpenGL Users<pyo...@li...
>         <mailto:pyo...@li...>>
>         Subject: [PyOpenGL-Users]  Shader linking problems...
>
>     What is the error that you get?
>
>     Regards, Gijs
>
>
> This is the what shows in the info log:
>
> Fragment shader(s) failed to link,  vertex shader(s) failed to link.
> ERROR: 0:1: 'v' : syntax error parse error
> ERROR:  compilation errors.  No code generated.
>
> ERROR: 0:1: 'v' : syntax error parse error
> ERROR:  compilation errors.  No code generated.
>
> Here's the shaders I'm trying to load.
>
> varying vec3 pos;
> void main() {
>     pos = gl_Vertex.xyz;
>     gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
> }
>
> varying vec3 pos;
> void main() {
>         gl_FragColor.rgb = pos.xyz;
> }
>
>
> Also, tried this last night on my laptop running Ubuntu Hardy, and it 
> ran fine.  This is error is showing up on XP.
>
> -bodiddlie
>
I've only seen this error occur when you print your log using the 
program-object instead of the shader-object. You sure you're printing 
the log from the correct object? (I'm sure there is an error otherwise 
it would just run fine)

Regards, Gijs

PS: You also need to send a reply to the mailinglist :)

[PyOpenGL-Users] Shadowmapping Strangeness

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

Hello,

I have a problem with shadowmapping in my shaders.  The occluder appears to
be casting a shadow correctly on other objects, but not correctly on
itself.  The effect is difficult to describe, but it looks sort of like the
shadowmap is rotating twice as fast as the object rotates and is flipped
(occluded not shadowed and vice-versa).

The following example program displays the effect:
geometrian.com/shadowmapping%20problem.zip.  The occluder is a spaceship
from turbosquid.com rendered with VBOs (thanks!) and the floor is a single
quad with a brick texture applied.  As you can see, the shadow on the floor
looks correct (see below), but the shadow on the spaceship is not.  Try
rotating the camera and the spaceship (left or right click + drag
respectively).

My *guess *is that the texture matrix is not being set up correctly.  The
floor may look fine, but the floor is 2D, so the "flipped" effect mentioned
earlier has no real effect.  Also, when the floor is rotated, the shadow
rotates with it, so the rotation problem is still there too.  The spaceship
shows these problems quite obviously.

I think I should be able to fix the "flipped" problem in the shader, but
what do I do about the shadow rotation problem?

Thanks a ton,
Ian

Re: [PyOpenGL-Users] Difficulty accessing glCreateShader

[Mohan <mg...@ca...>]

On Mar 17 2009, Mike C. Fletcher wrote:

>.  You are 
>using code that uses the equivalent of the "raw" PyOpenGL api, i.e. raw 
>ctypes-coded interfaces with the C DLL.  You can certainly continue to 
>do that, or you can switch to using the PyOpenGL API.  The code sample 
>you are using as a source is from before PyOpenGL supported the 2.x (or 
>3.x) extension functions, so it's showing you the raw C-style API 
>calls.  Probably would be easier to use a sample written for PyOpenGL 
>3.x to get started faster. 

Now I understand why the documentation provides two signatures for each 
function! I'll and keep trying with the (considerably nicer) non-raw 
interface. Thank you again.

Mohan

Re: [PyOpenGL-Users] Shader linking problems...

[<bod...@gm...>]

Maybe, but I'm thinking not. The shaders compile fine, then error on linking. 
-----Original Message-----
From: Ian Mallett <geo...@gm...>

Date: Tue, 17 Mar 2009 15:35:37 
To: PyOpenGL Users<pyo...@li...>
Subject: [PyOpenGL-Users]  Shader linking problems...


------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com

[PyOpenGL-Users] Shader linking problems...

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

Perhaps newlines are getting mixed in when the file is read?

[PyOpenGL-Users] Shader linking problems...

[Nick K. <bod...@gm...>]

Hi all,

I've been having some problems getting some basic shaders to link when
loading from a file.  If I hard code the shaders as a python string, I have
no problems.  Here's how I'm loading the shaders.

f  = open('test.vert')
vertex = f.read()
f.close()

f = open('test.frag')
fragment = f.read()
f.close

program = compile_program(vertex, fragment)


I know that the file's are loading from doing a print of the two vars.
Here's my compile functions:

def compile_shader(source, shader_type):
    shader = glCreateShaderObjectARB(shader_type)

    glShaderSourceARB(shader, source)

    glCompileShaderARB(shader)

    status = glGetObjectParameterivARB(shader, GL_OBJECT_COMPILE_STATUS_ARB)

    if not status:
    print_log(shader)
        glDeleteObjectARB(shader)
        raise ValueError, 'Shader compilation failed'
    return shader

def compile_program(vertex_source, fragment_source):
    glInitShaderObjectsARB()
    glInitVertexShaderARB()
    glInitFragmentShaderARB()
    program = glCreateProgramObjectARB()

    if vertex_source:
        vertex_shader = compile_shader(vertex_source, GL_VERTEX_SHADER_ARB)
    glAttachObjectARB(program, vertex_shader)
    if fragment_source:
        fragment_shader = compile_shader(fragment_source,
GL_FRAGMENT_SHADER_ARB)
    glAttachObjectARB(program, fragment_shader)

    glLinkProgramARB(program)

    status = glGetObjectParameterivARB(program, GL_OBJECT_LINK_STATUS_ARB)

    if not status:
    print_program_log(program)
    raise ValueError, 'Program link failed'

    if vertex_shader:
        glDeleteObjectARB(vertex_shader)
    if fragment_shader:
        glDeleteObjectARB(fragment_shader)

    return program

def print_log(shader):
    length = glGetObjectParameterivARB(shader,
GL_OBJECT_INFO_LOG_LENGTH_ARB)

    if length > 0:
        log = glGetInfoLogARB(shader)
        print log

def print_program_log(program):
    length = glGetObjectParameterivARB(program,
GL_OBJECT_INFO_LOG_LENGTH_ARB)

    if length > 0:
    log = glGetInfoLogARB(program)
    print log
    else:
    print 'An error occurred in the program.'

Any ideas?  Thanks!

-bodiddlie

Re: [PyOpenGL-Users] Difficulty accessing glCreateShader

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

Mohan wrote:
> Hi Mike,
>
> Thank you very much for the (very quick!) reply. Changing the code to refer 
> to
>
>    glCreateShader = OpenGL.GL.glCreateShader 
>
> etc. solved that problem. Unfortunately, there is still an error, namely
>
>    ValueError: glShaderSource requires 2 arguments (shaderObj, string), 
> received 4:
>     (2L, 1, <cparam 'P' (0187bd28)>, <cparam 'P' (0187bd78)>)
>  
> (I have kept the
>
>    glShaderSource.argtypes = [c_int, c_int, POINTER(c_char_p), 
> POINTER(c_int)]
>
> in the source.)
>   
Sorry, I should have been more verbose in the explanation.  You are 
using code that uses the equivalent of the "raw" PyOpenGL api, i.e. raw 
ctypes-coded interfaces with the C DLL.  You can certainly continue to 
do that, or you can switch to using the PyOpenGL API.  The code sample 
you are using as a source is from before PyOpenGL supported the 2.x (or 
3.x) extension functions, so it's showing you the raw C-style API 
calls.  Probably would be easier to use a sample written for PyOpenGL 
3.x to get started faster.  There's a sample in OpenGLContext, another 
in the proesch PyOpenGL-Demo subdirectory, and a third in the 
PyOpenGL-Demo/GLUT subdirectory IIRC.

You shouldn't need any ctypes references to work with PyOpenGL unless 
you want to use ctypes data-types (arrays).  You shouldn't ever need to 
specify argtypes for a PyOpenGL function, at least.
> In another post on a very similar problem (pyopengl-Bugs-1878648), you wrote
>
>   
>> I'm guessing what's
>>     
> happening is that you are on Win32, and that at the point where you import
> the module, there's no glShaderSource function. As a result the wrappers
> were not being created. Later, when you tried to call them, the
> null-function wrapper was able to resolve the function and tried to call it
> directly.<
>
> Is there a workaround for this? I had a look at the example you mentioned 
> in that post, and it references glShaderSourceARB rather than 
> glShaderSource. I can switch to ARB extensions if need be, but I'd like to 
> understand why the straightforward 2.0 approach isn't working, i.e. why 
> there's no glShaderSource function when the module is imported.
>   
This is an allowed OpenGL operating modality, and apparently some driver 
writers are relying on it.  Basically the work-around is to only do the 
calls *after* you have a rendering context available from which to 
retrieve the functions.  It shouldn't happen with *core* functions 
AFAIK, it should only happen with ARB, EXT or other extension functions.

HTH,
Mike

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

Re: [PyOpenGL-Users] Difficulty accessing glCreateShader

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

Mohan wrote:
> Hi Mike,
>
> Thank you very much for the (very quick!) reply. Changing the code to refer 
> to
>
>    glCreateShader = OpenGL.GL.glCreateShader 
>
> etc. solved that problem. Unfortunately, there is still an error, namely
>
>    ValueError: glShaderSource requires 2 arguments (shaderObj, string), 
> received 4:
>     (2L, 1, <cparam 'P' (0187bd28)>, <cparam 'P' (0187bd78)>)
>  
> (I have kept the
>
>    glShaderSource.argtypes = [c_int, c_int, POINTER(c_char_p), 
> POINTER(c_int)]
>
> in the source.)
>
> In another post on a very similar problem (pyopengl-Bugs-1878648), you wrote
>
>> I'm guessing what's
> happening is that you are on Win32, and that at the point where you import
> the module, there's no glShaderSource function. As a result the wrappers
> were not being created. Later, when you tried to call them, the
> null-function wrapper was able to resolve the function and tried to call it
> directly.<
>
> Is there a workaround for this? I had a look at the example you mentioned 
> in that post, and it references glShaderSourceARB rather than 
> glShaderSource. I can switch to ARB extensions if need be, but I'd like to 
> understand why the straightforward 2.0 approach isn't working, i.e. why 
> there's no glShaderSource function when the module is imported.
>
> It sounds like I might be asking for help in an inappropriate place, in 
> that I'm not really using the functionality of PyOpenGL. (I am very 
> grateful for the previous assistance!) Would you happen to know of a more 
> appropriate mailing list or forum?
>
> Thanks again,
> Mohan
>
> PS. My mail client is misbehaving -- I've waited half an hour to avoid 
> double posts, but in case something went wrong I'm very sorry!
Hello Mohan,

I fooled around with these kinds of problems quite a bit and the best
way to make it work without too much work, is to switch all your OpenGL
code to their ARB equivalents. Best thing is that it makes it portable
across platforms as well. If you use the ARB function calls instead of
the "normal" ones, Windows, Mac OS X and Linux usually works 99% of the
time (not including driver differences).

I'm not completely clear on the problem, but it has something to do with
how/when the functions are bound to their OpenGL functions. Windows
binds them later on, while Mac OS X and Linux bind them earlier (from
what I've seen so far). Maybe Windows binds them when you call the Glut
init functions, but I'm sure Mike can give you a better answer regarding
the problem.

Regards, Gijs

Re: [PyOpenGL-Users] Difficulty accessing glCreateShader

[Mohan <mg...@ca...>]

Hi Mike,

Thank you very much for the (very quick!) reply. Changing the code to refer 
to

   glCreateShader = OpenGL.GL.glCreateShader 

etc. solved that problem. Unfortunately, there is still an error, namely

   ValueError: glShaderSource requires 2 arguments (shaderObj, string), 
received 4:
    (2L, 1, <cparam 'P' (0187bd28)>, <cparam 'P' (0187bd78)>)
 
(I have kept the

   glShaderSource.argtypes = [c_int, c_int, POINTER(c_char_p), 
POINTER(c_int)]

in the source.)

In another post on a very similar problem (pyopengl-Bugs-1878648), you wrote

>I'm guessing what's
happening is that you are on Win32, and that at the point where you import
the module, there's no glShaderSource function. As a result the wrappers
were not being created. Later, when you tried to call them, the
null-function wrapper was able to resolve the function and tried to call it
directly.<

Is there a workaround for this? I had a look at the example you mentioned 
in that post, and it references glShaderSourceARB rather than 
glShaderSource. I can switch to ARB extensions if need be, but I'd like to 
understand why the straightforward 2.0 approach isn't working, i.e. why 
there's no glShaderSource function when the module is imported.

It sounds like I might be asking for help in an inappropriate place, in 
that I'm not really using the functionality of PyOpenGL. (I am very 
grateful for the previous assistance!) Would you happen to know of a more 
appropriate mailing list or forum?

Thanks again,
Mohan

PS. My mail client is misbehaving -- I've waited half an hour to avoid 
double posts, but in case something went wrong I'm very sorry!

Re: [PyOpenGL-Users] Difficulty accessing glCreateShader

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

Mohan wrote:
> Hi,
>
> I'm just starting with PyOpenGL (installed from PyOpenGL-3.0.0c1.win32.exe 
> under a fresh install of Python 2.5 on Windows XP Professional; the only 
> other package installed is pygame). I'm running into problems with the 
> example here:
>
>    http://www.pygame.org/wiki/GLSLExample
>
> I get the error:
>
>    AttributeError: function 'glCreateShader' not found
>
> on line 26: glCreateShader = gl.glCreateShader
>   
That code is not really using PyOpenGL.  It's just using ctypes to 
access the raw functionality via PyOpenGL's pointer to the OpenGL library.

from OpenGL.GL import glCreateShader

should get a fully functional and wrapped version of the function, as 
long as it's available on your machine.

HTH,
Mike

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

[PyOpenGL-Users] Difficulty accessing glCreateShader

[Mohan <mg...@ca...>]

Hi,

I'm just starting with PyOpenGL (installed from PyOpenGL-3.0.0c1.win32.exe 
under a fresh install of Python 2.5 on Windows XP Professional; the only 
other package installed is pygame). I'm running into problems with the 
example here:

   http://www.pygame.org/wiki/GLSLExample

I get the error:

   AttributeError: function 'glCreateShader' not found

on line 26: glCreateShader = gl.glCreateShader

glGetString(...) reports that I'm running version 2.1.2 from NVidia, and 
have reams of extensions available.

Any help would be much appreciated!
Mohan

Re: [PyOpenGL-Users] VBO Problem

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

Ian Mallett wrote:
> Hi,
>
> I've been trying a long time to get VBOs working with PyOpenGL.  The 
> VBOs appear to be created correctly, but I don't see anything at all 
> on the screen (I have other objects onscreen too not drawn with VBOs 
> just to make sure). 
>
> I'm creating the VBOs like so (vbo_formatted_vertices is a NumPy array 
> of the vertices all lumped into one array (not separated into separate 
> 3-item lists)):
Sorry I haven't time tonight to look into what's going on in your code, 
but here are 4 pieces of sample code that all use VBOs to draw with 
PyOpenGL...

http://bazaar.launchpad.net/~mcfletch/openglcontext/trunk/annotate/head%3A/tests//shader_1.py
http://bazaar.launchpad.net/~mcfletch/openglcontext/trunk/annotate/head%3A/tests//shader_2.py
http://bazaar.launchpad.net/~mcfletch/openglcontext/trunk/annotate/head%3A/tests//shader_3.py
http://bazaar.launchpad.net/~mcfletch/openglcontext/trunk/annotate/head%3A/tests//shader_4.py

which may help you pinpoint what's not working.  The 4th example shows 
usage in almost-legacy-free form (other than the model-view matrix), the 
arrays passed to the VBO are "interleaved" style vertex arrays.

HTH,
Mike

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

[PyOpenGL-Users] VBO Problem

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

Hi,

I've been trying a long time to get VBOs working with PyOpenGL.  The VBOs
appear to be created correctly, but I don't see anything at all on the
screen (I have other objects onscreen too not drawn with VBOs just to make
sure).

I'm creating the VBOs like so (vbo_formatted_vertices is a NumPy array of
the vertices all lumped into one array (not separated into separate 3-item
lists)):

vertex_vbo = glGenBuffersARB(1)
glBindBufferARB(GL_ARRAY_BUFFER_ARB,vertex_vbo)
glBufferDataARB(GL_ARRAY_BUFFER_ARB,vbo_formatted_vertices,GL_STATIC_DRAW_ARB)

I am trying to draw the VBOs like so (zero_array =
[0]*len(self.vbo_formatted_vertices[i]):

glEnableClientState(GL_VERTEX_ARRAY)
glBindBufferARB(GL_ARRAY_BUFFER_ARB,vertex_vbo)
glVertexPointer(3,GL_FLOAT,0,zero_array)
glDrawArrays(GL_TRIANGLES,0,len(vbo_formatted_vertices))
glDisableClientState(GL_VERTEX_ARRAY)
glBindBufferARB(GL_ARRAY_BUFFER_ARB,0)

Again, the code appears to run fine; I just don't see anything.

Ideas why?
Thanks,
Ian

Re: [PyOpenGL-Users] passing multiple values to glUniform

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

Gijs wrote:
...
>
> Yea, the "None"-fix did the trick. Now I can finally get rid of those
> ugly for loops that set the array one by one :)
>
> Thanks.
>
> Regards, Gijs
>   
Okay, I've pushed it into current BZR, so it should show up in the final 
release.  I'd still like to get a test case for PyOpenGL or 
OpenGLContext that uses it, but that can wait until I have a bit more time.

Thanks,
Mike

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

Re: [PyOpenGL-Users] passing multiple values to glUniform

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

Mike C. Fletcher wrote:
> Gijs wrote:
>> Hello,
>>
>> I'm kinda running into a problem here using the glUniform functions.
>> I use the following piece of code to set 8 values in the fragment
>> shader:
>> input_image  = glGetUniformLocationARB(program, "input_image")
>> glUniform1ivARB(input_image, 8, array([0, 1, 2, 3, 4, 5, 6, 7], 'i'))
>>   
> There's a definite bug in the wrapper, it was written before I
> realized that you could pass multiple values to the vector forms.  In
> GL/ARB/shader_objects.py line 53, change "size" to None in the call
> and it *should* work.  I'll need to construct a test case and apply it
> to the 2.0 version as well, of course.
>
> Thanks for the bug report,
> Mike
>
Yea, the "None"-fix did the trick. Now I can finally get rid of those
ugly for loops that set the array one by one :)

Thanks.

Regards, Gijs