pyopengl-users — Discussion of all PyOpenGL matters.

Re: [PyOpenGL-Users] OSX - glutCheckLoop and glutWMCloseFunc

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

On 11-08-26 08:21 AM, Nicolas Rougier wrote:
>
>
> Hi everybody,
>
>
> While having a look at glut headers on OSX, I realized that there are
> a glutCheckLoop and a glutWMCloseFunc functions but they are not
> exported through OpenGL.GLUT.

glutWMCloseFunc *should* be available from the freeglut extensions by
default (IIUC it's actually a deprecated version of glutCloseFunc()). 
glutCheckLoop appears to be solving the same problem as FreeGLUT's
glutMainLoopEvent call, apparently from Rob Fletcher's GLUT patches. 
I've added it to the wrapper in an os-x specific module (it will
evaluate to bool(False) if the function is not defined, as with
everything else).

So, do you not see glutWMCloseFunc in OpenGL.GLUT ?  If you don't with
bzr head, then there's a bug somewhere.

    python -c "from OpenGL import GLUT; print GLUT.glutWMCloseFunc"

HTH,
Mike

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

Re: [PyOpenGL-Users] Tricky question on shader

[Almar K. <alm...@gm...>]

>
> For visvis, you might be interested in the different weight functions (I
> translated those of the antigrain library that are used in matplotlib):
>
> http://code.google.com/p/glumpy/source/browse/glumpy/image/filter.py
> http://code.google.com/p/glumpy/source/browse/glumpy/image/filter.vert
> http://code.google.com/p/glumpy/source/browse/glumpy/image/filter.frag
>

You're right, a Gaussian filter is probably not the best choice for aa. I
took a look at your filters and implemented a Lanczos filter (with dynamic
bandwith depending on image scale). Looks much better because it does not
blur so much. Thanks!

Almar

Re: [PyOpenGL-Users] Tricky question on shader

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

Thanks for the explanation. 
In fact, in the "real" implementation, I also used a texture lookup to store kernel values (see GPU gems 24) and read them when needed.
I was trying to normalize my kernel before storing it but your code is easier to use.

For visvis, you might be interested in the different weight functions (I translated those of the antigrain library that are used in matplotlib):

http://code.google.com/p/glumpy/source/browse/glumpy/image/filter.py
http://code.google.com/p/glumpy/source/browse/glumpy/image/filter.vert
http://code.google.com/p/glumpy/source/browse/glumpy/image/filter.frag


Thanks again, you made my day !

Nicolas

On Sep 3, 2011, at 22:27 , Almar Klein wrote:

> Hi,
>  
> I've been playing with gaussian texture filtering using shaders and I obtained a strange "grid" effect on a completely uniform texture. Since all fragments get the same processing and same neighbouring values,I wonder if the grid is the result of some kind of artifact with floating points or the way texture coordinates are interpolated. Or I missed something completely obvious…
> 
> The Gaussian kernel is in theory infinite. Of course you need to cut it off somewhere, but you should normalize the kernel such that its sum is 1.0. I'm guessing that the fact that your kernel is asymetric does not help either.
> 
> The code below fixes the pattern:
> 
> vec4
> filter( float x, vec4 c0, vec4 c1, vec4 c2, vec4 c3 )
> {
> float w;
>     
> w = gaussian(x+1.0); // h.x;
> float w_sum = w;
> vec4 r = c0 * w;
>     
> w = gaussian(x+0.0); // h.y;
> w_sum += w;
> r += c1 * w;
>     
> w = gaussian(1.0-x); // h.z;
> w_sum += w;
> r += c2 * w;
>     
> w = gaussian(2.0-x); // h.w;
> w_sum += w;
> r += c3 * w;
>     
> return r/w_sum;
> }
>  
> 
> Also a suggestion. I'm doing something similar in visvis to anti-alias 2D images. I also use a vec4 to represent the kernel, but I make use of the fact that the Gaussian kernel is symetric: kernel[0] is the center element, and kernel[1] to kernel[3] are the 3 elements on each side of the center. This way I get a kernel of effectively 7 elements. Further, I calculate (and normalize) the kernel beforehand in Python, and pass it as a uniform vec4. This way, it does not have to be calculated for each pixel. I'm not sure how significant this is for the speed, but there is a costly exp call in there ...
> 
> Regards,
>   Almar
> 
> 

Re: [PyOpenGL-Users] Tricky question on shader

[Almar K. <alm...@gm...>]

Hi,


> I've been playing with gaussian texture filtering using shaders and I
> obtained a strange "grid" effect on a completely uniform texture. Since all
> fragments get the same processing and same neighbouring values,I wonder if
> the grid is the result of some kind of artifact with floating points or the
> way texture coordinates are interpolated. Or I missed something completely
> obvious…
>

The Gaussian kernel is in theory infinite. Of course you need to cut it off
somewhere, but you should normalize the kernel such that its sum is 1.0. I'm
guessing that the fact that your kernel is asymetric does not help either.

The code below fixes the pattern:

 vec4

filter( float x, vec4 c0, vec4 c1, vec4 c2, vec4 c3 )

{

float w;

 w = gaussian(x+1.0); // h.x;

float w_sum = w;

vec4 r = c0 * w;

 w = gaussian(x+0.0); // h.y;

w_sum += w;

r += c1 * w;

 w = gaussian(1.0-x); // h.z;

w_sum += w;

r += c2 * w;

 w = gaussian(2.0-x); // h.w;

w_sum += w;

r += c3 * w;

 return r/w_sum;

}


Also a suggestion. I'm doing something similar in visvis to anti-alias 2D
images. I also use a vec4 to represent the kernel, but I make use of the
fact that the Gaussian kernel is symetric: kernel[0] is the center element,
and kernel[1] to kernel[3] are the 3 elements on each side of the center.
This way I get a kernel of effectively 7 elements. Further, I calculate (and
normalize) the kernel beforehand in Python, and pass it as a uniform vec4.
This way, it does not have to be calculated for each pixel. I'm not sure how
significant this is for the speed, but there is a costly exp call in there
...

Regards,
  Almar

Re: [PyOpenGL-Users] Tricky question on shader

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

On Wed, Aug 31, 2011 at 3:48 PM, Nicolas Rougier
<Nic...@in...>wrote:

>
> Hi folks,
>
> I've been playing with gaussian texture filtering using shaders and I
> obtained a strange "grid" effect on a completely uniform texture. Since all
> fragments get the same processing and same neighbouring values,I wonder if
> the grid is the result of some kind of artifact with floating points or the
> way texture coordinates are interpolated. Or I missed something completely
> obvious…
>
> I attached the code below. It is self-contained and you should see the grid
> I'm talking about.
>
> Nicolas

It feels like the texture coordinates as you calculate them in
interpolate(...), and the offsets in filter(...) are to blame.  I assume
you're trying to do something like a "manual" minification filter using a
gauss kernel.  Without knowing more about the algorithm, I can't say.

My recommendation is to try gamedev.net in the OpenGL forum, as there are a
large number of people there who can help.

Ian

[PyOpenGL-Users] Tricky question on shader

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

Hi folks,

I've been playing with gaussian texture filtering using shaders and I obtained a strange "grid" effect on a completely uniform texture. Since all fragments get the same processing and same neighbouring values,I wonder if the grid is the result of some kind of artifact with floating points or the way texture coordinates are interpolated. Or I missed something completely obvious…

I attached the code below. It is self-contained and you should see the grid I'm talking about.

Nicolas

Re: [PyOpenGL-Users] Possible PyOpenGL Material/Shader/Display List Bug

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

Well, I made my test, and it's not PyOpenGL :-)

Problem still occurs.  The code is mostly just a direct port of the Python
version, with a few simplifications and rearrangements as necessary.

Thanks,
Ian

Re: [PyOpenGL-Users] Possible PyOpenGL Material/Shader/Display List Bug

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

On Mon, Aug 29, 2011 at 8:32 PM, Alejandro Segovia <as...@gm...>wrote:

> Hello Ian,
>
> On Sun, Aug 21, 2011 at 12:42 PM, Alejandro Segovia <as...@gm...>wrote:
>
>> Hi Ian,
>>
>> Ah, the driver might be where the difference is. I am using PyOpenGL 3.0.1
>>>> but I'm on a Mac, so I'm not using the NVIDIA drivers at all.Best,
>>>>
>>>> I sent a bug report to NVIDIA, but evidently I have to be a registered
>>> developer to submit anything so technical.  I started the application
>>> process, so hopefully they'll be able to get the report in a few days.  Let
>>> me know how your tests go,
>>>
>>
>> Sorry for the delay, I was really busy last week. I tried the script on
>> Linux and, much to my surprise, I still can't reproduce the problem you
>> describe.
>>
>>  I initially get a red quad and then I can turn on and off the white quad
>> without any issues.
>>
>> This is my system configuration, I'm on Fedora 12 x86_64:
>>
>> >>> glGetString(GL_VERSION)
>> '4.0.0 NVIDIA 256.44'
>>
>> >>> glGetString(GL_RENDERER)
>> 'GeForce GTX 465/PCI/SSE2'
>>
>> >>> glGetString(GL_VENDOR)
>> 'NVIDIA Corporation'
>>
>> I'm starting to wonder whether this could be a Windows-specific issue.
>>
>
> Well, I've finally took some time to try this on Windows. Unfortunately, I
> still can't reproduce the symptoms!
>
> This is my system configuration:
>
> >>> glGetString(GL_VERSION)
> '4.1.0'
>
> >>> glGetString(GL_RENDERER)
> 'GeForce GTX 465/PCI/SSE2'
>
> >>> glGetString(GL_VENDOR)
> 'NVIDIA Corporation'
>
> I'm on a 64-bit Windows 7 (Professional).
>
> Is there anything I might be missing?
>
Well, I'm on 32-bit, and I have a different GPU.  I think it must be a
particular combination of my GPU and my driver that's causing the issue.

> Did you get any kind of reply from NVIDIA?
>
Sadly no.  I think I shall have to go yell at them again.

>
> I've read about them releasing OpenGL 4.2-capable drivers. Have you tried
> those?
>
The only ones I'd tried are 275.33, 266.58, and 280.26.

I wonder if this is a PyOpenGL problem.  Even though it seems like a
hardware issue, perhaps there's something underlying that's causing the
issue?  I'll see about writing a small C++ test.

Thanks for checking!
Ian

Re: [PyOpenGL-Users] Possible PyOpenGL Material/Shader/Display List Bug

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

Hello Ian,

On Sun, Aug 21, 2011 at 12:42 PM, Alejandro Segovia <as...@gm...>wrote:

> Hi Ian,
>
> Ah, the driver might be where the difference is. I am using PyOpenGL 3.0.1
>>> but I'm on a Mac, so I'm not using the NVIDIA drivers at all.Best,
>>>
>>> I sent a bug report to NVIDIA, but evidently I have to be a registered
>> developer to submit anything so technical.  I started the application
>> process, so hopefully they'll be able to get the report in a few days.  Let
>> me know how your tests go,
>>
>
> Sorry for the delay, I was really busy last week. I tried the script on
> Linux and, much to my surprise, I still can't reproduce the problem you
> describe.
>
>  I initially get a red quad and then I can turn on and off the white quad
> without any issues.
>
> This is my system configuration, I'm on Fedora 12 x86_64:
>
> >>> glGetString(GL_VERSION)
> '4.0.0 NVIDIA 256.44'
>
> >>> glGetString(GL_RENDERER)
> 'GeForce GTX 465/PCI/SSE2'
>
> >>> glGetString(GL_VENDOR)
> 'NVIDIA Corporation'
>
> I'm starting to wonder whether this could be a Windows-specific issue.
>

Well, I've finally took some time to try this on Windows. Unfortunately, I
still can't reproduce the symptoms!

This is my system configuration:

>>> glGetString(GL_VERSION)
'4.1.0'

>>> glGetString(GL_RENDERER)
'GeForce GTX 465/PCI/SSE2'

>>> glGetString(GL_VENDOR)
'NVIDIA Corporation'

I'm on a 64-bit Windows 7 (Professional).

Is there anything I might be missing? Did you get any kind of reply from
NVIDIA?

I've read about them releasing OpenGL 4.2-capable drivers. Have you tried
those?

Best regards,
Alejandro.-

-- 
http://alejandrosegovia.net

[PyOpenGL-Users] OSX - glutCheckLoop and glutWMCloseFunc

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

Hi everybody,


While having a look at glut headers on OSX, I realized that there are a glutCheckLoop and a glutWMCloseFunc functions but they are not exported through OpenGL.GLUT. 


#if (GLUT_MACOSX_IMPLEMENTATION >= 2)
/* Mac OS X specific API */
extern void APIENTRY glutWMCloseFunc(void (*func)(void));
extern void APIENTRY glutCheckLoop(void);
#endif


I quickly tried to add the following code in OpenGL/GLUT/__init__.py (I know it should be done somewhere else) as a quick test and it seems to be working fine:

glutCheckLoop = platform.createBaseFunction( 
    'glutCheckLoop', dll=platform.GLUT, resultType=None, 
    argTypes=[],
    doc='glutCheckLoop(  ) -> None', 
    argNames=(),
)

glutCheckLoop = platform.createBaseFunction( 
    'glutCheckLoop', dll=platform.GLUT, resultType=None, 
    argTypes=[],
    doc='glutCheckLoop(  ) -> None', 
    argNames=(),
)


Would that be possible to include the code (at the right place) for next release ?


Nicolas

Re: [PyOpenGL-Users] Possible PyOpenGL Material/Shader/Display List Bug

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

Hi Ian,

Ah, the driver might be where the difference is. I am using PyOpenGL 3.0.1
>> but I'm on a Mac, so I'm not using the NVIDIA drivers at all.Best,
>>
>> I sent a bug report to NVIDIA, but evidently I have to be a registered
> developer to submit anything so technical.  I started the application
> process, so hopefully they'll be able to get the report in a few days.  Let
> me know how your tests go,
>

Sorry for the delay, I was really busy last week. I tried the script on
Linux and, much to my surprise, I still can't reproduce the problem you
describe.

I initially get a red quad and then I can turn on and off the white quad
without any issues.

This is my system configuration, I'm on Fedora 12 x86_64:

>>> glGetString(GL_VERSION)
'4.0.0 NVIDIA 256.44'

>>> glGetString(GL_RENDERER)
'GeForce GTX 465/PCI/SSE2'

>>> glGetString(GL_VENDOR)
'NVIDIA Corporation'

I'm starting to wonder whether this could be a Windows-specific issue.

Best,
Alejandro.-

-- 
 http://alejandrosegovia.net

Re: [PyOpenGL-Users] Possible PyOpenGL Material/Shader/Display List Bug

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

On 11-08-15 06:05 PM, Ian Mallett wrote:
...
> -If I add another step between 2. and 3., where I unbind and rebind
> the shader (i.e., steps are: 1, 2, 4,1, 3, 4), then the program works
> as expected (both

I don't see any difference from doing the bind/unbind, so I'm assuming
that I'm not seeing the issue (I see a red quad in all cases).

It really does sound like a broken driver (I'm on an AMD here).

Not sure what to suggest here,
Mike

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

Re: [PyOpenGL-Users] Possible PyOpenGL Material/Shader/Display List Bug

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

Hi Ian,

On Mon, Aug 15, 2011 at 7:05 PM, Ian Mallett <geo...@gm...> wrote:

> Hi,
>
> There is an odd problem I've encountered.  Also I describe on gamedev.net,
> here <http://www.gamedev.net/topic/608387-weird-shadermaterial-problem/>:
> 1. Bind a shader (compiles, links, etc. with no errors or warnings)
> 2. Draw a simple quad:
> glBegin(GL_QUADS)
> glVertex3f(0,0,0)
> glVertex3f(1,0,0)
> glVertex3f(1,0,1)
> glVertex3f(0,0,1)
> glEnd()
> 3. Call a display list.
> 4. Unbind the shader (back to fixed function)
>
> The display list contains code that alters material properties with
> glMaterialfv(...), as well as an object. The problem is that, though the
> object draws, the values of gl_FrontMaterial in the fragment program are
> incorrect, so it doesn't look as it should.
>
> Now, properties of the issue:
> -If I remove both steps 1. and 4., then the materials work correctly
> (though the rendering of the object isn't as nice).
> -If I instead remove step 2., then the shader works correctly (but then, of
> course, the simple quad isn't drawn).
> -If I add another step between 2. and 3., where I unbind and rebind the
> shader (i.e., steps are: 1, 2, 4,1, 3, 4), then the program works as
> expected (both the quad draws, and the materials work properly when the
> object is drawn--but then of course I'm binding and unbinding the shader
> when it really shouldn't be necessary).
> -Drawing the object without a display list alleviates the problem (but then
> it's slower).
>
> I've attached an example file (requires PyGame, PyOpenGL), tested with
> Python 2.6 on NVIDIA 8400M GS (tested against three different drivers) that
> demonstrates the problem.  Click+drag to rotate, "D" to toggle drawing of
> other polygon.
>

I've gone through your code and tried running it. I don't think I'm being
able to reproduce the problem you describe.

By default I get a red quad floating around (the one from the Display List)
and, upon pressing "D", a white quad appears. The red quad always stays red.
Maybe I'm not understanding the problem completely. Should any of the quads
change color when toggling the white one?

I'm running the source file without any changes, so (I think) I'm going
through steps 1,2,3,4 in order.

This is my current config:
>>> glGetString(GL_VERSION)
'2.1 NVIDIA-1.6.36'

>>> glGetString(GL_RENDERER)
'NVIDIA GeForce 9400M OpenGL Engine'

Alejandro.-



-- 
http://alejandrosegovia.net

[PyOpenGL-Users] Possible PyOpenGL Material/Shader/Display List Bug

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

Hi,

There is an odd problem I've encountered.  Also I describe on gamedev.net,
here <http://www.gamedev.net/topic/608387-weird-shadermaterial-problem/>:
1. Bind a shader (compiles, links, etc. with no errors or warnings)
2. Draw a simple quad:
glBegin(GL_QUADS)
glVertex3f(0,0,0)
glVertex3f(1,0,0)
glVertex3f(1,0,1)
glVertex3f(0,0,1)
glEnd()
3. Call a display list.
4. Unbind the shader (back to fixed function)

The display list contains code that alters material properties with
glMaterialfv(...), as well as an object. The problem is that, though the
object draws, the values of gl_FrontMaterial in the fragment program are
incorrect, so it doesn't look as it should.

Now, properties of the issue:
-If I remove both steps 1. and 4., then the materials work correctly (though
the rendering of the object isn't as nice).
-If I instead remove step 2., then the shader works correctly (but then, of
course, the simple quad isn't drawn).
-If I add another step between 2. and 3., where I unbind and rebind the
shader (i.e., steps are: 1, 2, 4,1, 3, 4), then the program works as
expected (both the quad draws, and the materials work properly when the
object is drawn--but then of course I'm binding and unbinding the shader
when it really shouldn't be necessary).
-Drawing the object without a display list alleviates the problem (but then
it's slower).

I've attached an example file (requires PyGame, PyOpenGL), tested with
Python 2.6 on NVIDIA 8400M GS (tested against three different drivers) that
demonstrates the problem.  Click+drag to rotate, "D" to toggle drawing of
other polygon.

Thanks!
Ian

[PyOpenGL-Users] [ pyopengl-Feature Requests-574464 ] Testing framework

[SourceForge.net <no...@so...>]

Feature Requests item #574464, was opened at 2002-06-27 06:48
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355988&aid=574464&group_id=5988

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: new module-OpenGLContext
Group: OpenGLContext v1.0
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Mike C. Fletcher (mcfletch)
Assigned to: Mike C. Fletcher (mcfletch)
Summary: Testing framework

Initial Comment:
Need to work on creating an automated testing framework
for PyOpenGL.  This should allow for testing the
various context modes with test code snippets and
possibly comparing results with expected-results
bitmaps (taking into consideration that OpenGL doesn't
guarantee pixel-perfect reproduction AFAIK).

At the least the code should be able to run every
method in the library just to see if they blow up.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2011-07-18 18:27

Message:
iPhU4G  <a href="http://dvujzvmrrwqo.com/">dvujzvmrrwqo</a>,
[url=http://wfeeopozspxb.com/]wfeeopozspxb[/url],
[link=http://eqengollzyxj.com/]eqengollzyxj[/link],
http://egeuvonjhmyx.com/

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355988&aid=574464&group_id=5988

Re: [PyOpenGL-Users] PyOpenGL on Windows

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

>
> Thanks for that Alejandro.
>

No problemo! Let me know how it goes.

Best,
Alejandro.-

PS: Stay tuned for more PyOpenGL/Windows adventures as I stumble across new
blocks along the way (like trying to use cx_Freeze with PyOpenGL). Crashing
a thread near you soon ;)


-- 
http://alejandrosegovia.net

Re: [PyOpenGL-Users] PyOpenGL on Windows

[Henry G. <he...@ca...>]

On Tue, 2011-07-12 at 14:20 +0100, Henry Gomersall wrote:
> On Tue, 2011-07-12 at 10:11 -0300, Alejandro Segovia wrote:
> > The only changes I had to make were to convert the GLE source to a
> > Visual C++ 9 project and then change the project configuration to
> > generate a DLL instead of a static link library (.LIB). 
> > 
> > Should I just attach the files to a mail message or do you have a
> FTP
> > site? It's a little more than 5MB in size. 
> 
> Its probably easiest to email it to me personally and I'll send a link
> to the list. 

There is now a github repository containing the updated gle32.dll file
and the source tree used to compile it. This can be found at:
https://github.com/hgomersall/GLE-for-PyOpenGL-for-Windows

I'm not in a position to test it at the moment, but I will do in the
next few days.

Thanks for that Alejandro.

Cheers,

Henry

Re: [PyOpenGL-Users] PyOpenGL on Windows

[Henry G. <he...@ca...>]

On Tue, 2011-07-12 at 10:11 -0300, Alejandro Segovia wrote:
> The only changes I had to make were to convert the GLE source to a
> Visual C++ 9 project and then change the project configuration to
> generate a DLL instead of a static link library (.LIB). 
> 
> Should I just attach the files to a mail message or do you have a FTP
> site? It's a little more than 5MB in size. 

Its probably easiest to email it to me personally and I'll send a link
to the list.

Cheers,

Henry

Re: [PyOpenGL-Users] PyOpenGL on Windows

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

On Tue, Jul 12, 2011 at 4:45 AM, Henry Gomersall <he...@ca...> wrote:

> On Mon, 2011-07-11 at 23:43 -0300, Alejandro Segovia wrote:
> >
> > Would you like me to send the compiled DLL over?
>
> I would please. I'm sure it would be useful to others, so I can push it
> onto my github repository for the time being if you're happy with that.
> In which case, could you send the source over as well. Were there any
> changes?
>

Okay, I have everything ready: the DLL and the source.

The only changes I had to make were to convert the GLE source to a Visual
C++ 9 project and then change the project configuration to generate a DLL
instead of a static link library (.LIB).

Should I just attach the files to a mail message or do you have a FTP site?
It's a little more than 5MB in size.

Alejandro.-



-- 
http://alejandrosegovia.net

Re: [PyOpenGL-Users] PyOpenGL on Windows

[Henry G. <he...@ca...>]

On Mon, 2011-07-11 at 23:43 -0300, Alejandro Segovia wrote:
> 
> Would you like me to send the compiled DLL over? 

I would please. I'm sure it would be useful to others, so I can push it
onto my github repository for the time being if you're happy with that.
In which case, could you send the source over as well. Were there any
changes?

Cheers,
Henry

Re: [PyOpenGL-Users] PyOpenGL on Windows

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

Hi Mike,

> Okay guys, I managed to get the GLE source code. It was found laying in a
> SourceForge project.
>
>  http://sourceforge.net/projects/gle/
>
>  By default it builds as a static library. I ported the project to Visual
> C++ 9 (so it links against MSVCRT9.0) and tweaked it to build into a DLL
> file.
>
>  I've replaced the old and busted gle32.dll with this new DLL and my
> application no longer complains about missing the MSVCRT7.1 runtime.
>
>  Mike, would you agree on replacing the old DLL in the PyOpenGL source
> bundle with this one?
>
> IIRC we need to have multiple versions and choose the correct one based on
> which Python we are installing into.  I've tagged this as a todo for myself.
>

Would you like me to send the compiled DLL over?

Let me know if I can help.

Alejandro.-


>  On Mon, Jul 4, 2011 at 3:15 PM, Alejandro Segovia <as...@gm...>wrote:
>
>> Hi Henry,
>>
>>  Thanks for all the help. The CRT versioning discussion was a great read.
>>
>>   >> It seems that the gle32.dll packaged with PyOpenGL has this
>>> >> dependency, so its this library that needs to be recompiled.
>>>
>>>  It also seems to be a fairly minimal change to remove the GLE
>>> functionality entirely under Windows. Certainly, I won't be needing it.
>>>
>>
>>  Yes, I think I'll go this way too. I'll try to find whatever code
>> requests this DLL to be loaded and nuke it. I just hope nothing breaks.
>>
>>  It would still be nice being able to recompile this library and patch
>> PyOpenGL. I found this other page using Google:
>> http://brightideassoftware.com/GLE32Downloads.aspx but the source code is
>> incomplete and I can't build it.
>>
>>  If anyone has the GLE32 code, please drop me a line.
>>
>>  Best,
>> Alejandro.-
>>
>>
>> --
>> http://alejandrosegovia.net
>>
>>
>
>
> --
> http://alejandrosegovia.net
>
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
>
>
> _______________________________________________
> PyOpenGL Homepagehttp://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>
>
>
> --
> ________________________________________________
>   Mike C. Fletcher
>   Designer, VR Plumber, Coder
>   http://www.vrplumber.com
>   http://blog.vrplumber.com
>
>
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>
>


-- 
http://alejandrosegovia.net

Re: [PyOpenGL-Users] Support for py3k?

[Almar K. <alm...@gm...>]

> I believe Renaud reported we ran on Py3K with 2to3, and IIRC that was my
> experience as well with the very limited set of tests that don't use
> Numpy.  However, I don't really have any interest or bandwidth to test
> it without getting OpenGLContext running there (since that's what 90% of
> my tests are written in).  I'm willing to accept Py3K patches as long as
> we retain Python 2.5 compatibility and don't introduce too much code-smell.
>

Ok, I might look into that in the future (too busy right now).

Regards,
  Almar

Re: [PyOpenGL-Users] Support for py3k?

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

On 11-07-06 04:28 AM, Almar Klein wrote:
> Hi all,
>
> I'm using PyOpenGl as a basis for my visualization toolkit
> (http://code.google.com/p/visvis/). Thanks for the great package.
>
> Since Numpy is now py3k-ready, I'm starting to think about supporting
> Python3. Any idea when PyOpenGL is going to run on Python 3 too?
>
> I did see a branch of PyOpenGL that is supposed to run on Py3k, but it
> said "untested".
I believe Renaud reported we ran on Py3K with 2to3, and IIRC that was my
experience as well with the very limited set of tests that don't use
Numpy.  However, I don't really have any interest or bandwidth to test
it without getting OpenGLContext running there (since that's what 90% of
my tests are written in).  I'm willing to accept Py3K patches as long as
we retain Python 2.5 compatibility and don't introduce too much code-smell.

HTH,
Mike

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

Re: [PyOpenGL-Users] PyOpenGL on Windows

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

On 11-07-04 02:41 PM, Alejandro Segovia wrote:
> Okay guys, I managed to get the GLE source code. It was found laying
> in a SourceForge project.
>
> http://sourceforge.net/projects/gle/
>
> By default it builds as a static library. I ported the project to
> Visual C++ 9 (so it links against MSVCRT9.0) and tweaked it to build
> into a DLL file.
>
> I've replaced the old and busted gle32.dll with this new DLL and my
> application no longer complains about missing the MSVCRT7.1 runtime.
>
> Mike, would you agree on replacing the old DLL in the PyOpenGL source
> bundle with this one?
IIRC we need to have multiple versions and choose the correct one based
on which Python we are installing into.  I've tagged this as a todo for
myself.

HTH,
Mike
>
> On Mon, Jul 4, 2011 at 3:15 PM, Alejandro Segovia <as...@gm...
> <mailto:as...@gm...>> wrote:
>
>     Hi Henry,
>
>     Thanks for all the help. The CRT versioning discussion was a great
>     read.
>
>         >> It seems that the gle32.dll packaged with PyOpenGL has this
>         >> dependency, so its this library that needs to be recompiled.
>
>         It also seems to be a fairly minimal change to remove the GLE
>         functionality entirely under Windows. Certainly, I won't be
>         needing it.
>
>
>     Yes, I think I'll go this way too. I'll try to find whatever code
>     requests this DLL to be loaded and nuke it. I just hope nothing
>     breaks. 
>
>     It would still be nice being able to recompile this library and
>     patch PyOpenGL. I found this other page using
>     Google: http://brightideassoftware.com/GLE32Downloads.aspx but the
>     source code is incomplete and I can't build it.
>
>     If anyone has the GLE32 code, please drop me a line.
>
>     Best,
>     Alejandro.-
>
>
>     -- 
>     http://alejandrosegovia.net
>
>
>
>
> -- 
> http://alejandrosegovia.net
>
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security 
> threats, fraudulent activity, and more. Splunk takes this data and makes 
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
>
>
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users


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

Re: [PyOpenGL-Users] error using GL_MAX_TEXTURE_BUFFER_SIZE_ARB

[Belzile Marc-A. <ma...@ho...>]

Going back to my initial question. GL_MAX_TEXTURE_BUFFER_SIZE_ARB is not in the OpenGL.constants module so that's why I get an unknown specifier error:
 File "c:\Python27\lib\site-packages\OpenGL\converters.py", line 234, in getSize   raise KeyError( """Unknown specifier %s"""%( specifier ))eyError: ('Unknown specifier GL_MAX_TEXTURE_BUFFER_SIZE_ARB (35883)', 'Failure in cConverter <OpenGL.converters.SizedOutput objectt 0x0000000002C6CEC8>', (GL_MAX_TEXTURE_BUFFER_SIZE_ARB,), 1, <OpenGL.wrapper.glGetIntegerv object at 0x0000000002EF8148>)
glInitTextureBufferObjectARB() indicates that the extension is actually available.
I was under the impression that all opengl extensions constants were generated at install time. Is it the case or do I need to do something special to generate them ?
thanks
-mab

From: ma...@ho...
To: as...@gm...
Date: Tue, 5 Jul 2011 23:01:13 -0400
CC: pyo...@li...
Subject: Re: [PyOpenGL-Users] error using GL_MAX_TEXTURE_BUFFER_SIZE_ARB








These 'NoneType is not callable" errors are probably related to a bad installation. I used PyQt as well and got the same error. 

-mab

From: as...@gm...
Date: Tue, 5 Jul 2011 23:32:22 -0300
Subject: Re: [PyOpenGL-Users] error using GL_MAX_TEXTURE_BUFFER_SIZE_ARB
To: ma...@ho...
CC: pyo...@li...

Hello Mab,
I am currently using PyOpenGL on a Windows 7 x64 machine and I haven't run into these issues. I am not using GLUT though, I create my OpenGL context using Qt.


Those "NoneType is not callable" errors lead me to believe that for some reason the OpenGL functions are not being linked into your program. This should happen automagically when you create an OpenGL context (at least this is the case for me using Qt on a NVIDIA driver).


Have you tried using a different mechanism to create your window? pygame is really simple, just call pygame.display.set_mode((w,h), pygame.OPENGL | pygame.DOUBLEBUF).
Alejandro.-



On Tue, Jul 5, 2011 at 10:49 PM, Belzile Marc-André <ma...@ho...> wrote:







Hi,
anyone knows what's going on ? I supsect my pyopengl installation is not adequate. So here are the instructions I used to install pyopengl 3.0.1:
python.exe setup.py build

python.exe setup.py install
However this doesn't seem to do the job:
C:\Users\mab\Downloads\PyOpenGL-3.0.1 (1)\PyOpenGL-3.0.1\tests>python test_glutinit.py

Traceback (most recent call last):  File "test_glutinit.py", line 18, in <module>    glutInit([])  File "c:\Python27\lib\site-packages\OpenGL\GLUT\special.py", line 323, in glutInit

    _base_glutInit( ctypes.byref(count), holder )TypeError: 'NoneType' object is not callable
I'm sure I'm missing something obvious. Is there any more magic involved for installing pyopengl on win64 ?


I was able to install the win64 package available here http://www.lfd.uci.edu/~gohlke/pythonlibs/ but I still get the error for GL_MAX_TEXTURE_BUFFER_SIZE_ARB .


thanks for your help
-mab


From: ma...@ho...


To: as...@gm...
Date: Tue, 5 Jul 2011 09:55:04 -0400
CC: pyo...@li...


Subject: Re: [PyOpenGL-Users] error using GL_MAX_TEXTURE_BUFFER_SIZE_ARB








Hi,
yes I did. Here's the full code I'm using:
"""Log opengl info for this machine"""

from OpenGL.GL import *

from OpenGL.GLUT import *from OpenGL.GL.ARB.texture_buffer_object import *



def InitGL(Width, Height):	glClearColor(0.0, 0.0, 0.0, 0.0)

	glMatrixMode(GL_PROJECTION)

	glLoadIdentity()	glMatrixMode(GL_MODELVIEW)

  

def log_opengl_info(): 	ver = glGetString( GL_VERSION )

 	ven = glGetString( GL_VENDOR )

 	ren = glGetString( GL_RENDERER )
 	
 	print 'vendor: %s\nopenl version: %s\nrenderer: %s\nsupported extensions:' % (ven,ver,ren)

 	#print '\n'.join( glGetString( GL_EXTENSIONS ).split(' ') )

	print 'OpenGL.GL.ARB.texture_buffer_object %d\n' % glInitTextureBufferObjectARB()

	print glGetIntegerv( GL_MAX_TEXTURE_BUFFER_SIZE_ARB )

def render():

	glClear(GL_COLOR_BUFFER_BIT)

	glLoadIdentity()	log_opengl_info()

window = None	

def main():	global window

	glutInit(sys.argv)

	glutInitDisplayMode(GLUT_RGBA)

	glutInitWindowSize(10, 10)

	glutInitWindowPosition(0, 0)

	window = glutCreateWindow('log opengl info')

	glutDisplayFunc(render)

	# Initialize our window. 

	InitGL(10, 10)

	# Start Event Processing Engine    

	glutMainLoop()



if __name__ == "__main__":    main()



From: as...@gm...
Date: Tue, 5 Jul 2011 10:14:14 -0300
Subject: Re: [PyOpenGL-Users] error using GL_MAX_TEXTURE_BUFFER_SIZE_ARB
To: ma...@ho...


CC: pyo...@li...

Hi Mab,





Hi,



using GL_MAX_TEXTURE_BUFFER_SIZE_ARB ends up with an error 




Have you tried creating a window with an OpenGL context before trying to call glGetIntegerv?
Alejandro.- --  http://alejandrosegovia.net




 		 	   		  

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
PyOpenGL Homepage
http://pyopengl.sourceforge.net
_______________________________________________
PyOpenGL-Users mailing list
PyO...@li...
https://lists.sourceforge.net/lists/listinfo/pyopengl-users 		 	   		  


-- 
http://alejandrosegovia.net

 		 	   		  

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
PyOpenGL Homepage
http://pyopengl.sourceforge.net
_______________________________________________
PyOpenGL-Users mailing list
PyO...@li...
https://lists.sourceforge.net/lists/listinfo/pyopengl-users