Thread: [PyOpenGL-Users] Vista, PyOpengl 3.0.1b2 and VBO's
Brought to you by:
mcfletch
From: Nils S. <su...@gm...> - 2010-01-20 20:03:22
|
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. |
From: Alejandro S. <as...@gm...> - 2010-01-20 22:00:03
|
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 |
From: Nils S. <su...@gm...> - 2010-01-21 09:23:35
|
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. |
From: Alejandro S. <as...@gm...> - 2010-01-24 03:21:23
|
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. > |
From: Ian M. <geo...@gm...> - 2010-01-24 03:37:14
|
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? |
From: Nils S. <su...@gm...> - 2010-01-24 11:06:25
|
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. |
From: Gijs <in...@bs...> - 2010-01-24 11:15:25
|
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 |
From: Alejandro S. <as...@gm...> - 2010-01-24 14:02:04
|
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 > |
From: Nils S. <su...@gm...> - 2010-01-24 18:56:31
|
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. |
From: Nils S. <su...@gm...> - 2010-01-24 20:56:14
|
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. |
From: Nils S. <su...@gm...> - 2010-01-25 13:17:14
|
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. |