pyopengl-users — Discussion of all PyOpenGL matters.

Re: [PyOpenGL-Users] Setting Up on New Machine

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

On Mon, 2012-02-27 at 10:23 -0500, Mike C. Fletcher wrote:
> > This:
> > https://github.com/hgomersall/GLE-for-PyOpenGL-for-Windows
> >
> > might be useful for the gle bit.
> >
> > cheers,
> >
> > Henry
> Do you happen to know what the changes were?  Is this something I
> should 
> fold back into PyOpenGL's build process?  Were there changes that
> make 
> non-64-bit no longer work?  Seem the history starts with your adding
> it 
> to the repository there. 

The changes were so it would build, which were all done by Alejandro. I
pretty certain it's unmodified from that code he sent me.

I don't *even* think that I built it - the dll was from Alejandro's
efforts. (sorry I can't be more useful!).

Cheers,

Henry

Re: [PyOpenGL-Users] Setting Up on New Machine

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

On Mon, 2012-02-27 at 10:18 -0500, Mike C. Fletcher wrote:
> > Theoretically, it should be possible to use cygwin to generate
> 64-bit 
> > binaries. Let me know if you decide to move forward in this
> direction, 
> > I might be able to help.
> 
> What I'm reading is saying that Mingw64 (i.e. Cygwin without the
> Cygwin 
> DLL) isn't a good option (yet).
> 
> http://wiki.cython.org/64BitCythonExtensionsOnWindows
> 
> The Python 2.6 win32 releases were all Mingw32 compiles, as that let
> me 
> use Mingw32 for 2.6 and VC++ Express for the 2.7 version.  I'll
> likely 
> go with the SDK approach for the 2.7 releases on 64-bit, not sure
> what 
> I'll do for the 64-bit 2.6 compiles yet.  If this wasn't a 
> pay-per-install OS I'd just set up a VM branch for the 2.6 release,
> but 
> I only have the one (real) machine with a Win64 license. 

There is more info on the distutils page on cross compiling:

http://docs.python.org/distutils/builtdist.html

I don't know how that tallies with the emphatic "Do not use MinGW-w64".
I'm assuming distutils uses mingw (though I don't really know).

cheers,

Henry

Re: [PyOpenGL-Users] Setting Up on New Machine

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

On 12-02-27 09:08 AM, Henry Gomersall wrote:
> On Mon, 2012-02-27 at 09:05 -0500, Mike C. Fletcher wrote:
>> Likely need to recompile all of the glut, gle, accelerate etc DLLs if
>> that's the case.  I'll see if I can get some time to do that today.
>> Don't know if I have all of the compilation tools set up properly for
>> the 64-bit Windows, so that might be a bit of a challenge (hopefully
>> mingw64 exists and will work with 2.6).  Python 2.7 *should* IIRC
>> work
>> with the currently-available free compiler, so *that* should be
>> straightforward.
> This:
> https://github.com/hgomersall/GLE-for-PyOpenGL-for-Windows
>
> might be useful for the gle bit.
>
> cheers,
>
> Henry
Do you happen to know what the changes were?  Is this something I should 
fold back into PyOpenGL's build process?  Were there changes that make 
non-64-bit no longer work?  Seem the history starts with your adding it 
to the repository there.

Thanks,
Mike

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

Re: [PyOpenGL-Users] Setting Up on New Machine

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

On 12-02-27 09:29 AM, Alejandro Segovia wrote:
> Hi all,
>
> Theoretically, it should be possible to use cygwin to generate 64-bit 
> binaries. Let me know if you decide to move forward in this direction, 
> I might be able to help.

What I'm reading is saying that Mingw64 (i.e. Cygwin without the Cygwin 
DLL) isn't a good option (yet).

http://wiki.cython.org/64BitCythonExtensionsOnWindows

The Python 2.6 win32 releases were all Mingw32 compiles, as that let me 
use Mingw32 for 2.6 and VC++ Express for the 2.7 version.  I'll likely 
go with the SDK approach for the 2.7 releases on 64-bit, not sure what 
I'll do for the 64-bit 2.6 compiles yet.  If this wasn't a 
pay-per-install OS I'd just set up a VM branch for the 2.6 release, but 
I only have the one (real) machine with a Win64 license.

Enjoy,
Mike

> 2012/2/27 Henry Gomersall <he...@ca... <mailto:he...@ca...>>
>
>     On Mon, 2012-02-27 <tel:2012-02-27> at 09:05 -0500, Mike C.
>     Fletcher wrote:
>     > Likely need to recompile all of the glut, gle, accelerate etc
>     DLLs if
>     > that's the case.  I'll see if I can get some time to do that today.
>     > Don't know if I have all of the compilation tools set up
>     properly for
>     > the 64-bit Windows, so that might be a bit of a challenge (hopefully
>     > mingw64 exists and will work with 2.6).  Python 2.7 *should* IIRC
>     > work
>     > with the currently-available free compiler, so *that* should be
>     > straightforward.
>
>     This:
>     https://github.com/hgomersall/GLE-for-PyOpenGL-for-Windows
>
>     might be useful for the gle bit.
>
>     cheers,
>
>     Henry
>
>
>     ------------------------------------------------------------------------------
>     Try before you buy = See our experts in action!
>     The most comprehensive online learning library for Microsoft
>     developers
>     is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3,
>     MVC3,
>     Metro Style Apps, more. Free future releases when you subscribe now!
>     http://p.sf.net/sfu/learndevnow-dev2
>     _______________________________________________
>     PyOpenGL Homepage
>     http://pyopengl.sourceforge.net
>     _______________________________________________
>     PyOpenGL-Users mailing list
>     PyO...@li...
>     <mailto:PyO...@li...>
>     https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>
>
>
>
> -- 
> http://alejandrosegovia.net
>


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

Re: [PyOpenGL-Users] Setting Up on New Machine

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

Hi all,

Theoretically, it should be possible to use cygwin to generate 64-bit
binaries. Let me know if you decide to move forward in this direction, I
might be able to help.

Best,
Alejandro.-

2012/2/27 Henry Gomersall <he...@ca...>

> On Mon, 2012-02-27 at 09:05 -0500, Mike C. Fletcher wrote:
> > Likely need to recompile all of the glut, gle, accelerate etc DLLs if
> > that's the case.  I'll see if I can get some time to do that today.
> > Don't know if I have all of the compilation tools set up properly for
> > the 64-bit Windows, so that might be a bit of a challenge (hopefully
> > mingw64 exists and will work with 2.6).  Python 2.7 *should* IIRC
> > work
> > with the currently-available free compiler, so *that* should be
> > straightforward.
>
> This:
> https://github.com/hgomersall/GLE-for-PyOpenGL-for-Windows
>
> might be useful for the gle bit.
>
> cheers,
>
> Henry
>
>
>
> ------------------------------------------------------------------------------
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
> _______________________________________________
> 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] Setting Up on New Machine

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

On Mon, 2012-02-27 at 09:05 -0500, Mike C. Fletcher wrote:
> Likely need to recompile all of the glut, gle, accelerate etc DLLs if 
> that's the case.  I'll see if I can get some time to do that today.  
> Don't know if I have all of the compilation tools set up properly for 
> the 64-bit Windows, so that might be a bit of a challenge (hopefully 
> mingw64 exists and will work with 2.6).  Python 2.7 *should* IIRC
> work 
> with the currently-available free compiler, so *that* should be 
> straightforward. 

This:
https://github.com/hgomersall/GLE-for-PyOpenGL-for-Windows

might be useful for the gle bit.

cheers,

Henry

Re: [PyOpenGL-Users] Setting Up on New Machine

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

On 12-02-25 07:19 PM, Ian Mallett wrote:
> On Fri, Feb 3, 2012 at 11:09 AM, Mike C. Fletcher 
> <mcf...@vr... <mailto:mcf...@vr...>> wrote:
>
>     The tess issues seem to have been there for a long time; it works
>     perfectly well in OpenGLContext' usage and tests, and even works
>     if I copy the OpenGLContext test into a raw test, but the original
>     test doesn't generate vertices (it wasn't checking for that
>     previously).  At this point I'm assuming this is just a test-setup
>     issue, so not a critical fix.
>
> Yeah, I'm not too concerned about gluTess* stuff; there's hardware 
> support for tessellation now, which is better.  And I can honestly 
> say, I've not had need for either.
>
> I am having a new problem, however.  glutInit is failing.  The error 
> looks something like:
>
>     Traceback (most recent call last):
>       File "<pyshell#2>", line 1, in <module>
>         glutInit()
>       File
>     "C:\dev\Python26\lib\site-packages\pyopengl-3.0.2a4-py2.6.egg\OpenGL\GLUT\special.py",
>     line 324, in glutInit
>         _base_glutInit( ctypes.byref(count), holder )
>     TypeError: 'NoneType' object is not callable
>
> There are similar problems with other GLUT functions.  I read 
> somewhere that this may be due to 64 bit issues (i.e., PyOpenGL is 
> trying to use a glut32.dll compiled for 32 bit platforms).  Is this 
> the case?  And is there a way to solve it for the general case?
>
> Thanks,
> Ian
Likely need to recompile all of the glut, gle, accelerate etc DLLs if 
that's the case.  I'll see if I can get some time to do that today.  
Don't know if I have all of the compilation tools set up properly for 
the 64-bit Windows, so that might be a bit of a challenge (hopefully 
mingw64 exists and will work with 2.6).  Python 2.7 *should* IIRC work 
with the currently-available free compiler, so *that* should be 
straightforward.

Always more work than time,
Mike

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

Re: [PyOpenGL-Users] Setting Up on New Machine

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

On Fri, Feb 3, 2012 at 11:09 AM, Mike C. Fletcher <mcf...@vr...>wrote:

> The tess issues seem to have been there for a long time; it works
> perfectly well in OpenGLContext' usage and tests, and even works if I copy
> the OpenGLContext test into a raw test, but the original test doesn't
> generate vertices (it wasn't checking for that previously).  At this point
> I'm assuming this is just a test-setup issue, so not a critical fix.
>
Yeah, I'm not too concerned about gluTess* stuff; there's hardware support
for tessellation now, which is better.  And I can honestly say, I've not
had need for either.

I am having a new problem, however.  glutInit is failing.  The error looks
something like:

Traceback (most recent call last):
  File "<pyshell#2>", line 1, in <module>
    glutInit()
  File
"C:\dev\Python26\lib\site-packages\pyopengl-3.0.2a4-py2.6.egg\OpenGL\GLUT\special.py",
line 324, in glutInit
    _base_glutInit( ctypes.byref(count), holder )
TypeError: 'NoneType' object is not callable

There are similar problems with other GLUT functions.  I read somewhere
that this may be due to 64 bit issues (i.e., PyOpenGL is trying to use a
glut32.dll compiled for 32 bit platforms).  Is this the case?  And is there
a way to solve it for the general case?

Thanks,
Ian

Re: [PyOpenGL-Users] Depth buffers and GLSL

[James G. <ja...@ja...>]

Well, it seems that I've solved my own problem! I turns out that I had a
very subtle bug in my perspective function, and it was giving me incorrect
values for the projection. Hence, the depth buffer was active and working,
but the depth values were incorrect, which is why it appeared that the
depth buffer wasn't running...

On Fri, Feb 24, 2012 at 5:03 AM, James Gao <ja...@ja...> wrote:

> Sorry for spamming the list, but I've seem to find another problem with my
> code. I can't seem to get depth test to work. I've checked all the usual
> suspects -- glEnable, glut is allocating the depth buffer. I'm using almost
> exclusively glsl 1.1 (no fixed function commands) -- is there something I
> must do in the shaders themselves in order to get depth test to work?
>
> Thanks in advance!
>
> -James
>

Re: [PyOpenGL-Users] Depth buffers and GLSL

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

Ahh, nevermind, I just realized you are taking that into account.

2012/2/24 Alejandro Segovia <as...@gm...>

> Dear James,
>
> It seems to me that you should trying creating your window _after_ having
> initialized GLUT, otherwise your GL configuration is being set before
> having an actual OpenGL Context.
>
> Hope this helps.
>
> Alejandro.-
>
> 2012/2/24 James Gao <ja...@ja...>
>
>>  I did try to write to gl_FragDepth, but it had no effect... Here's some
>> trimmed test code: http://pastebin.com/YD9pu0TU
>> Basically, I draw two planes -- a red one fairly close, and a blue one
>> that should be completely occluded by the red plane. As you can see in the
>> demo though, the blue one still gets drawn on top of the red one...
>>
>>
>> On Fri, Feb 24, 2012 at 7:43 AM, Ian Mallett <geo...@gm...>wrote:
>>
>>> On Fri, Feb 24, 2012 at 6:03 AM, James Gao <ja...@ja...> wrote:
>>>
>>>> Sorry for spamming the list, but I've seem to find another problem with
>>>> my code. I can't seem to get depth test to work. I've checked all the usual
>>>> suspects -- glEnable, glut is allocating the depth buffer. I'm using almost
>>>> exclusively glsl 1.1 (no fixed function commands) -- is there something I
>>>> must do in the shaders themselves in order to get depth test to work?
>>>
>>> You can write to gl_DepthCoord, but typically this is implicitly done as
>>> glFragCoord.z.
>>>
>>> Can we see code?
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Virtualization & Cloud Management Using Capacity Planning
>> Cloud computing makes use of virtualization - but cloud computing
>> also focuses on allowing computing to be delivered as a service.
>> http://www.accelacomm.com/jaw/sfnl/114/51521223/
>> _______________________________________________
>> PyOpenGL Homepage
>> http://pyopengl.sourceforge.net
>> _______________________________________________
>> PyOpenGL-Users mailing list
>> PyO...@li...
>> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>>
>>
>
>
> --
> http://alejandrosegovia.net
>
>


-- 
http://alejandrosegovia.net

Re: [PyOpenGL-Users] Depth buffers and GLSL

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

Dear James,

It seems to me that you should trying creating your window _after_ having
initialized GLUT, otherwise your GL configuration is being set before
having an actual OpenGL Context.

Hope this helps.

Alejandro.-

2012/2/24 James Gao <ja...@ja...>

> I did try to write to gl_FragDepth, but it had no effect... Here's some
> trimmed test code: http://pastebin.com/YD9pu0TU
> Basically, I draw two planes -- a red one fairly close, and a blue one
> that should be completely occluded by the red plane. As you can see in the
> demo though, the blue one still gets drawn on top of the red one...
>
>
> On Fri, Feb 24, 2012 at 7:43 AM, Ian Mallett <geo...@gm...> wrote:
>
>> On Fri, Feb 24, 2012 at 6:03 AM, James Gao <ja...@ja...> wrote:
>>
>>> Sorry for spamming the list, but I've seem to find another problem with
>>> my code. I can't seem to get depth test to work. I've checked all the usual
>>> suspects -- glEnable, glut is allocating the depth buffer. I'm using almost
>>> exclusively glsl 1.1 (no fixed function commands) -- is there something I
>>> must do in the shaders themselves in order to get depth test to work?
>>
>> You can write to gl_DepthCoord, but typically this is implicitly done as
>> glFragCoord.z.
>>
>> Can we see code?
>>
>
>
>
> ------------------------------------------------------------------------------
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> 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] Depth buffers and GLSL

[James G. <ja...@ja...>]

I did try to write to gl_FragDepth, but it had no effect... Here's some
trimmed test code: http://pastebin.com/YD9pu0TU
Basically, I draw two planes -- a red one fairly close, and a blue one that
should be completely occluded by the red plane. As you can see in the demo
though, the blue one still gets drawn on top of the red one...

On Fri, Feb 24, 2012 at 7:43 AM, Ian Mallett <geo...@gm...> wrote:

> On Fri, Feb 24, 2012 at 6:03 AM, James Gao <ja...@ja...> wrote:
>
>> Sorry for spamming the list, but I've seem to find another problem with
>> my code. I can't seem to get depth test to work. I've checked all the usual
>> suspects -- glEnable, glut is allocating the depth buffer. I'm using almost
>> exclusively glsl 1.1 (no fixed function commands) -- is there something I
>> must do in the shaders themselves in order to get depth test to work?
>
> You can write to gl_DepthCoord, but typically this is implicitly done as
> glFragCoord.z.
>
> Can we see code?
>

Re: [PyOpenGL-Users] Depth buffers and GLSL

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

On Fri, Feb 24, 2012 at 6:03 AM, James Gao <ja...@ja...> wrote:

> Sorry for spamming the list, but I've seem to find another problem with my
> code. I can't seem to get depth test to work. I've checked all the usual
> suspects -- glEnable, glut is allocating the depth buffer. I'm using almost
> exclusively glsl 1.1 (no fixed function commands) -- is there something I
> must do in the shaders themselves in order to get depth test to work?

You can write to gl_DepthCoord, but typically this is implicitly done as
glFragCoord.z.

Can we see code?

[PyOpenGL-Users] Depth buffers and GLSL

[James G. <ja...@ja...>]

Sorry for spamming the list, but I've seem to find another problem with my
code. I can't seem to get depth test to work. I've checked all the usual
suspects -- glEnable, glut is allocating the depth buffer. I'm using almost
exclusively glsl 1.1 (no fixed function commands) -- is there something I
must do in the shaders themselves in order to get depth test to work?

Thanks in advance!

-James

Re: [PyOpenGL-Users] Problems with simple pyopengl program

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

On 12-02-22 10:31 PM, James Gao wrote:
> Ahh, that did it, thank you so much! I had written a much larger 
> program based on a shader tutorial. I spent the last day and a half 
> slowly paring down the program until I got to that stub. I copied all 
> of it to C, saw that it worked, and finally had to ask someone...
>
> Perhaps a very large note in the documentation would be good?
Yeah, though I'm tempted to just disallow that functionality (int/float 
as an array) when the data-type is a GLvoidp (which should cover 
essentially all of the pointer-as-offset types, IIRC)... or maybe just 
disable it globally, as it really isn't all *that* useful most of the time.

Have fun,
Mike
>
>
> On Wed, Feb 22, 2012 at 6:58 PM, Mike C. Fletcher 
> <mcf...@vr... <mailto:mcf...@vr...>> wrote:
>
>     On 12-02-22 07:47 PM, James Gao wrote:
>     > Hi everyone,
>     > I'm trying to get a very very simple pass-through shader to work in
>     > pyopengl. I compiled and tested a simple C program, available here:
>     > http://pastebin.com/FGVxUUXH
>     > This program works exactly as expected -- a red plane is drawn,
>     > completely covering the screen.
>     >
>     > I tried to make the *exact* duplicate of this C program here:
>     > http://pastebin.com/dYbbXTY1
>     > This apparently does not work. Only the gray glClear color is
>     > displayed, and the two triangles are never drawn.
>     >
>     > Any insight into why this isn't working?
>
>     You need to modify the calls which are using voidp offsets to
>     explicitly
>     create GLvoidp instances, the integer 0 values are being
>     interpreted as
>     single-value arrays and the result is a useless offset:
>
>         glVertexAttribPointer( posidx, 2, GL_FLOAT, GL_FALSE, 4*2,
>     GLvoidp(0))
>
>         # Draw the two triangles
>         glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, ebuf);
>         glDrawElements(
>             GL_TRIANGLES,           # mode
>             6,           # count
>             GL_UNSIGNED_SHORT,      # type
>             GLvoidp(0)                       # element array buffer offset
>         )
>
>     This is a mis-feature of the wrapping in PyOpenGL allowing you to pass
>     in an integer where an array is expected.
>
>     HTH,
>     Mike
>
>     --
>     ________________________________________________
>       Mike C. Fletcher
>       Designer, VR Plumber, Coder
>     http://www.vrplumber.com
>     http://blog.vrplumber.com
>
>
>     ------------------------------------------------------------------------------
>     Virtualization & Cloud Management Using Capacity Planning
>     Cloud computing makes use of virtualization - but cloud computing
>     also focuses on allowing computing to be delivered as a service.
>     http://www.accelacomm.com/jaw/sfnl/114/51521223/
>     _______________________________________________
>     PyOpenGL Homepage
>     http://pyopengl.sourceforge.net
>     _______________________________________________
>     PyOpenGL-Users mailing list
>     PyO...@li...
>     <mailto: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] Problems with simple pyopengl program

[James G. <ja...@ja...>]

Ahh, that did it, thank you so much! I had written a much larger program
based on a shader tutorial. I spent the last day and a half slowly paring
down the program until I got to that stub. I copied all of it to C, saw
that it worked, and finally had to ask someone...

Perhaps a very large note in the documentation would be good?

-James

On Wed, Feb 22, 2012 at 6:58 PM, Mike C. Fletcher <mcf...@vr...>wrote:

> On 12-02-22 07:47 PM, James Gao wrote:
> > Hi everyone,
> > I'm trying to get a very very simple pass-through shader to work in
> > pyopengl. I compiled and tested a simple C program, available here:
> > http://pastebin.com/FGVxUUXH
> > This program works exactly as expected -- a red plane is drawn,
> > completely covering the screen.
> >
> > I tried to make the *exact* duplicate of this C program here:
> > http://pastebin.com/dYbbXTY1
> > This apparently does not work. Only the gray glClear color is
> > displayed, and the two triangles are never drawn.
> >
> > Any insight into why this isn't working?
>
> You need to modify the calls which are using voidp offsets to explicitly
> create GLvoidp instances, the integer 0 values are being interpreted as
> single-value arrays and the result is a useless offset:
>
>     glVertexAttribPointer( posidx, 2, GL_FLOAT, GL_FALSE, 4*2, GLvoidp(0))
>
>     # Draw the two triangles
>     glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, ebuf);
>     glDrawElements(
>         GL_TRIANGLES,           # mode
>         6,           # count
>         GL_UNSIGNED_SHORT,      # type
>         GLvoidp(0)                       # element array buffer offset
>     )
>
> This is a mis-feature of the wrapping in PyOpenGL allowing you to pass
> in an integer where an array is expected.
>
> HTH,
> Mike
>
> --
> ________________________________________________
>   Mike C. Fletcher
>   Designer, VR Plumber, Coder
>   http://www.vrplumber.com
>   http://blog.vrplumber.com
>
>
>
> ------------------------------------------------------------------------------
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>

Re: [PyOpenGL-Users] Problems with simple pyopengl program

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

On 12-02-22 07:47 PM, James Gao wrote:
> Hi everyone,
> I'm trying to get a very very simple pass-through shader to work in 
> pyopengl. I compiled and tested a simple C program, available here: 
> http://pastebin.com/FGVxUUXH
> This program works exactly as expected -- a red plane is drawn, 
> completely covering the screen.
>
> I tried to make the *exact* duplicate of this C program here: 
> http://pastebin.com/dYbbXTY1
> This apparently does not work. Only the gray glClear color is 
> displayed, and the two triangles are never drawn.
>
> Any insight into why this isn't working?

You need to modify the calls which are using voidp offsets to explicitly 
create GLvoidp instances, the integer 0 values are being interpreted as 
single-value arrays and the result is a useless offset:

     glVertexAttribPointer( posidx, 2, GL_FLOAT, GL_FALSE, 4*2, GLvoidp(0))

     # Draw the two triangles
     glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, ebuf);
     glDrawElements(
         GL_TRIANGLES,           # mode
         6,           # count
         GL_UNSIGNED_SHORT,      # type
         GLvoidp(0)                       # element array buffer offset
     )

This is a mis-feature of the wrapping in PyOpenGL allowing you to pass 
in an integer where an array is expected.

HTH,
Mike

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

[PyOpenGL-Users] Problems with simple pyopengl program

[James G. <ja...@ja...>]

Hi everyone,
I'm trying to get a very very simple pass-through shader to work in
pyopengl. I compiled and tested a simple C program, available here:
http://pastebin.com/FGVxUUXH
This program works exactly as expected -- a red plane is drawn, completely
covering the screen.

I tried to make the *exact* duplicate of this C program here:
http://pastebin.com/dYbbXTY1
This apparently does not work. Only the gray glClear color is displayed,
and the two triangles are never drawn.

Any insight into why this isn't working?

-James

Re: [PyOpenGL-Users] Difficulty with the shaders tutorial

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

You might want to have a look at:

gl.glPixelTransferf(gl.GL_ALPHA_SCALE, scale)
gl.glPixelTransferf(gl.GL_ALPHA_BIAS, bias)


This will control how your texture is mapped from CPU to GPU memory.

Have a look at http://code.google.com/p/glumpy/source/browse/glumpy/image/texture.py, this is exactly what is done.



Nicolas



On Feb 21, 2012, at 20:10 , Derakon wrote:

> On Fri, Feb 17, 2012 at 1:44 PM, Derakon <de...@gm...> wrote:
>> 
>> That did it! I have working false-color now; all that remains is to
>> integrate it into the rest of my program.
> 
> I've run into some implementation issues now that I'm not dealing with
> idealized data. My image data is using the GL_SHORT datatype (16-bit
> int). It can actually need anywhere from the full range to only 8 bits
> or so, and needs to display properly in all situations. I'm trying to
> deal with two things:
> 
> 1) I want the false coloration to be able to use the actual range in
> the data, as opposed to being locked to using 0 as the minimum and
> 2^15 - 1 as the maximum.
> 2) I want to be able to adjust the coloration on the fly, changing
> where the min and max are (which would mean that more pixels would be
> "off the end" of the spectrum). This is necessary to enhance contrast
> in many situations.
> 
> I figured this should be doable by modifying the fragment shader:
> 
>        uniform sampler2D texture;
>        uniform sampler1D color_lut;
>        uniform vec2 scaling;
>        void main() {
>            vec2 uv = gl_TexCoord[0].xy;
>            vec4 color = texture2D(texture, uv);
>            gl_FragColor = texture1D(color_lut,
>                min(.9999999, max(0, (color.a + scaling.x) * scaling.y)));
>        }
> 
> The "scaling" vec2 includes an offset and a scaling factor that should
> let me set the effective minimum (displayed as blue) and maximum
> (displayed as red) values in the texture.
> 
> I set scaling.x to 0 and scaling.y to
> (2 ** 16 - 1) / float(self.imageData.max() - self.imageData.min())
> That gives the following image:
> http://derakon.dyndns.org/~chriswei/temp2/auto.png
> 
> Then I applied the same scaling factor directly to the data before
> calling glTexSubImage2D, and left scaling as [0, 1], giving the
> following result:
> http://derakon.dyndns.org/~chriswei/temp2/manual.png
> 
> What I'm finding is that applying scaling in the shader gives much
> worse color resolution than if I manually scale the image -- auto.png
> only has two colors in it, while manual.png has many more. My values
> are also inverted for some reason, but I'm less worried about that.
> 
> What am I doing wrong?
> 
> -Chris
> 
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users

Re: [PyOpenGL-Users] Difficulty with the shaders tutorial

[Derakon <de...@gm...>]

On Fri, Feb 17, 2012 at 1:44 PM, Derakon <de...@gm...> wrote:
>
> That did it! I have working false-color now; all that remains is to
> integrate it into the rest of my program.

I've run into some implementation issues now that I'm not dealing with
idealized data. My image data is using the GL_SHORT datatype (16-bit
int). It can actually need anywhere from the full range to only 8 bits
or so, and needs to display properly in all situations. I'm trying to
deal with two things:

1) I want the false coloration to be able to use the actual range in
the data, as opposed to being locked to using 0 as the minimum and
2^15 - 1 as the maximum.
2) I want to be able to adjust the coloration on the fly, changing
where the min and max are (which would mean that more pixels would be
"off the end" of the spectrum). This is necessary to enhance contrast
in many situations.

I figured this should be doable by modifying the fragment shader:

        uniform sampler2D texture;
        uniform sampler1D color_lut;
        uniform vec2 scaling;
        void main() {
            vec2 uv = gl_TexCoord[0].xy;
            vec4 color = texture2D(texture, uv);
            gl_FragColor = texture1D(color_lut,
                min(.9999999, max(0, (color.a + scaling.x) * scaling.y)));
        }

The "scaling" vec2 includes an offset and a scaling factor that should
let me set the effective minimum (displayed as blue) and maximum
(displayed as red) values in the texture.

I set scaling.x to 0 and scaling.y to
(2 ** 16 - 1) / float(self.imageData.max() - self.imageData.min())
That gives the following image:
http://derakon.dyndns.org/~chriswei/temp2/auto.png

Then I applied the same scaling factor directly to the data before
calling glTexSubImage2D, and left scaling as [0, 1], giving the
following result:
http://derakon.dyndns.org/~chriswei/temp2/manual.png

What I'm finding is that applying scaling in the shader gives much
worse color resolution than if I manually scale the image -- auto.png
only has two colors in it, while manual.png has many more. My values
are also inverted for some reason, but I'm less worried about that.

What am I doing wrong?

-Chris

Re: [PyOpenGL-Users] PyOpenGL on 64bit Windows

[Derakon <de...@gm...>]

On Fri, Feb 17, 2012 at 1:38 PM, Jens Nellesen
<jen...@un...> wrote:
> Hi all,
>
> I cannot get PyOpenGL working on 64 bit Windows (Win XP and 7).

Well, I know it's possible, at least on Win7, because I have a working
install of it. Judging from your error, you have a 32-bit/64-bit
mismatch somewhere, so double-check that you have 64-bit versions of
Python, numpy, and PyOpenGL. You can't mix and match here; if you have
32-bit Python then you have to use all 32-bit libraries, and 64-bit
Python can't load 32-bit libraries (IIRC).

-Chris

[PyOpenGL-Users] PyOpenGL on 64bit Windows

[Jens N. <jen...@un...>]

Hi all,

I cannot get PyOpenGL working on 64 bit Windows (Win XP and 7).

In both cases I get the following import error:

Python 2.7.2 (default, Jun 12 2011, 14:24:46) [MSC v.1500 64 bit (AMD64)]
on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from OpenGL.GL import *
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "c:\python27\lib\site-packages\OpenGL\GL\__init__.py", line 3, in
<module>
    from OpenGL.GL.VERSION.GL_1_1 import *
  File "c:\python27\lib\site-packages\OpenGL\GL\VERSION\GL_1_1.py", line
10, in <module>
    from OpenGL import platform, constants, constant, arrays
  File "c:\python27\lib\site-packages\OpenGL\platform\__init__.py", line
35, in <module>
    _load()
  File "c:\python27\lib\site-packages\OpenGL\platform\__init__.py", line
26, in _load
    plugin_class = plugin.load()
  File "c:\python27\lib\site-packages\OpenGL\plugins.py", line 14, in load
    return importByName( self.import_path )
  File "c:\python27\lib\site-packages\OpenGL\plugins.py", line 28, in
importByName
    module = __import__( ".".join(moduleName), {}, {}, moduleName)
  File "c:\python27\lib\site-packages\OpenGL\platform\win32.py", line 13,
in <module>
    class Win32Platform( baseplatform.BasePlatform ):
  File "c:\python27\lib\site-packages\OpenGL\platform\win32.py", line 22,
in Win32Platform
    raise ImportError("Unable to load OpenGL library", *err.args)
ImportError: ('Unable to load OpenGL library', 193, '%1 is not a valid
Win32 application', 'C:\\WIND
OWS\\SysWOW64\\opengl32.dll', 'C:\\WINDOWS\\SysWOW64\\opengl32.dll')

Can anyone tell me what's wrong with my installation?

Kind regards,
Jens
PS: I tried PyPI, easy_install and the PyOpenGL-package bundled on
http://www.lfd.uci.edu/~gohlke/pythonlibs/
but without success.

Re: [PyOpenGL-Users] Difficulty with the shaders tutorial

[Derakon <de...@gm...>]

On Fri, Feb 17, 2012 at 12:39 AM, Nicolas Rougier
<Nic...@in...> wrote:
>
>
> No need to go for OpenGL 3.0 to use shaders.
>
> Here is code that do what you want (translated from glumpy):
>
> Color are transformed using the alpha channel of the image (see fragment code) and the color lookup table is a 1d texture. Fill it with any color sequence you want.
>
> Nicolas
>

That did it! I have working false-color now; all that remains is to
integrate it into the rest of my program.

For what it's worth, the color sequence I used does the following
ramps (percentages indicate distance along the texture):

Red: 0 at 35% to 1 at 67%, held through to 86%, down to .5 at 100%
Green: 0 at 10% to 1 at 39%, held through to 61%, down to 0 at 90%
Blue: .5 at 0% to 1 at 10%, held through to 31%, down tot 0 at 65%

This starts at dark blue, then goes to cyan, green, yellow, orange,
red. I got the percentages by manually examining the output of using
matplotlib's savefig function.

-Chris

Re: [PyOpenGL-Users] Difficulty with the shaders tutorial

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

No need to go for OpenGL 3.0 to use shaders.

Here is code that do what you want (translated from glumpy):

Color are transformed using the alpha channel of the image (see fragment code) and the color lookup table is a 1d texture. Fill it with any color sequence you want.

Nicolas

Re: [PyOpenGL-Users] Difficulty with the shaders tutorial

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

On Thu, Feb 16, 2012 at 12:09 PM, Derakon <de...@gm...> wrote:

> On further investigation, those functions weren't available because I
> didn't have an OpenGL context yet. My bad. Moving the set-up to later
> on in the program (the first paint call) instead gives these errors:
>
> RuntimeError: ('Shader compile failure (0): 0(3) : error C7533: global
> variable gl_ModelViewProjectionMatrix is deprecated after version
> 120\n0(3) : error C7533: global variable gl_Vertex is deprecated after
> version 120\n', ['#version 330\n            void main() {\n
>    gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;\n
>  }'], GL_VERTEX_SHADER)
>
> Feel free to correct me, but it looks like this means that the
> tutorial is using deprecated concepts? GL_VERSION is 3.3.0 and
> GL_SHADER_VERSION is "3.30 NVIDIA via Cg compiler", for what it's
> worth.

In later versions of OpenGL, the hardware matrix support was dropped.  I
think this is a mistake.  But the practical upshot is, to make your code
work, try using something like "#version 120" or something.
Ian