pyopengl-users — Discussion of all PyOpenGL matters.

[PyOpenGL-Users] _base_glutInit( ctypes.byref(count), holder ) TypeError: 'NoneType' object is not callable

[John L. <joh...@gm...>]

Hey Guys!,

Does anyone know what the fix for the following error is:

C:\dev\PyOpenGL-Demo-3.0.1b1\PyOpenGL-Demo\NeHe>python
Python 2.5.4 (r254:67916, Dec 23 2008, 15:10:54) [MSC v.1310 32 bit (Intel)]
on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import lesson5.py
Hit ESC key to quit.
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "lesson5.py", line 240, in <module>
    main()
  File "lesson5.py", line 195, in main
    glutInit(sys.argv)
  File "C:\Python25\Lib\site-packages\OpenGL\GLUT\special.py", line 323, in
glutInit
    _base_glutInit( ctypes.byref(count), holder )
TypeError: 'NoneType' object is not callable
>>>

I am running 2.5 on XP with NVidia drivers. I have GLUT, GLU, OpenGL
installed on the system.
I can get NeHe samples working from within VC++ 2010, just not Python.

Thanks!,
John

[PyOpenGL-Users] PyOpenGL at Northwest Python Day

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

For any of you in or around the Seattle area: I'll be giving a talk at 
Northwest Python Day this Saturday in Seattle in which PyOpenGL will 
feature prominently. I'll be talking about how I developed a 
high-performance mapping application called Maproom with PyOpenGL and 
other Python libraries.

More about the conference: http://seapig.org/NWPD10
More about the talk: http://seapig.org/NWPD10Talks#PyOpenGL

Hope to see some of you there!

Dan

Re: [PyOpenGL-Users] glumpy, a fast-OpenGL based numpy visualization

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

You can get the whole tree with command:

hg clone http://glumpy.googlecode.com/hg/ glumpy



Nicolas

On Jan 25, 2010, at 14:08 , Nils Sudmann wrote:

> Hi,
> 
> This is very interesting to me, but do I have to download each individual file at http://glumpy.googlecode.com/hg/ (glumpy) since there are no files in downloads at http://code.google.com/p/glumpy/downloads/list ?
> I could always use wget, but surly this is not what you intended?
> 
> This is interesting since I have used IDL (http://en.wikipedia.org/wiki/IDL_%28programming_language%29) a bit at work, but the licenses are a bitch.
> 
> Good work.
> 
> On Mon, Jan 25, 2010 at 12:20 PM, Nicolas Rougier <Nic...@lo...> wrote:
> 
> 
> Hello,
> 
> glumpy is a fast-OpenGL based numpy visualization based on top of
> PyOpenGL and IPython (for interactive sessions) that allows for the fast
> vizualization of numpy arrays (mainly two dimensional). It had been
> designed with efficiency in mind and if you want to have a sense of
> what’s going on in your simulation while it is running, then maybe
> glumpy can help you.
> 
> Sources: hg clone http://glumpy.googlecode.com/hg/ glumpy
> No installation required, you can run all demos inplace.
> 
> Homepage: http://code.google.com/p/glumpy/
> 
> 
> Nicolas
> 
> 
> ------------------------------------------------------------------------------
> Throughout its 18-year history, RSA Conference consistently attracts the
> world's best and brightest in the field, creating opportunities for Conference
> attendees to learn about information security's most important issues through
> interactions with peers, luminaries and emerging and established companies.
> http://p.sf.net/sfu/rsaconf-dev2dev
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
> 
> 
> 
> -- 
> If Atheism is a religion, then not collecting stamps is a hobby.

Re: [PyOpenGL-Users] Vista, PyOpengl 3.0.1b2 and VBO's

[Nils S. <su...@gm...>]

Addendum: Adding WX_GL_RGBA in addition to WX_GL_DOUBLEBUFFER as options to
wxPython.GLCanvas also worked. Weird stuff, but probably this is a fault in
wxPython (in combination with Vista?).

On Sun, Jan 24, 2010 at 9:56 PM, Nils Sudmann <su...@gm...> wrote:

> Found the faulty code.
>
> I was using wxPython GLCanvas and specified WX_GL_DOUBLEBUFFER. After
> rewriting the code to use old vertex arrays, it kind of worked, but a lot of
> other stuff was strange. It seems that WX_GL_DOUBLEBUFFER caused GL_VERSION
> to report 1.1.0 and probably disabled all the buffer object functionality
> and other stuff. Removing the doublebuffer option caused GL_VERSION to
> report 3.2.0 and everything worked!
>
> Again thanks for all the help.
>
>
> On Sun, Jan 24, 2010 at 3:01 PM, Alejandro Segovia <as...@gm...>wrote:
>
>> On Sun, Jan 24, 2010 at 9:15 AM, Gijs <in...@bs...> wrote:
>>
>>> On 1/24/10 12:06 , Nils Sudmann wrote:
>>> > Hmm,
>>> >
>>> > I checked some versions and here is what I found:
>>> >
>>> > Vista - PyOpenGL 3.0.1b2, GL_VERSION = 1.1.0 (!!!)
>>> > Fedora 11 - PyOpenGL 3.0.0, GL_VERSION = None (!!!)
>>> >
>>> > Suse 11 - At work, need to check this tomorrow.
>>> >
>>> > About vista, the GL_VERSION string seems odd. I tried a OpenGL
>>> > extension viewer that reports OpenGL version 3.2. Again, I'm clueless
>>> > to why PyOpenGL thinks it is dealing with a 1.1 driver.
>>> >
>>> > My Fedora server has a ATI X800 card, and AFAIK AMD/ATI has dropped
>>> > support for "older" cards on newer kernels (ATI is on my do not buy
>>> > list). But I managed to get it working somehow, at least glxinfo
>>> > reports that everything is ok (OpenGL version string: 2.1 Mesa
>>> > 7.6-devel). I did download and upgrade PyOpenGL to 3.0.1b2, but it
>>> > still reports a GL_VERSION of None.
>>> >
>>> > So it seems that on both affected systems, there is something wrong
>>> > with my GL setup.
>>> Well, the problem on Fedora is that you are using the mesa driver. This
>>> does some basic GL stuff but don't expect it do anything more than
>>> render some polygons. You'll need to opensource ATI driver which gives
>>> you more GL functions, or you could try out the driver of ATI. About
>>> Windows, the OpenGL version 1.1.0 has something to do with the version
>>> reported back by the OpenGL library itself. This will never report any
>>> higher than 1.1.0 I think. You'd probably get a better idea as to why
>>> this happens when you google for it.
>>>
>>> You might have better luck trying out the ARB functions (glGenBuffersARB
>>> and glBindBufferARB). These should work if your OpenGL installation is
>>> good.
>>>
>>>
>> I agree with Gijs. As far as mesa goes, it's just an OpenGL-like API which
>> doesn't usually provide hardware rendering support. VBO's may well be out of
>> its league. You are going to need the ATI driver here.
>>
>> Regarding Windows reporting 1.1, it's not that weird. I've had NVIDIA
>> drivers reporting up to OpenGL 2.0, but usually Windows does not provide
>> functionality beyond 1.1 without the use of extensions.
>>
>> As Gijs said, try using the glGenBuffersARB extension instead of
>> glGenBuffers (I think it's under the OpenGL.ext package).
>>
>> Let us know how it goes ;)
>>
>> Alejandro.-
>>
>>
>>
>>> Regards, Gijs
>>>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>> Throughout its 18-year history, RSA Conference consistently attracts the
>>> world's best and brightest in the field, creating opportunities for
>>> Conference
>>> attendees to learn about information security's most important issues
>>> through
>>> interactions with peers, luminaries and emerging and established
>>> companies.
>>> http://p.sf.net/sfu/rsaconf-dev2dev
>>> _______________________________________________
>>> PyOpenGL Homepage
>>> http://pyopengl.sourceforge.net
>>> _______________________________________________
>>> PyOpenGL-Users mailing list
>>> PyO...@li...
>>> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>>>
>>
>>
>
>
> --
> If Atheism is a religion, then not collecting stamps is a hobby.
>



-- 
If Atheism is a religion, then not collecting stamps is a hobby.

Re: [PyOpenGL-Users] glumpy, a fast-OpenGL based numpy visualization

[Nils S. <su...@gm...>]

Hi,

This is very interesting to me, but do I have to download each individual
file at http://glumpy.googlecode.com/hg/ (glumpy) since there are no files
in downloads at http://code.google.com/p/glumpy/downloads/list ?
I could always use wget, but surly this is not what you intended?

This is interesting since I have used IDL (
http://en.wikipedia.org/wiki/IDL_%28programming_language%29) a bit at work,
but the licenses are a bitch.

Good work.

On Mon, Jan 25, 2010 at 12:20 PM, Nicolas Rougier
<Nic...@lo...>wrote:

>
>
> Hello,
>
> glumpy is a fast-OpenGL based numpy visualization based on top of
> PyOpenGL and IPython (for interactive sessions) that allows for the fast
> vizualization of numpy arrays (mainly two dimensional). It had been
> designed with efficiency in mind and if you want to have a sense of
> what’s going on in your simulation while it is running, then maybe
> glumpy can help you.
>
> Sources: hg clone http://glumpy.googlecode.com/hg/ glumpy
> No installation required, you can run all demos inplace.
>
> Homepage: http://code.google.com/p/glumpy/
>
>
> Nicolas
>
>
>
> ------------------------------------------------------------------------------
> Throughout its 18-year history, RSA Conference consistently attracts the
> world's best and brightest in the field, creating opportunities for
> Conference
> attendees to learn about information security's most important issues
> through
> interactions with peers, luminaries and emerging and established companies.
> http://p.sf.net/sfu/rsaconf-dev2dev
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>



-- 
If Atheism is a religion, then not collecting stamps is a hobby.

[PyOpenGL-Users] glumpy, a fast-OpenGL based numpy visualization

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

Hello,

glumpy is a fast-OpenGL based numpy visualization based on top of
PyOpenGL and IPython (for interactive sessions) that allows for the fast
vizualization of numpy arrays (mainly two dimensional). It had been
designed with efficiency in mind and if you want to have a sense of
what’s going on in your simulation while it is running, then maybe
glumpy can help you. 

Sources: hg clone http://glumpy.googlecode.com/hg/ glumpy
No installation required, you can run all demos inplace.

Homepage: http://code.google.com/p/glumpy/


Nicolas

Re: [PyOpenGL-Users] Vista, PyOpengl 3.0.1b2 and VBO's

[Nils S. <su...@gm...>]

Found the faulty code.

I was using wxPython GLCanvas and specified WX_GL_DOUBLEBUFFER. After
rewriting the code to use old vertex arrays, it kind of worked, but a lot of
other stuff was strange. It seems that WX_GL_DOUBLEBUFFER caused GL_VERSION
to report 1.1.0 and probably disabled all the buffer object functionality
and other stuff. Removing the doublebuffer option caused GL_VERSION to
report 3.2.0 and everything worked!

Again thanks for all the help.


On Sun, Jan 24, 2010 at 3:01 PM, Alejandro Segovia <as...@gm...>wrote:

> On Sun, Jan 24, 2010 at 9:15 AM, Gijs <in...@bs...> wrote:
>
>> On 1/24/10 12:06 , Nils Sudmann wrote:
>> > Hmm,
>> >
>> > I checked some versions and here is what I found:
>> >
>> > Vista - PyOpenGL 3.0.1b2, GL_VERSION = 1.1.0 (!!!)
>> > Fedora 11 - PyOpenGL 3.0.0, GL_VERSION = None (!!!)
>> >
>> > Suse 11 - At work, need to check this tomorrow.
>> >
>> > About vista, the GL_VERSION string seems odd. I tried a OpenGL
>> > extension viewer that reports OpenGL version 3.2. Again, I'm clueless
>> > to why PyOpenGL thinks it is dealing with a 1.1 driver.
>> >
>> > My Fedora server has a ATI X800 card, and AFAIK AMD/ATI has dropped
>> > support for "older" cards on newer kernels (ATI is on my do not buy
>> > list). But I managed to get it working somehow, at least glxinfo
>> > reports that everything is ok (OpenGL version string: 2.1 Mesa
>> > 7.6-devel). I did download and upgrade PyOpenGL to 3.0.1b2, but it
>> > still reports a GL_VERSION of None.
>> >
>> > So it seems that on both affected systems, there is something wrong
>> > with my GL setup.
>> Well, the problem on Fedora is that you are using the mesa driver. This
>> does some basic GL stuff but don't expect it do anything more than
>> render some polygons. You'll need to opensource ATI driver which gives
>> you more GL functions, or you could try out the driver of ATI. About
>> Windows, the OpenGL version 1.1.0 has something to do with the version
>> reported back by the OpenGL library itself. This will never report any
>> higher than 1.1.0 I think. You'd probably get a better idea as to why
>> this happens when you google for it.
>>
>> You might have better luck trying out the ARB functions (glGenBuffersARB
>> and glBindBufferARB). These should work if your OpenGL installation is
>> good.
>>
>>
> I agree with Gijs. As far as mesa goes, it's just an OpenGL-like API which
> doesn't usually provide hardware rendering support. VBO's may well be out of
> its league. You are going to need the ATI driver here.
>
> Regarding Windows reporting 1.1, it's not that weird. I've had NVIDIA
> drivers reporting up to OpenGL 2.0, but usually Windows does not provide
> functionality beyond 1.1 without the use of extensions.
>
> As Gijs said, try using the glGenBuffersARB extension instead of
> glGenBuffers (I think it's under the OpenGL.ext package).
>
> Let us know how it goes ;)
>
> Alejandro.-
>
>
>
>> Regards, Gijs
>>
>>
>> ------------------------------------------------------------------------------
>>
>> Throughout its 18-year history, RSA Conference consistently attracts the
>> world's best and brightest in the field, creating opportunities for
>> Conference
>> attendees to learn about information security's most important issues
>> through
>> interactions with peers, luminaries and emerging and established
>> companies.
>> http://p.sf.net/sfu/rsaconf-dev2dev
>> _______________________________________________
>> PyOpenGL Homepage
>> http://pyopengl.sourceforge.net
>> _______________________________________________
>> PyOpenGL-Users mailing list
>> PyO...@li...
>> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>>
>
>


-- 
If Atheism is a religion, then not collecting stamps is a hobby.

Re: [PyOpenGL-Users] Vista, PyOpengl 3.0.1b2 and VBO's

[Nils S. <su...@gm...>]

Thanks for all the input.

So I've decided to try glGenBuffers(ARB) and glBindBuffer(ARB) myself and
putting my fedora ATI driver problem at hold for now. Alas, on vista,
glGenBuffersARB is not defined (there is no OpenGL.ext module) and
glGenBuffers gives me a OpenGL.error.NullFunctionError.

I'll try to get the ATI card working in the next days, meanwhile I'll just
add another code path that uses the old vertex arrays.

Thanks again,
Nils

On Sun, Jan 24, 2010 at 3:01 PM, Alejandro Segovia <as...@gm...>wrote:

> On Sun, Jan 24, 2010 at 9:15 AM, Gijs <in...@bs...> wrote:
>
>> On 1/24/10 12:06 , Nils Sudmann wrote:
>> > Hmm,
>> >
>> > I checked some versions and here is what I found:
>> >
>> > Vista - PyOpenGL 3.0.1b2, GL_VERSION = 1.1.0 (!!!)
>> > Fedora 11 - PyOpenGL 3.0.0, GL_VERSION = None (!!!)
>> >
>> > Suse 11 - At work, need to check this tomorrow.
>> >
>> > About vista, the GL_VERSION string seems odd. I tried a OpenGL
>> > extension viewer that reports OpenGL version 3.2. Again, I'm clueless
>> > to why PyOpenGL thinks it is dealing with a 1.1 driver.
>> >
>> > My Fedora server has a ATI X800 card, and AFAIK AMD/ATI has dropped
>> > support for "older" cards on newer kernels (ATI is on my do not buy
>> > list). But I managed to get it working somehow, at least glxinfo
>> > reports that everything is ok (OpenGL version string: 2.1 Mesa
>> > 7.6-devel). I did download and upgrade PyOpenGL to 3.0.1b2, but it
>> > still reports a GL_VERSION of None.
>> >
>> > So it seems that on both affected systems, there is something wrong
>> > with my GL setup.
>> Well, the problem on Fedora is that you are using the mesa driver. This
>> does some basic GL stuff but don't expect it do anything more than
>> render some polygons. You'll need to opensource ATI driver which gives
>> you more GL functions, or you could try out the driver of ATI. About
>> Windows, the OpenGL version 1.1.0 has something to do with the version
>> reported back by the OpenGL library itself. This will never report any
>> higher than 1.1.0 I think. You'd probably get a better idea as to why
>> this happens when you google for it.
>>
>> You might have better luck trying out the ARB functions (glGenBuffersARB
>> and glBindBufferARB). These should work if your OpenGL installation is
>> good.
>>
>>
> I agree with Gijs. As far as mesa goes, it's just an OpenGL-like API which
> doesn't usually provide hardware rendering support. VBO's may well be out of
> its league. You are going to need the ATI driver here.
>
> Regarding Windows reporting 1.1, it's not that weird. I've had NVIDIA
> drivers reporting up to OpenGL 2.0, but usually Windows does not provide
> functionality beyond 1.1 without the use of extensions.
>
> As Gijs said, try using the glGenBuffersARB extension instead of
> glGenBuffers (I think it's under the OpenGL.ext package).
>
> Let us know how it goes ;)
>
> Alejandro.-
>
>
>
>> Regards, Gijs
>>
>>
>> ------------------------------------------------------------------------------
>>
>> Throughout its 18-year history, RSA Conference consistently attracts the
>> world's best and brightest in the field, creating opportunities for
>> Conference
>> attendees to learn about information security's most important issues
>> through
>> interactions with peers, luminaries and emerging and established
>> companies.
>> http://p.sf.net/sfu/rsaconf-dev2dev
>> _______________________________________________
>> PyOpenGL Homepage
>> http://pyopengl.sourceforge.net
>> _______________________________________________
>> PyOpenGL-Users mailing list
>> PyO...@li...
>> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>>
>
>


-- 
If Atheism is a religion, then not collecting stamps is a hobby.

Re: [PyOpenGL-Users] Vista, PyOpengl 3.0.1b2 and VBO's

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

On Sun, Jan 24, 2010 at 9:15 AM, Gijs <in...@bs...> wrote:

> On 1/24/10 12:06 , Nils Sudmann wrote:
> > Hmm,
> >
> > I checked some versions and here is what I found:
> >
> > Vista - PyOpenGL 3.0.1b2, GL_VERSION = 1.1.0 (!!!)
> > Fedora 11 - PyOpenGL 3.0.0, GL_VERSION = None (!!!)
> >
> > Suse 11 - At work, need to check this tomorrow.
> >
> > About vista, the GL_VERSION string seems odd. I tried a OpenGL
> > extension viewer that reports OpenGL version 3.2. Again, I'm clueless
> > to why PyOpenGL thinks it is dealing with a 1.1 driver.
> >
> > My Fedora server has a ATI X800 card, and AFAIK AMD/ATI has dropped
> > support for "older" cards on newer kernels (ATI is on my do not buy
> > list). But I managed to get it working somehow, at least glxinfo
> > reports that everything is ok (OpenGL version string: 2.1 Mesa
> > 7.6-devel). I did download and upgrade PyOpenGL to 3.0.1b2, but it
> > still reports a GL_VERSION of None.
> >
> > So it seems that on both affected systems, there is something wrong
> > with my GL setup.
> Well, the problem on Fedora is that you are using the mesa driver. This
> does some basic GL stuff but don't expect it do anything more than
> render some polygons. You'll need to opensource ATI driver which gives
> you more GL functions, or you could try out the driver of ATI. About
> Windows, the OpenGL version 1.1.0 has something to do with the version
> reported back by the OpenGL library itself. This will never report any
> higher than 1.1.0 I think. You'd probably get a better idea as to why
> this happens when you google for it.
>
> You might have better luck trying out the ARB functions (glGenBuffersARB
> and glBindBufferARB). These should work if your OpenGL installation is
> good.
>
>
I agree with Gijs. As far as mesa goes, it's just an OpenGL-like API which
doesn't usually provide hardware rendering support. VBO's may well be out of
its league. You are going to need the ATI driver here.

Regarding Windows reporting 1.1, it's not that weird. I've had NVIDIA
drivers reporting up to OpenGL 2.0, but usually Windows does not provide
functionality beyond 1.1 without the use of extensions.

As Gijs said, try using the glGenBuffersARB extension instead of
glGenBuffers (I think it's under the OpenGL.ext package).

Let us know how it goes ;)

Alejandro.-



> Regards, Gijs
>
>
> ------------------------------------------------------------------------------
> Throughout its 18-year history, RSA Conference consistently attracts the
> world's best and brightest in the field, creating opportunities for
> Conference
> attendees to learn about information security's most important issues
> through
> interactions with peers, luminaries and emerging and established companies.
> http://p.sf.net/sfu/rsaconf-dev2dev
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>

Re: [PyOpenGL-Users] Vista, PyOpengl 3.0.1b2 and VBO's

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

On 1/24/10 12:06 , Nils Sudmann wrote:
> Hmm,
>
> I checked some versions and here is what I found:
>
> Vista - PyOpenGL 3.0.1b2, GL_VERSION = 1.1.0 (!!!)
> Fedora 11 - PyOpenGL 3.0.0, GL_VERSION = None (!!!)
>
> Suse 11 - At work, need to check this tomorrow.
>
> About vista, the GL_VERSION string seems odd. I tried a OpenGL 
> extension viewer that reports OpenGL version 3.2. Again, I'm clueless 
> to why PyOpenGL thinks it is dealing with a 1.1 driver.
>
> My Fedora server has a ATI X800 card, and AFAIK AMD/ATI has dropped 
> support for "older" cards on newer kernels (ATI is on my do not buy 
> list). But I managed to get it working somehow, at least glxinfo 
> reports that everything is ok (OpenGL version string: 2.1 Mesa 
> 7.6-devel). I did download and upgrade PyOpenGL to 3.0.1b2, but it 
> still reports a GL_VERSION of None.
>
> So it seems that on both affected systems, there is something wrong 
> with my GL setup.
Well, the problem on Fedora is that you are using the mesa driver. This 
does some basic GL stuff but don't expect it do anything more than 
render some polygons. You'll need to opensource ATI driver which gives 
you more GL functions, or you could try out the driver of ATI. About 
Windows, the OpenGL version 1.1.0 has something to do with the version 
reported back by the OpenGL library itself. This will never report any 
higher than 1.1.0 I think. You'd probably get a better idea as to why 
this happens when you google for it.

You might have better luck trying out the ARB functions (glGenBuffersARB 
and glBindBufferARB). These should work if your OpenGL installation is good.

Regards, Gijs

Re: [PyOpenGL-Users] Vista, PyOpengl 3.0.1b2 and VBO's

[Nils S. <su...@gm...>]

Hmm,

I checked some versions and here is what I found:

Vista - PyOpenGL 3.0.1b2, GL_VERSION = 1.1.0 (!!!)
Fedora 11 - PyOpenGL 3.0.0, GL_VERSION = None (!!!)

Suse 11 - At work, need to check this tomorrow.

About vista, the GL_VERSION string seems odd. I tried a OpenGL extension
viewer that reports OpenGL version 3.2. Again, I'm clueless to why PyOpenGL
thinks it is dealing with a 1.1 driver.

My Fedora server has a ATI X800 card, and AFAIK AMD/ATI has dropped support
for "older" cards on newer kernels (ATI is on my do not buy list). But I
managed to get it working somehow, at least glxinfo reports that everything
is ok (OpenGL version string: 2.1 Mesa 7.6-devel). I did download and
upgrade PyOpenGL to 3.0.1b2, but it still reports a GL_VERSION of None.

So it seems that on both affected systems, there is something wrong with my
GL setup.

Ian Mallett asked for some example data that fails, dunno if it helps but
initially it is just a regular icosahedron.
        tao=(1.0+math.sqrt(5.0))/2
        icos = np.array([
            [1,tao,0],[-1,tao,0],[0,1,tao],
            [-1,tao,0],[-tao,0,1],[0,1,tao],
            [0,1,tao],[-tao,0,1],[0,-1,tao],
            [0,-1,tao],[-tao,0,1],[-1,-tao,0],
            [1,-tao,0],[-1,-tao,0],[0,-1,-tao],
            [-1,-tao,0],[1,-tao,0],[0,-1,tao],
            [0,-1,-tao],[tao,0,-1],[1,-tao,0],
            [1,tao,0],[tao,0,1],[tao,0,-1],
            [1,tao,0],[0,1,tao],[tao,0,1],
            [tao,0,1],[1,-tao,0],[tao,0,-1],
            [tao,0,1],[0,1,tao],[0,-1,tao],
            [tao,0,1],[0,-1,tao],[1,-tao,0],
            [-1,tao,0],[1,tao,0],[0,1,-tao],
            [-tao,0,-1],[-1,tao,0],[0,1,-tao],
            [-1,-tao,0],[-tao,0,1],[-tao,0,-1],
            [0,1,-tao],[tao,0,-1],[0,-1,-tao],
            [-1,-tao,0],[-tao,0,-1],[0,-1,-tao],
            [-tao,0,-1],[0,1,-tao],[0,-1,-tao],
            [0,1,-tao],[1,tao,0],[tao,0,-1],
            [-tao,0,1],[-1,tao,0],[-tao,0,-1]
            ], dtype=np.float32);

Thanks for your help, I appreciate it.

On Sun, Jan 24, 2010 at 4:21 AM, Alejandro Segovia <as...@gm...>wrote:

> Hi Nils,
>
> I'm sorry to hear it's putting you through so much trouble.
>
> On Sat, Jan 23, 2010 at 10:59 PM, Nils Sudmann <su...@gm...> wrote:
>
>> I've had the chance to test some more.
>>
>> I tried calling glGenBuffers, glBindBuffer myself without using the VBO
>> class, but it produces the same error (OpenGL.error.
>> NullFunctionError: Attempt to call an undefined function). I've tried the
>> code on yet another setup (redhat 11) and it has the same problems.
>>
>> Summary:
>> Suse 11/Nvidia - works
>> Vista/Nvidia - doesn't work
>> Redhat 11/ATI - same as vista.
>>
>> I am totally stumped.
>
>
> What versions of PyOpenGL are you using? Are you always using 3.0.1 beta
> and compiling it from source yourself? If so, then the difference between
> the configurations under which it works and the ones under which it doesn't
> could be due to different OpenGL capabilities on each machine.
>
> Could you check the OpenGL version on all three machine configurations
> (just use glGetString(GL_VERSION)) and paste them here?
>
> Best regards,
> Alejandro.-
>
> PS: I'm copying back to the list so if anyone has come across this issue
> before, he or she might be able to help.
>
>
>>
>>
>>
>> On Thu, Jan 21, 2010 at 1:41 PM, Alejandro Segovia <as...@gm...>wrote:
>>
>>> Hi Nils,
>>>
>>> On Thu, Jan 21, 2010 at 7:23 AM, Nils Sudmann <su...@gm...> wrote:
>>>
>>>> Hi Alejandro
>>>>
>>>> Thanks for the input, but it is not my code that generates the error.
>>>> It is the vbo class from PyOpenGL. Let me illustrate:
>>>>
>>>> icos = np.array([...], dtype=np.float32)
>>>> v=vbo.VBO(icos, usage='GL_STATIC_DRAW')
>>>> glEnableClientState(GL_VERTEX_ARRAY)
>>>> v.bind()
>>>> glVertexPointer (3, GL_FLOAT, 0, v)
>>>> glDrawArrays (GL_TRIANGLES, 0, 60)
>>>>
>>>> Here v.bind() fails.
>>>>
>>>> It doesn't seem right to modify the vbo class.
>>>
>>>
>>> I see what you mean. In my case, I was just using plain OpenGL calls from
>>> within a custom VBO class, this provided me with the flexibility to have
>>> some fallbacks in place if some of the calls fail.
>>>
>>> The stock OpenGL.arrays.vbo.VBO class seems to be working correctly on my
>>> Mac. Have you tried creating and binding a VBO "manually"? Does it seem to
>>> work?
>>>
>>> Alejandro.-
>>>
>>>
>>>>
>>>>
>>>> On Wed, Jan 20, 2010 at 10:59 PM, Alejandro Segovia <as...@gm...>wrote:
>>>>
>>>>>
>>>>> Hi Nils,
>>>>>
>>>>> I ran into the same issue when porting VBO code from Linux to Mac. In
>>>>> my case, the problem was that the function's signature was different
>>>>> on both versions: on Linux it received two parameters (one was an
>>>>> "out" value where to place the new newly created buffer's reference)
>>>>> whereas on Mac it just received the number of buffers to create and
>>>>> returned the reference(s) by means of "return".
>>>>>
>>>>> In order to keep my code portable I surrounded the call in a
>>>>> try...except block and fall back to the other call.
>>>>>
>>>>> Hope this helps.
>>>>>
>>>>> Best regards,
>>>>> Alejandro.-
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>> On Jan 20, 2010, at 6:03 PM, Nils Sudmann <su...@gm...> wrote:
>>>>>
>>>>> > Hi, just installed Python 2.6 and PyOpengl 3.0.1b2 on a Vista
>>>>> machine.
>>>>> > However, a very simple test program that uses VBO's (and not much
>>>>> > else) fails on Vista, but works like a charm on my linux box.
>>>>> > This is what it tells me:
>>>>> >
>>>>> > OpenGL.error.NullFunctionError: Attempt to call an undefined
>>>>> > function glGenBuffersARB, check for bool(glGenBuffersARB) before
>>>>> > calling
>>>>> > Traceback (most recent call last):
>>>>> >   File "test.py", line 50, in OnPaint
>>>>> >     v.bind()
>>>>> >   File "C:\Program Files\Python26\lib\site-packages\OpenGL\arrays
>>>>> > \vbo.py", line 217, in bind
>>>>> >     buffers = self.create_buffers()
>>>>> >
>>>>> > I tried setting
>>>>> > OpenGL.FORWARD_COMPATIBLE_ONLY = False
>>>>> > but I guess my opengl drivers for vista have dropped legacy support
>>>>> > altogether (the card is a GTX275).
>>>>> >
>>>>> > Any ideas?
>>>>> > --
>>>>> > If Atheism is a religion, then not collecting stamps is a hobby.
>>>>> > ---
>>>>> > ---
>>>>> > ---
>>>>> > ---------------------------------------------------------------------
>>>>> > Throughout its 18-year history, RSA Conference consistently attracts
>>>>> > the
>>>>> > world's best and brightest in the field, creating opportunities for
>>>>> > Conference
>>>>> > attendees to learn about information security's most important
>>>>> > issues through
>>>>> > interactions with peers, luminaries and emerging and established
>>>>> > companies.
>>>>> > http://p.sf.net/sfu/rsaconf-dev2dev
>>>>> > _______________________________________________
>>>>> > PyOpenGL Homepage
>>>>> > http://pyopengl.sourceforge.net
>>>>> > _______________________________________________
>>>>> > PyOpenGL-Users mailing list
>>>>> > PyO...@li...
>>>>> > https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Throughout its 18-year history, RSA Conference consistently attracts
>>>>> the
>>>>> world's best and brightest in the field, creating opportunities for
>>>>> Conference
>>>>> attendees to learn about information security's most important issues
>>>>> through
>>>>> interactions with peers, luminaries and emerging and established
>>>>> companies.
>>>>> http://p.sf.net/sfu/rsaconf-dev2dev
>>>>> _______________________________________________
>>>>> PyOpenGL Homepage
>>>>> http://pyopengl.sourceforge.net
>>>>> _______________________________________________
>>>>> PyOpenGL-Users mailing list
>>>>> PyO...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> If Atheism is a religion, then not collecting stamps is a hobby.
>>>>
>>>
>>>
>>
>>
>> --
>> If Atheism is a religion, then not collecting stamps is a hobby.
>>
>
>


-- 
If Atheism is a religion, then not collecting stamps is a hobby.

Re: [PyOpenGL-Users] Vista, PyOpengl 3.0.1b2 and VBO's

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

On Thu, Jan 21, 2010 at 7:23 AM, Nils Sudmann <su...@gm...> wrote:

> icos = np.array([...], dtype=np.float32)
>>>
>>> Could we have some simple example data that fails?

Re: [PyOpenGL-Users] Vista, PyOpengl 3.0.1b2 and VBO's

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

Hi Nils,

I'm sorry to hear it's putting you through so much trouble.

On Sat, Jan 23, 2010 at 10:59 PM, Nils Sudmann <su...@gm...> wrote:

> I've had the chance to test some more.
>
> I tried calling glGenBuffers, glBindBuffer myself without using the VBO
> class, but it produces the same error (OpenGL.error.
> NullFunctionError: Attempt to call an undefined function). I've tried the
> code on yet another setup (redhat 11) and it has the same problems.
>
> Summary:
> Suse 11/Nvidia - works
> Vista/Nvidia - doesn't work
> Redhat 11/ATI - same as vista.
>
> I am totally stumped.


What versions of PyOpenGL are you using? Are you always using 3.0.1 beta and
compiling it from source yourself? If so, then the difference between the
configurations under which it works and the ones under which it doesn't
could be due to different OpenGL capabilities on each machine.

Could you check the OpenGL version on all three machine configurations (just
use glGetString(GL_VERSION)) and paste them here?

Best regards,
Alejandro.-

PS: I'm copying back to the list so if anyone has come across this issue
before, he or she might be able to help.


>
>
>
> On Thu, Jan 21, 2010 at 1:41 PM, Alejandro Segovia <as...@gm...>wrote:
>
>> Hi Nils,
>>
>> On Thu, Jan 21, 2010 at 7:23 AM, Nils Sudmann <su...@gm...> wrote:
>>
>>> Hi Alejandro
>>>
>>> Thanks for the input, but it is not my code that generates the error.
>>> It is the vbo class from PyOpenGL. Let me illustrate:
>>>
>>> icos = np.array([...], dtype=np.float32)
>>> v=vbo.VBO(icos, usage='GL_STATIC_DRAW')
>>> glEnableClientState(GL_VERTEX_ARRAY)
>>> v.bind()
>>> glVertexPointer (3, GL_FLOAT, 0, v)
>>> glDrawArrays (GL_TRIANGLES, 0, 60)
>>>
>>> Here v.bind() fails.
>>>
>>> It doesn't seem right to modify the vbo class.
>>
>>
>> I see what you mean. In my case, I was just using plain OpenGL calls from
>> within a custom VBO class, this provided me with the flexibility to have
>> some fallbacks in place if some of the calls fail.
>>
>> The stock OpenGL.arrays.vbo.VBO class seems to be working correctly on my
>> Mac. Have you tried creating and binding a VBO "manually"? Does it seem to
>> work?
>>
>> Alejandro.-
>>
>>
>>>
>>>
>>> On Wed, Jan 20, 2010 at 10:59 PM, Alejandro Segovia <as...@gm...>wrote:
>>>
>>>>
>>>> Hi Nils,
>>>>
>>>> I ran into the same issue when porting VBO code from Linux to Mac. In
>>>> my case, the problem was that the function's signature was different
>>>> on both versions: on Linux it received two parameters (one was an
>>>> "out" value where to place the new newly created buffer's reference)
>>>> whereas on Mac it just received the number of buffers to create and
>>>> returned the reference(s) by means of "return".
>>>>
>>>> In order to keep my code portable I surrounded the call in a
>>>> try...except block and fall back to the other call.
>>>>
>>>> Hope this helps.
>>>>
>>>> Best regards,
>>>> Alejandro.-
>>>>
>>>> Sent from my iPhone
>>>>
>>>> On Jan 20, 2010, at 6:03 PM, Nils Sudmann <su...@gm...> wrote:
>>>>
>>>> > Hi, just installed Python 2.6 and PyOpengl 3.0.1b2 on a Vista machine.
>>>> > However, a very simple test program that uses VBO's (and not much
>>>> > else) fails on Vista, but works like a charm on my linux box.
>>>> > This is what it tells me:
>>>> >
>>>> > OpenGL.error.NullFunctionError: Attempt to call an undefined
>>>> > function glGenBuffersARB, check for bool(glGenBuffersARB) before
>>>> > calling
>>>> > Traceback (most recent call last):
>>>> >   File "test.py", line 50, in OnPaint
>>>> >     v.bind()
>>>> >   File "C:\Program Files\Python26\lib\site-packages\OpenGL\arrays
>>>> > \vbo.py", line 217, in bind
>>>> >     buffers = self.create_buffers()
>>>> >
>>>> > I tried setting
>>>> > OpenGL.FORWARD_COMPATIBLE_ONLY = False
>>>> > but I guess my opengl drivers for vista have dropped legacy support
>>>> > altogether (the card is a GTX275).
>>>> >
>>>> > Any ideas?
>>>> > --
>>>> > If Atheism is a religion, then not collecting stamps is a hobby.
>>>> > ---
>>>> > ---
>>>> > ---
>>>> > ---------------------------------------------------------------------
>>>> > Throughout its 18-year history, RSA Conference consistently attracts
>>>> > the
>>>> > world's best and brightest in the field, creating opportunities for
>>>> > Conference
>>>> > attendees to learn about information security's most important
>>>> > issues through
>>>> > interactions with peers, luminaries and emerging and established
>>>> > companies.
>>>> > http://p.sf.net/sfu/rsaconf-dev2dev
>>>> > _______________________________________________
>>>> > PyOpenGL Homepage
>>>> > http://pyopengl.sourceforge.net
>>>> > _______________________________________________
>>>> > PyOpenGL-Users mailing list
>>>> > PyO...@li...
>>>> > https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Throughout its 18-year history, RSA Conference consistently attracts the
>>>> world's best and brightest in the field, creating opportunities for
>>>> Conference
>>>> attendees to learn about information security's most important issues
>>>> through
>>>> interactions with peers, luminaries and emerging and established
>>>> companies.
>>>> http://p.sf.net/sfu/rsaconf-dev2dev
>>>> _______________________________________________
>>>> PyOpenGL Homepage
>>>> http://pyopengl.sourceforge.net
>>>> _______________________________________________
>>>> PyOpenGL-Users mailing list
>>>> PyO...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>>>>
>>>
>>>
>>>
>>> --
>>> If Atheism is a religion, then not collecting stamps is a hobby.
>>>
>>
>>
>
>
> --
> If Atheism is a religion, then not collecting stamps is a hobby.
>

Re: [PyOpenGL-Users] offscreen rendering problem with glInitFramebufferObjectEXT

[Revaz Y. <yve...@ep...>]

Ok, I've found nice solutions to my problem:

- with glut, to avoid to display a window simply use glutHideWindow :-[ :

glutCreateWindow("my window")
glutHideWindow()

- simple and good examples about offscreen rendering using FrameBuffer 
and Renderbuffer can be found here:

http://www.opengl.org/wiki/GL_EXT_framebuffer_object

Cheers,

yves



Dan Helfman wrote:
> Revaz Yves wrote:
>   
>>> The only time I've used the FBO extension is when I've got an OpenGL 
>>> window open, e.g. for rendering a separate pick buffer so I can tell 
>>> what the user clicks on. I don't know of a way to initialize GL 
>>> without a window, 
>>>       
>> ok, maybe it's not so important... however I expected to run backgound 
>> scripts...
>>     
>
> FYI:
>
> http://stackoverflow.com/questions/576896/can-you-create-opengl-context-without-opening-a-window
>
> Dan
>   


-- 
                                                 (o o)
--------------------------------------------oOO--(_)--OOo-------
  Yves Revaz
  Laboratory of Astrophysics EPFL
  Observatoire de Sauverny     Tel : ++ 41 22 379 24 28
  51. Ch. des Maillettes       Fax : ++ 41 22 379 22 05
  1290 Sauverny             e-mail : Yve...@ep...
  SWITZERLAND                  Web : http://www.lunix.ch/revaz/
----------------------------------------------------------------

Re: [PyOpenGL-Users] offscreen rendering problem with glInitFramebufferObjectEXT

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

Revaz Yves wrote:
> 
>>
>> The only time I've used the FBO extension is when I've got an OpenGL 
>> window open, e.g. for rendering a separate pick buffer so I can tell 
>> what the user clicks on. I don't know of a way to initialize GL 
>> without a window, 
> ok, maybe it's not so important... however I expected to run backgound 
> scripts...

FYI:

http://stackoverflow.com/questions/576896/can-you-create-opengl-context-without-opening-a-window

Dan

Re: [PyOpenGL-Users] offscreen rendering problem with glInitFramebufferObjectEXT

[Revaz Y. <yve...@ep...>]

>
> The only time I've used the FBO extension is when I've got an OpenGL 
> window open, e.g. for rendering a separate pick buffer so I can tell 
> what the user clicks on. I don't know of a way to initialize GL without 
> a window, 
ok, maybe it's not so important... however I expected to run backgound 
scripts...
> although it's certainly possible to initialize GL without 
> using GLUT. You can use wxPython's GLCanvas, for instance. But even 
> GLCanvas expects a parent window.
>   
sure,

well, anyway, thanks for your precious help.

yves
> Dan
>   


-- 
                                                 (o o)
--------------------------------------------oOO--(_)--OOo-------
  Yves Revaz
  Laboratory of Astrophysics EPFL
  Observatoire de Sauverny     Tel : ++ 41 22 379 24 28
  51. Ch. des Maillettes       Fax : ++ 41 22 379 22 05
  1290 Sauverny             e-mail : Yve...@ep...
  SWITZERLAND                  Web : http://www.lunix.ch/revaz/
----------------------------------------------------------------

Re: [PyOpenGL-Users] offscreen rendering problem with glInitFramebufferObjectEXT

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

Revaz Yves wrote:
> ok, fine ! now it works, after a
> 
> glutInitDisplayMode
> 
> which initialize OpenGL.
> But how can I initialize OpenGL without creating a window ?
> 
>> In general, I would recommend using the frame buffer object extension 
>> for off-screen rendering. 
> ok, so I'm on the right way.
> Any example will be welcome...

The only time I've used the FBO extension is when I've got an OpenGL 
window open, e.g. for rendering a separate pick buffer so I can tell 
what the user clicks on. I don't know of a way to initialize GL without 
a window, although it's certainly possible to initialize GL without 
using GLUT. You can use wxPython's GLCanvas, for instance. But even 
GLCanvas expects a parent window.

Dan

Re: [PyOpenGL-Users] offscreen rendering problem with glInitFramebufferObjectEXT

[Revaz Y. <yve...@ep...>]

Dan Helfman wrote:
> Revaz Yves wrote:
>   
>> Dear List,
>>
>> I would like to use off-screen rendering with PyOpenGL.
>> According to the few informations I found on the web, one method is
>> to use a FrameBufferObject.
>>
>> Unfortunately, when initializing a new FrameBuffer :
>>
>> from OpenGL.GL.EXT.framebuffer_object import *
>> glInitFramebufferObjectEXT()
>>
>> I get :
>>     
>
> [error snipped]
>
> Have you tried initializing PyOpenGL first?
>
> When I try running those two lines of code on a machine that I know has 
> the frame buffer object extension, without initial PyOpenGL first, I get 
> the same error message.
>   
ok, fine ! now it works, after a

glutInitDisplayMode

which initialize OpenGL.
But how can I initialize OpenGL without creating a window ?

> In general, I would recommend using the frame buffer object extension 
> for off-screen rendering. 
ok, so I'm on the right way.
Any example will be welcome...

Cheers,

yves
> There are older techniques like p-buffers, but 
> they're more difficult to use. One downside of frame buffer objects is 
> that some older/cheaper graphics chipset drivers do not support them.
>
> Dan
>   


-- 
                                                 (o o)
--------------------------------------------oOO--(_)--OOo-------
  Yves Revaz
  Laboratory of Astrophysics EPFL
  Observatoire de Sauverny     Tel : ++ 41 22 379 24 28
  51. Ch. des Maillettes       Fax : ++ 41 22 379 22 05
  1290 Sauverny             e-mail : Yve...@ep...
  SWITZERLAND                  Web : http://www.lunix.ch/revaz/
----------------------------------------------------------------

Re: [PyOpenGL-Users] offscreen rendering problem with glInitFramebufferObjectEXT

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

Revaz Yves wrote:
> Dear List,
> 
> I would like to use off-screen rendering with PyOpenGL.
> According to the few informations I found on the web, one method is
> to use a FrameBufferObject.
> 
> Unfortunately, when initializing a new FrameBuffer :
> 
> from OpenGL.GL.EXT.framebuffer_object import *
> glInitFramebufferObjectEXT()
> 
> I get :

[error snipped]

Have you tried initializing PyOpenGL first?

When I try running those two lines of code on a machine that I know has 
the frame buffer object extension, without initial PyOpenGL first, I get 
the same error message.

In general, I would recommend using the frame buffer object extension 
for off-screen rendering. There are older techniques like p-buffers, but 
they're more difficult to use. One downside of frame buffer objects is 
that some older/cheaper graphics chipset drivers do not support them.

Dan

[PyOpenGL-Users] offscreen rendering problem with glInitFramebufferObjectEXT

[Revaz Y. <yve...@ep...>]

Dear List,

I would like to use off-screen rendering with PyOpenGL.
According to the few informations I found on the web, one method is
to use a FrameBufferObject.

Unfortunately, when initializing a new FrameBuffer :

from OpenGL.GL.EXT.framebuffer_object import *
glInitFramebufferObjectEXT()

I get :

---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)

/home/revaz/<ipython console> in <module>()

/usr/lib/pymodules/python2.6/OpenGL/raw/GL/EXT/framebuffer_object.pyc in 
glInitFramebufferObjectEXT()
    
301                                                                                              

    
302                                                                                              

    303 def 
glInitFramebufferObjectEXT():                                                            

    304         '''Return boolean indicating whether this extension is 
available'''                 
--> 305         return extensions.hasGLExtension( EXTENSION_NAME 
)                                  

/usr/lib/pymodules/python2.6/OpenGL/extensions.py in 
hasGLExtension(specifier)
     32                 print 
AVAILABLE_GL_EXTENSIONS                        
     33                 if not 
AVAILABLE_GL_EXTENSIONS:                      
---> 34                         AVAILABLE_GL_EXTENSIONS[:] = 
glGetString( GL_EXTENSIONS ).split()
     35                 return specifier in 
AVAILABLE_GL_EXTENSIONS                             
     36                         

the problem here is that GL_EXTENSIONS is None !

I'm running linux/ubuntu 9.10, python2.6 and PyOpenGL 3.0.1b1

All other suggestions about using off-screen rendering with PyOpenGL
are welcome.

Cheers,

yves



-- 
                                                 (o o)
--------------------------------------------oOO--(_)--OOo-------
  Yves Revaz
  Laboratory of Astrophysics EPFL
  Observatoire de Sauverny     Tel : ++ 41 22 379 24 28
  51. Ch. des Maillettes       Fax : ++ 41 22 379 22 05
  1290 Sauverny             e-mail : Yve...@ep...
  SWITZERLAND                  Web : http://www.lunix.ch/revaz/
----------------------------------------------------------------

Re: [PyOpenGL-Users] Vista, PyOpengl 3.0.1b2 and VBO's

[Nils S. <su...@gm...>]

Hi Alejandro

Thanks for the input, but it is not my code that generates the error.
It is the vbo class from PyOpenGL. Let me illustrate:

icos = np.array([...], dtype=np.float32)
v=vbo.VBO(icos, usage='GL_STATIC_DRAW')
glEnableClientState(GL_VERTEX_ARRAY)
v.bind()
glVertexPointer (3, GL_FLOAT, 0, v)
glDrawArrays (GL_TRIANGLES, 0, 60)

Here v.bind() fails.

It doesn't seem right to modify the vbo class.

On Wed, Jan 20, 2010 at 10:59 PM, Alejandro Segovia <as...@gm...>wrote:

>
> Hi Nils,
>
> I ran into the same issue when porting VBO code from Linux to Mac. In
> my case, the problem was that the function's signature was different
> on both versions: on Linux it received two parameters (one was an
> "out" value where to place the new newly created buffer's reference)
> whereas on Mac it just received the number of buffers to create and
> returned the reference(s) by means of "return".
>
> In order to keep my code portable I surrounded the call in a
> try...except block and fall back to the other call.
>
> Hope this helps.
>
> Best regards,
> Alejandro.-
>
> Sent from my iPhone
>
> On Jan 20, 2010, at 6:03 PM, Nils Sudmann <su...@gm...> wrote:
>
> > Hi, just installed Python 2.6 and PyOpengl 3.0.1b2 on a Vista machine.
> > However, a very simple test program that uses VBO's (and not much
> > else) fails on Vista, but works like a charm on my linux box.
> > This is what it tells me:
> >
> > OpenGL.error.NullFunctionError: Attempt to call an undefined
> > function glGenBuffersARB, check for bool(glGenBuffersARB) before
> > calling
> > Traceback (most recent call last):
> >   File "test.py", line 50, in OnPaint
> >     v.bind()
> >   File "C:\Program Files\Python26\lib\site-packages\OpenGL\arrays
> > \vbo.py", line 217, in bind
> >     buffers = self.create_buffers()
> >
> > I tried setting
> > OpenGL.FORWARD_COMPATIBLE_ONLY = False
> > but I guess my opengl drivers for vista have dropped legacy support
> > altogether (the card is a GTX275).
> >
> > Any ideas?
> > --
> > If Atheism is a religion, then not collecting stamps is a hobby.
> > ---
> > ---
> > ---
> > ---------------------------------------------------------------------
> > Throughout its 18-year history, RSA Conference consistently attracts
> > the
> > world's best and brightest in the field, creating opportunities for
> > Conference
> > attendees to learn about information security's most important
> > issues through
> > interactions with peers, luminaries and emerging and established
> > companies.
> > http://p.sf.net/sfu/rsaconf-dev2dev
> > _______________________________________________
> > PyOpenGL Homepage
> > http://pyopengl.sourceforge.net
> > _______________________________________________
> > PyOpenGL-Users mailing list
> > PyO...@li...
> > https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>
>
> ------------------------------------------------------------------------------
> Throughout its 18-year history, RSA Conference consistently attracts the
> world's best and brightest in the field, creating opportunities for
> Conference
> attendees to learn about information security's most important issues
> through
> interactions with peers, luminaries and emerging and established companies.
> http://p.sf.net/sfu/rsaconf-dev2dev
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>



-- 
If Atheism is a religion, then not collecting stamps is a hobby.

Re: [PyOpenGL-Users] Vista, PyOpengl 3.0.1b2 and VBO's

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

Hi Nils,

I ran into the same issue when porting VBO code from Linux to Mac. In  
my case, the problem was that the function's signature was different  
on both versions: on Linux it received two parameters (one was an  
"out" value where to place the new newly created buffer's reference)  
whereas on Mac it just received the number of buffers to create and  
returned the reference(s) by means of "return".

In order to keep my code portable I surrounded the call in a  
try...except block and fall back to the other call.

Hope this helps.

Best regards,
Alejandro.-

Sent from my iPhone

On Jan 20, 2010, at 6:03 PM, Nils Sudmann <su...@gm...> wrote:

> Hi, just installed Python 2.6 and PyOpengl 3.0.1b2 on a Vista machine.
> However, a very simple test program that uses VBO's (and not much  
> else) fails on Vista, but works like a charm on my linux box.
> This is what it tells me:
>
> OpenGL.error.NullFunctionError: Attempt to call an undefined  
> function glGenBuffersARB, check for bool(glGenBuffersARB) before  
> calling
> Traceback (most recent call last):
>   File "test.py", line 50, in OnPaint
>     v.bind()
>   File "C:\Program Files\Python26\lib\site-packages\OpenGL\arrays 
> \vbo.py", line 217, in bind
>     buffers = self.create_buffers()
>
> I tried setting
> OpenGL.FORWARD_COMPATIBLE_ONLY = False
> but I guess my opengl drivers for vista have dropped legacy support  
> altogether (the card is a GTX275).
>
> Any ideas?
> -- 
> If Atheism is a religion, then not collecting stamps is a hobby.
> --- 
> --- 
> --- 
> ---------------------------------------------------------------------
> Throughout its 18-year history, RSA Conference consistently attracts  
> the
> world's best and brightest in the field, creating opportunities for  
> Conference
> attendees to learn about information security's most important  
> issues through
> interactions with peers, luminaries and emerging and established  
> companies.
> http://p.sf.net/sfu/rsaconf-dev2dev
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users

[PyOpenGL-Users] Vista, PyOpengl 3.0.1b2 and VBO's

[Nils S. <su...@gm...>]

Hi, just installed Python 2.6 and PyOpengl 3.0.1b2 on a Vista machine.
However, a very simple test program that uses VBO's (and not much else)
fails on Vista, but works like a charm on my linux box.
This is what it tells me:

OpenGL.error.NullFunctionError: Attempt to call an undefined function
glGenBuffersARB, check for bool(glGenBuffersARB) before calling
Traceback (most recent call last):
  File "test.py", line 50, in OnPaint
    v.bind()
  File "C:\Program Files\Python26\lib\site-packages\OpenGL\arrays\vbo.py",
line 217, in bind
    buffers = self.create_buffers()

I tried setting
OpenGL.FORWARD_COMPATIBLE_ONLY = False
but I guess my opengl drivers for vista have dropped legacy support
altogether (the card is a GTX275).

Any ideas?
-- 
If Atheism is a religion, then not collecting stamps is a hobby.

Re: [PyOpenGL-Users] gl*Pointer() VBO offsets

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

Alejandro Segovia wrote:
> Hi
>
> I've been working with VBO's to speed up my rendering time. I have an  
> array loaded with vertex data up to the middle and from there to the  
> end loaded with color data, but I'm having trouble setting the  
> appropriate offset in the glColorPointer() call.
>
> I've tried several approaches but they either raise an exception or  
> draw nothing. The only thing that seems to work is using None (which  
> automatically gets converted to NULL).
>   
This will be because it was creating a 1-element array of integers (the
offset) and then attempting to draw from it (duh).

> Does anyone know what would the correct idiom be for converting from  
> an int into the offset "pointer" needed by PyOpenGL?
>   
You need a ctypes.c_void_p( offset ), or if you're using
OpenGL.arrays.vbo.VBO, you can just pass (your_vbo + offset) which
creates an object whose array-value is ctypes.c_void_p( offset ).  There
was a bug in a 3.0.0 release (I believe a beta) that prevented
interpreting the c_void_p( offset ) correctly.  If it doesn't work, you
may need to update to a 3.0.1 beta.

HTH,
Mike

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

[PyOpenGL-Users] gl*Pointer() VBO offsets

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

Hi

I've been working with VBO's to speed up my rendering time. I have an  
array loaded with vertex data up to the middle and from there to the  
end loaded with color data, but I'm having trouble setting the  
appropriate offset in the glColorPointer() call.

I've tried several approaches but they either raise an exception or  
draw nothing. The only thing that seems to work is using None (which  
automatically gets converted to NULL).

Does anyone know what would the correct idiom be for converting from  
an int into the offset "pointer" needed by PyOpenGL?

Thanks in advance,
Alejandro.-