pyopengl-users — Discussion of all PyOpenGL matters.

Re: [PyOpenGL-Users] llvmpipe and PyOpenGL

[Cyrille R. <cyr...@gm...>]

Thanks, it seems to work on Ubuntu 12.04! I just had to set
LD_LIBRARY_PATH after building llvmpipe.

Cyrille


2013/11/29 Mike C. Fletcher <mcf...@vr...>:
> On 13-11-29 07:46 AM, Cyrille Rossant wrote:
>> Hi,
>>
>> How difficult would it be to have PyOpenGL support a software
>> rasterizer like llvmpipe? Usecases would include computers with old
>> graphics cards/drivers and painless remote control of PyOpenGL-based
>> software.
>
> If I'm understanding the mechanics of the project (llvmpipe) correctly,
> it may "just work" out of the box... basically the function:
>
>      ctypes.util.find_library( 'GL' )
>
> (which is sitting underneath all of the platform machinery) needs to
> find your llvmpipe GL library, which might very well just work if you
> set LD_LIBRARY_PATH to the correct value (as documented in llvmpipe)
> before running PyOpenGL.
>
> If it *doesn't* work, you could trivially replicate the
> OpenGL/platform/glx.py module (for testing) to see if you can get the
> library to load (let me know what you have to do to get it working, as
> this should "just work" IMO).  Once loaded you *should* (if I understand
> how llvmpipe works) just be able to use it as a regular driver running
> inside whatever GUI library (or offline pbuffer library) you want to use
> in order to test it.
>
> Hope that helps,
> Mike
>
>
> --
> ________________________________________________
>    Mike C. Fletcher
>    Designer, VR Plumber, Coder
>    http://www.vrplumber.com
>    http://blog.vrplumber.com
>
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users

Re: [PyOpenGL-Users] llvmpipe and PyOpenGL

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

On 13-11-29 07:46 AM, Cyrille Rossant wrote:
> Hi,
>
> How difficult would it be to have PyOpenGL support a software
> rasterizer like llvmpipe? Usecases would include computers with old
> graphics cards/drivers and painless remote control of PyOpenGL-based
> software.

If I'm understanding the mechanics of the project (llvmpipe) correctly, 
it may "just work" out of the box... basically the function:

     ctypes.util.find_library( 'GL' )

(which is sitting underneath all of the platform machinery) needs to 
find your llvmpipe GL library, which might very well just work if you 
set LD_LIBRARY_PATH to the correct value (as documented in llvmpipe) 
before running PyOpenGL.

If it *doesn't* work, you could trivially replicate the 
OpenGL/platform/glx.py module (for testing) to see if you can get the 
library to load (let me know what you have to do to get it working, as 
this should "just work" IMO).  Once loaded you *should* (if I understand 
how llvmpipe works) just be able to use it as a regular driver running 
inside whatever GUI library (or offline pbuffer library) you want to use 
in order to test it.

Hope that helps,
Mike


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

[PyOpenGL-Users] llvmpipe and PyOpenGL

[Cyrille R. <cyr...@gm...>]

Hi,

How difficult would it be to have PyOpenGL support a software
rasterizer like llvmpipe? Usecases would include computers with old
graphics cards/drivers and painless remote control of PyOpenGL-based
software.

Thanks,
Cyrille

[PyOpenGL-Users] funny return format of glGetTexImage

[Patrick D. <pyo...@pd...>]

Hi all,

using glGetTexImageI have noticed two bugs:

1.
according to the documentation the return value should always be an 
array if
OpenGL.UNSIGNED_BYTE_IMAGES_AS_STRING == False
which is not the case: OpenGL.UNSIGNED_BYTE_IMAGES_AS_STRING seems to be 
ignored completely and
with type=GL_UNSIGNED_BYTE and the default for outputType a string is 
returned. Setting outputType=None returns an array.

2.
image = glGetTexImage( GL_TEXTURE_RECTANGLE, level=0, format=GL_RGBA, 
format, type=GL_UNSIGNED_BYTE, outputType=None )
print "\timage:", type(image), image.shape, image.dtype

prints
     image: <type 'numpy.ndarray'> (472L, 575L, 1L, 4L) uint8

(for format=GL_RGB the shape is (472L, 575L, 1L, 3L) )

In addition to the unused dimension 2 of the array, width and height are 
mixed up.
My workaround is:

image.shape = (image.shape[1], image.shape[0], image.shape[3])

which creates an image that looks fine apart from being mirrored along 
the horizontal axis.
So to save it to disk, I do:
im = PIL.Image.fromarray(image_data)
im = im.transpose(PIL.Image.FLIP_TOP_BOTTOM)
im.save('test.png', format="PNG")

Regards,
Patrick

[PyOpenGL-Users] glDrawElements access violation when passed numpy array

[Keith C S. <kc...@ra...>]

I added the optional pyopengl_accelerate 3.0.2 module and the access
violation seems to have gone away?

[PyOpenGL-Users] glDrawElements access violation when passed numpy array

[Keith C S. <kc...@ra...>]

I'm using visvis for plotting scientific data as triangular facets.
visvis generates several windows.  When I interact (rotate, zoom)  with the
windows I eventual
get intermittent access violations when generating meshes.  self._faces is
a numpy  UINT32 array

I see this behavior on several workstations with Nivida card running
Windows XP and Windows 7

 File "C:\Users\~\Python33\lib\site-packages\visvis\wobjects
\polygonalModeling.py", line 1086, in _Draw
    gl.glDrawElements(type, N, face_dtype, self._faces)
  File "C:\Users\~\Python33\lib\site-packages\OpenGL\latebind.py", line 41,
in __call__
    return self._finalCall( *args, **named )
  File "C:\Users\~\Python33\lib\site-packages\OpenGL\wrapper.py", line 765,
in wrapperCall
    result = self.wrappedOperation( *cArguments )
OSError: exception: access violation reading 0xFFFFFFFC07536F1C


Have tried replacing "gl.glDrawElements(type, N, face_dtype, self._faces)"
with "gl.glDrawElements(type, N, face_dtype, self._faces.ctypes.data_as
(ctypes.POINTER(ctypes.c_long)))".  Seems to crash less on Windows 7, but
no change on Windows XP.

I also tried using VBOs
            self.indexPositions.bind()
            self.vertexPositions.bind()
            gl.glEnableVertexAttribArray(0);
            gl.glVertexAttribPointer(0, 3, gl.GL_FLOAT, False, 0, None)
            gl.glDrawElements(type, N, face_dtype, None

Didn't seem to crash on Windows 7, but messes up visvis labels, shading,
etc.

Windows 7:
Python 3.3.2
visvis 1.8
pyOpenGL 3.0.2
Graphic Adapter: Nivida Quadro 4000, driver 297.03

Also crashes in same way on two other Windows XP workstations with Nivida
cards.

Does  anyone have similar experiences and know of possible solutions?

thanks
Keith

Re: [PyOpenGL-Users] A little help with blending and glx

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

On 13-09-18 03:54 AM, Oly wrote:
> I have the example code below, simplified from a larger project. I 
> have been trying to make alpha channels work i have enabled blending 
> and written a similar example using pygame which works. How ever 
> setting up opengl to work with a glx context seems to stop blending 
> from working, i have a feeling i need to enabel some parameter to the 
> gl context setup but have not been able to find out what that 
> parameter is.
>
> Any suggestions on why this is not working, i have tried on two 
> different machines one with high end radeon and another with an intel 
> graphics card both do the same however.
>
> http://pastebin.com/vTDspSwp
>
> Any help would be most appreciated.

So it really doesn't seem to be *blending* that's the problem here, it's 
just that you're not getting a GL context set up at all?  I note that 
the following functions:

XDISPLAY_POINTER = ctypes.POINTER( struct__XDisplay )
...
         self.display = GdkX11.x11_get_default_xdisplay()
         self.xscreen = GdkX11.x11_get_default_screen()

         self.xdisplay = ctypes.cast( hash(self.display), XDISPLAY_POINTER )

are there, and seem to work, but glXChooseVisual always returns None on 
my machine, which the docs suggest is due to an unrecognized attribute 
in the attribute list.

Afraid I haven't much more to go on.  This *looks* like it's something 
simple going wrong, but I don't see it immediately.

Good luck,
Mike

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

[PyOpenGL-Users] A little help with blending and glx

[Oly <ol...@gm...>]

I have the example code below, simplified from a larger project. I have
been trying to make alpha channels work i have enabled blending and written
a similar example using pygame which works. How ever setting up opengl to
work with a glx context seems to stop blending from working, i have a
feeling i need to enabel some parameter to the gl context setup but have
not been able to find out what that parameter is.

Any suggestions on why this is not working, i have tried on two different
machines one with high end radeon and another with an intel graphics card
both do the same however.

http://pastebin.com/vTDspSwp

Any help would be most appreciated.

[PyOpenGL-Users] Raise window to top?

[Qingnan Z. <qn...@gm...>]

Dear all,

This is probably an easy question, but I couldn't find answers on google.

It is slightly annoying that new PyOpenGL windows are always created behind
my maximized terminal window in Mac.  I have to Command-Tab to the Python
window to view the contents.  For instance, all examples in PyOpenGL demo (
https://pypi.python.org/pypi/PyOpenGL-Demo) creates window that is not
automatically raised to the top.  Is there a way to fix that?  Thanks in
advance!

best,
James

Re: [PyOpenGL-Users] Format of New glReadPixels

[Ian M. <ia...@ge...>]

On Mon, Jul 8, 2013 at 7:24 AM, Mike C. Fletcher <mcf...@vr...>wrote:

>  > Is there a workaround available for current implementations?
> You can pass the array in explicitly (param array), then convert it on
> output (.tostring() for numpy).  If you have numpy installed and the
> code isn't picking it up, then we have another failure case :( .  You
> could also just copy the wrapper function from bzr into your code, it's
> just a regular python function wrapper; however, if you have numpy, then
> it should have picked that up as your default output array format
> (generic preferences are numpy, numeric, ctypesarrays, and since *noone*
> has Numeric any more, that's just numpy or ctypes arrays).
>
> You can *explicitly* set your preferred handler with
> OpenGL.arrays.arraydatatype.ArrayDatatype.registerReturn( 'numpy' ), but
> since that's the default anyway, it *shouldn't* make a difference, and
> it will still try the others if it can't find your preferred format.
>
> My guess is that numpy isn't importable/usable, and you fell through to
> the ctypes arrays. If not, we need to spelunk.
>
The numpy on my machine is seriously broken--which might be due to a
nonstandard Python setup. I'm on Windows, and all the Pythons wanted to
install themselves to the registry in the same place. I fussed around with
it a while ago, and now double-clicking on a file runs it with Python 2.7,
while IDLE is Python 3.3. In fact, if I recall correctly, the NumPy
installers that come for Windows couldn't find *any* Python on the computer
at all, nor would they let me tell them where it was. I was annoyed about
the whole thing, but didn't (and still don't) have time to untangle the
mess.

May I recommend a feature to convert the result directly to a Python string
or something for those of us without NumPy?

 HTH,
> Mike
>
Thanks,
Ian

Re: [PyOpenGL-Users] [PyOpenGL-Devel] Plan to remove Numeric support (not numpy, Numeric)

[Chris B. - N. F. <chr...@no...>]

On Wed, Jul 17, 2013 at 9:25 PM, Mike C. Fletcher
<mcf...@vr...> wrote:

>> What would be really nice is to support memoryviews (i.e. PEP 3118
>> buffers) directly, and maybe even be able to remove direct numpy
>> support....

> I started work on this quite a while ago, but ReleaseBuffers in my tests
> always wound up producing glibc segfaults, and I just never got back to
> it. If someone feels like hacking on it, the code is in
> OpenGL/arrays/_buffers.py with the FormatHandler in buffers.py

I was messing with the the other day for another application, and had
the same issues. Hopefully I''ll get a chance to figure it out
(consulting with the Cython folks...). If/when I do I"ll let you know.

-Chris



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

Re: [PyOpenGL-Users] [PyOpenGL-Devel] Plan to remove Numeric support (not numpy, Numeric)

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

On 13-07-15 11:21 AM, Chris Barker - NOAA Federal wrote:
> On Mon, Jul 15, 2013 at 7:51 AM, Chris Weisiger <cwe...@ms...> wrote:
>> I got PyOpenGL working just fine with Numpy on WinXP 64-bit without any
>> significant difficulties that I can recall. Win7 64-bit was similarly
>> trivial. I see no reason why Numeric support should be continued just
>> because of 64-bit concerns.
> Agreed. And Mike, you are quite right, Numeric is even more poorly
> supported on Win64.
>
> What would be really nice is to support memoryviews (i.e. PEP 3118
> buffers) directly, and maybe even be able to remove direct numpy
> support....
I started work on this quite a while ago, but ReleaseBuffers in my tests 
always wound up producing glibc segfaults, and I just never got back to 
it. If someone feels like hacking on it, the code is in 
OpenGL/arrays/_buffers.py with the FormatHandler in buffers.py

Enjoy,
Mike

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

Re: [PyOpenGL-Users] [PyOpenGL-Devel] Plan to remove Numeric support (not numpy, Numeric)

[Chris B. - N. F. <chr...@no...>]

On Mon, Jul 15, 2013 at 7:51 AM, Chris Weisiger <cwe...@ms...> wrote:
> I got PyOpenGL working just fine with Numpy on WinXP 64-bit without any
> significant difficulties that I can recall. Win7 64-bit was similarly
> trivial. I see no reason why Numeric support should be continued just
> because of 64-bit concerns.

Agreed. And Mike, you are quite right, Numeric is even more poorly
supported on Win64.

What would be really nice is to support memoryviews (i.e. PEP 3118
buffers) directly, and maybe even be able to remove direct numpy
support....

-Chris



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

Re: [PyOpenGL-Users] [PyOpenGL-Devel] Plan to remove Numeric support (not numpy, Numeric)

[Chris W. <cwe...@ms...>]

I got PyOpenGL working just fine with Numpy on WinXP 64-bit without any
significant difficulties that I can recall. Win7 64-bit was similarly
trivial. I see no reason why Numeric support should be continued just
because of 64-bit concerns.

-Chris


On Sun, Jul 14, 2013 at 7:28 PM, Mike C. Fletcher <mcf...@vr...>wrote:

> On 13-07-14 06:42 PM, Tcll wrote:
> > just giving my input on this...
> > I think this would harshly affect x64 users, as NumPy doesn't have an
> x64 build.
> >
> > I havn't checked to see if Numeric does or not,
> > but I just think it would be better to leave it UNTIL NumPy has an x64
> build ;)
> I'm not sure what you're saying precisely:
>
>   * by x64, I'm guessing you mean Win64?
>       o there's definitely NumPy available on x64 Linux and OSX
>         platforms (I use x64 Linux as my primary)
>       o there are unofficial Numpy builds for Win64 on the unofficial
>         Win64 python builds page
>           + http://www.lfd.uci.edu/~gohlke/pythonlibs/#numpy
>             <http://www.lfd.uci.edu/%7Egohlke/pythonlibs/#numpy>
>       o my understanding is that the Win64 issues is down to the lack of
>         a suitable free Fortran compiler with which to do the
>         compilation (though that's just hearsay)
>   * Numeric is *ancient*, the chance that *it* has been ported to Win64
>     seems remote
>       o I see no binary releases for Win64 at all in Numeric
>       o it's last binary release was made for python 2.4 (which we don't
>         support in PyOpenGL anyway) in 2005
>       o The next release of PyOpenGL likely should just target 2.6+, to
>         make the code base cleanly modernized
>
> If you're saying "nothing should change in PyOpenGL until numpy has an
> x64 build"... it doesn't really seem like a compelling argument to me.
>
> List copied, in case there are others who feel strongly on this point,
> Mike
>
> --
> ________________________________________________
>    Mike C. Fletcher
>    Designer, VR Plumber, Coder
>    http://www.vrplumber.com
>    http://blog.vrplumber.com
>
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>

Re: [PyOpenGL-Users] [PyOpenGL-Devel] Plan to remove Numeric support (not numpy, Numeric)

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

On 13-07-14 06:42 PM, Tcll wrote:
> just giving my input on this...
> I think this would harshly affect x64 users, as NumPy doesn't have an x64 build.
>
> I havn't checked to see if Numeric does or not,
> but I just think it would be better to leave it UNTIL NumPy has an x64 build ;)
I'm not sure what you're saying precisely:

  * by x64, I'm guessing you mean Win64?
      o there's definitely NumPy available on x64 Linux and OSX
        platforms (I use x64 Linux as my primary)
      o there are unofficial Numpy builds for Win64 on the unofficial
        Win64 python builds page
          + http://www.lfd.uci.edu/~gohlke/pythonlibs/#numpy
            <http://www.lfd.uci.edu/%7Egohlke/pythonlibs/#numpy>
      o my understanding is that the Win64 issues is down to the lack of
        a suitable free Fortran compiler with which to do the
        compilation (though that's just hearsay)
  * Numeric is *ancient*, the chance that *it* has been ported to Win64
    seems remote
      o I see no binary releases for Win64 at all in Numeric
      o it's last binary release was made for python 2.4 (which we don't
        support in PyOpenGL anyway) in 2005
      o The next release of PyOpenGL likely should just target 2.6+, to
        make the code base cleanly modernized

If you're saying "nothing should change in PyOpenGL until numpy has an 
x64 build"... it doesn't really seem like a compelling argument to me.

List copied, in case there are others who feel strongly on this point,
Mike

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

Re: [PyOpenGL-Users] Plan to remove Numeric support (not numpy, Numeric)

[Matt W. <li...@mi...>]

On 11 July 2013 05:43, Mike C. Fletcher <mcf...@vr...> wrote:
> Hi all,
>
> I seriously doubt this will affect anyone, but just a heads-up that I'm
> planning to remove Numeric array support from PyOpenGL and
> OpenGLContext.  Note, *numpy* support will remain, this is the
> incredibly ancient long-since-deprecated Numeric module that no-one has
> used for ages and ages (and I doubt it's even compatible with modern
> Pythons, for that matter).  The only reason to remove it is to reduce
> the amount of maintenance and streamline some code paths.

Sounds like a good idea to me. Anything that can make maintainence
easier has got to be a good thing.

Matt

[PyOpenGL-Users] Plan to remove Numeric support (not numpy, Numeric)

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

Hi all,

I seriously doubt this will affect anyone, but just a heads-up that I'm 
planning to remove Numeric array support from PyOpenGL and 
OpenGLContext.  Note, *numpy* support will remain, this is the 
incredibly ancient long-since-deprecated Numeric module that no-one has 
used for ages and ages (and I doubt it's even compatible with modern 
Pythons, for that matter).  The only reason to remove it is to reduce 
the amount of maintenance and streamline some code paths.

Enjoy,
Mike

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

Re: [PyOpenGL-Users] coordinate system axes

[Ian M. <ia...@ge...>]

On Mon, Jul 1, 2013 at 6:39 AM, Jano Ferencik <fer...@gm...>wrote:

> Hello there,
>
> i am fairly new to pyopengl and I am facing some difficulties.
> I am trying to create a indicator for the global coordinate system in the
> corner of a glcanvas wndow. I managed to create the lines but I am not able
> to rotate them when the object rotates
> I suspect I am not isolating the transform matrices correctly.
>
> Currently I can see the cube and the coordinate system indicator but the
> latter is fixed when I rotate the cube. I would lie the indicator to rotate
> so it will be clear in which direction the object was rotated
>
> The code comes from a bunch of examples i found online a
>
You should probably find some better examples. I only skimmed the code, but
already I could see there's some very dodgy stuff there--initializing glut
every time you draw, the resize and view methods (ultimately from NeHe),
and just general stylistic things that tell me the author didn't really *get
* it (e.g. ".createCube(self)" does no such thing). The GUI part is
probably more okay, but honestly if you want my advice, redo the OpenGL
part entirely.

Amazingly, there's not a lot of great code demonstrating how to do this on
the web, but, at the risk of self-promotion, I do have an Introductory
OpenGL Tutorial<http://www.geometrian.com/programming/tutorials/introgl/index.php>that
would probably be very helpful for getting started with OpenGL 2 style
programs. It's written for C++/C99, but it's quite readable to Python
users. Once you understand the theory behind this stuff, you might
like my PyOpenGL
Base Code<http://www.geometrian.com/programming/tutorials/OpenGL%20Program%20Shell.py.txt>,
which is a well-tested, proven Python template for starting PyOpenGL code.
It requires PyGame, which works very nicely with PyOpenGL. Theoretically,
you could alter it to use GLUT, but you shouldn't be using that anyway.

Lastly, my suggestions for future help might point you to the forums at
GameDev.net, which has a special OpenGL board, lots of OpenGL-related
resources, and a generally faster turnaround time.

HTH,
Ian

Re: [PyOpenGL-Users] tutorial sources

[Andreas O. <or...@fi...>]

On 07/08/13 16:28, Mike C. Fletcher wrote:
> On 13-07-08 09:46 AM, Andreas Ortmann wrote:
>> Hello,
>>
>> where can I find the python sources for the tutorial on
>> http://pyopengl.sourceforge.net/context/tutorials/index.xhtml?
>>
>> At the bottom on that page it says:
>> "This code-walkthrough tutorial is generated from the shader_1.py script
>> in the OpenGLContext source distribution.".
>>
>> However I can not find a file 'shader_1.py' in the sources.
> The code is available online here:
>
> http://bazaar.launchpad.net/~mcfletch/openglcontext/trunk/view/head:/tests/shader_1.py
> <http://bazaar.launchpad.net/%7Emcfletch/openglcontext/trunk/view/head:/tests/shader_1.py>
>
> Or you can branch the repository if you have bzr installed:
>
>       bzr branch lp:openglcontext
>
> In the source code .tar.gz distribution it is in a parallel directory
> "tests" next to the "OpenGLContext" directory.
>
> Hope that helps,
> Mike
>
Thanks, thats nice.

Andreas

Re: [PyOpenGL-Users] tutorial sources

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

On 13-07-08 09:46 AM, Andreas Ortmann wrote:
> Hello,
>
> where can I find the python sources for the tutorial on
> http://pyopengl.sourceforge.net/context/tutorials/index.xhtml?
>
> At the bottom on that page it says:
> "This code-walkthrough tutorial is generated from the shader_1.py script
> in the OpenGLContext source distribution.".
>
> However I can not find a file 'shader_1.py' in the sources.
The code is available online here:

http://bazaar.launchpad.net/~mcfletch/openglcontext/trunk/view/head:/tests/shader_1.py 
<http://bazaar.launchpad.net/%7Emcfletch/openglcontext/trunk/view/head:/tests/shader_1.py>

Or you can branch the repository if you have bzr installed:

     bzr branch lp:openglcontext

In the source code .tar.gz distribution it is in a parallel directory 
"tests" next to the "OpenGLContext" directory.

Hope that helps,
Mike

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

Re: [PyOpenGL-Users] Format of New glReadPixels

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

On 13-07-07 06:56 PM, Ian Mallett wrote:
> On Fri, Jul 5, 2013 at 2:03 PM, Mike C. Fletcher 
> <mcf...@vr... <mailto:mcf...@vr...>> wrote:
>
>     > What is the return value format of glReadPixels?
>     Apparently ctypes arrays no longer have .raw attributes, so if you
>     don't
>     have numpy the object wasn't being converted to a string. Weird
>     thing is
>     I don't see any documentation on .raw on arrays, so it's possible
>     it was
>     just working by fluke-of-implementation before.  I've added code that
>     does the transformation of a ctypes array to the OpenGL/images.py
>     module
>     in bzr.
>
> This, I assume: 
> http://bazaar.launchpad.net/~mcfletch/pyopengl/trunk/revision/576 
> <http://bazaar.launchpad.net/%7Emcfletch/pyopengl/trunk/revision/576>
>
> Oddly, I theoretically do have NumPy, although my Python setup has 
> probably munged itself over several reinstalls.
>
> Is there a workaround available for current implementations?
You can pass the array in explicitly (param array), then convert it on 
output (.tostring() for numpy).  If you have numpy installed and the 
code isn't picking it up, then we have another failure case :( .  You 
could also just copy the wrapper function from bzr into your code, it's 
just a regular python function wrapper; however, if you have numpy, then 
it should have picked that up as your default output array format 
(generic preferences are numpy, numeric, ctypesarrays, and since *noone* 
has Numeric any more, that's just numpy or ctypes arrays).

You can *explicitly* set your preferred handler with 
OpenGL.arrays.arraydatatype.ArrayDatatype.registerReturn( 'numpy' ), but 
since that's the default anyway, it *shouldn't* make a difference, and 
it will still try the others if it can't find your preferred format.

My guess is that numpy isn't importable/usable, and you fell through to 
the ctypes arrays. If not, we need to spelunk.

HTH,
Mike

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

[PyOpenGL-Users] tutorial sources

[Andreas O. <or...@fi...>]

Hello,

where can I find the python sources for the tutorial on 
http://pyopengl.sourceforge.net/context/tutorials/index.xhtml?

At the bottom on that page it says:
"This code-walkthrough tutorial is generated from the shader_1.py script 
in the OpenGLContext source distribution.".

However I can not find a file 'shader_1.py' in the sources.

Grettings.

Re: [PyOpenGL-Users] Format of New glReadPixels

[Ian M. <ia...@ge...>]

On Fri, Jul 5, 2013 at 2:03 PM, Mike C. Fletcher <mcf...@vr...>wrote:

>  > What is the return value format of glReadPixels?
> Apparently ctypes arrays no longer have .raw attributes, so if you don't
> have numpy the object wasn't being converted to a string. Weird thing is
> I don't see any documentation on .raw on arrays, so it's possible it was
> just working by fluke-of-implementation before.  I've added code that
> does the transformation of a ctypes array to the OpenGL/images.py module
> in bzr.
>
This, I assume:
http://bazaar.launchpad.net/~mcfletch/pyopengl/trunk/revision/576

Oddly, I theoretically do have NumPy, although my Python setup has probably
munged itself over several reinstalls.

Is there a workaround available for current implementations?

HTH,
> Mike
>
Thanks,
Ian

Re: [PyOpenGL-Users] Format of New glReadPixels

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

On 13-06-29 06:44 PM, Ian Mallett wrote:
> Hi,
>
> The return value of glReadPixels seems to have changed since Py 2.5. 
> To take a screenshot, one used to be able to go:
> data = glReadPixels(0,0,screen_size[0],screen_size[1], GL_RGB, 
> GL_UNSIGNED_BYTE)
> image = pygame.image.fromstring(data,screen_size,"RGBA",True)
> pygame.image.save(image,"screenshot.png")
>
> This doesn't work anymore. It returns some data type that seems to 
> encapsulate a 3D array. I wasn't able to track down where this 
> datatype was defined. My best effort to reverse engineer it was 
> unsuccessful (the output is garbled):
> data = glReadPixels(0,0,screen_size[0],screen_size[1], GL_RGB, 
> GL_UNSIGNED_BYTE)
> r,g,b = data[0],data[1],data[2]
> image = pygame.Surface(screen_size)
> for y in range(screen_size[1]):
>     for x in range(screen_size[0]):
> image.set_at((x,screen_size[1]-y-1),(r[y][x],g[y][x],b[y][x]))
> pygame.image.save(image,"screenshot.png")
>
> What is the return value format of glReadPixels?
Apparently ctypes arrays no longer have .raw attributes, so if you don't 
have numpy the object wasn't being converted to a string. Weird thing is 
I don't see any documentation on .raw on arrays, so it's possible it was 
just working by fluke-of-implementation before.  I've added code that 
does the transformation of a ctypes array to the OpenGL/images.py module 
in bzr.

HTH,
Mike

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

[PyOpenGL-Users] coordinate system axes

[Jano F. <fer...@gm...>]

Hello there,

i am fairly new to pyopengl and I am facing some difficulties.
I am trying to create a indicator for the global coordinate system in the
corner of a glcanvas wndow. I managed to create the lines but I am not able
to rotate them when the object rotates
I suspect I am not isolating the transform matrices correctly.

Currently I can see the cube and the coordinate system indicator but the
latter is fixed when I rotate the cube. I would lie the indicator to rotate
so it will be clear in which direction the object was rotated

The code comes from a bunch of examples i found online a


Thanks in advance!


I should mention I subclassed glcanvas

class PHLVGLCanvas(glcanvas.GLCanvas):
def __init__(self, parent, attribs):
glcanvas.GLCanvas.__init__(self, parent, -1, attribList=attribs)
self.init = False
self.context = glcanvas.GLContext(self)
self.axes = True
self.width, self.height = self.GetSize()
self.alpha = 0
self.beta = 0
self.distance = 5.0
self.oldX = 0
self.oldY = 0
self.leftDown = False
self.rightDown = False
self.middleDown = False
self.xTrans = 0.
self.yTrans = 0.
self.turn, self.tip = 0, 0
#bind events
self.Bind(wx.EVT_SIZE, self.OnResize)
self.Bind(wx.EVT_PAINT, self.OnPaint)
hlev = hlmec(self, dragThreshPixel = 15)
## hlev.setOnHLVLeftDown(self.OnLeftDown)
## hlev.setOnHLVLeftUp(self.OnLeftUp)
hlev.setOnHLVMouseScroll(self.OnMouseScroll)
## hlev.setOnHLVLeftDClick(self.onHLVLeftDClick)
## hlev.setOnHLVLeftStartDragging(self.onHLVLeftStartDragging)
hlev.setOnHLVLeftDragging(self.OnLeftDragging)
## hlev.setOnHLVLeftEndDragging(self.onHLVLeftEndDragging)
hlev.setOnHLVMiddleDown(self.onMiddleDown)
## hlev.setOnHLVMiddleUp(self.onHLVMiddleUp)
## hlev.setOnHLVMiddleDClick(self.onHLVMiddleDClick)
## hlev.setOnHLVMiddleStartDragging(self.onMiddleStartDragging)
hlev.setOnHLVMiddleDragging(self.OnPan)
## hlev.setOnHLVMiddleEndDragging(self.onMiddleEndDragging)
## hlev.setOnHLVRightDown(self.onRightDown)
## hlev.setOnHLVRightUp(self.onHLVRightUp)
## hlev.setOnHLVRightDClick(self.onHLVRightDClick)
## hlev.setOnHLVRightStartDragging(self.onHLVRightStartDragging)
## hlev.setOnHLVRightDragging(self.OnPan)
## hlev.setOnHLVRightEndDragging(self.onHLVRightEndDragging)
## hlev.setOnHLVMotion(self.OnMotion)
## hlev.setOnHLVEnterWindow(self.onHLVEnterWindow)
## hlev.setOnHLVLeaveWindow(self.onHLVLeaveWindow)


#-----------------------------------------------------------------------------------------------

def ChangeView(self):
glMatrixMode(GL_MODELVIEW)
glLoadIdentity()
glTranslate(self.xTrans/100, -self.yTrans/100, -self.distance)
#print 'stranslated ', self.xTrans, self.yTrans
glRotate(-90, 0.0, 1.0, 0.0)
glRotate(-90, 1.0, 0.0, 0.0)
glRotate(self.alpha, 1.0, 0.0, 1.0)
glRotate(self.beta, 0.0, 1.0, 0.0)
self.OnDraw()


def OnPaint(self, event):
dc = wx.PaintDC(self)
self.SetCurrent(self.context)
if not self.init:
self.InitGL()
self.init = True
self.OnDraw()

def Resize(self):
ratio = float(self.width) / self.height;
glMatrixMode(GL_PROJECTION)
glLoadIdentity()
glViewport(0, 0, self.width, self.height)
gluPerspective(45, ratio, 1, 1000)
self.ChangeView()





#-----------------------------------------------------------------------------------------------
def OnResize(self, e):
w, h = e.GetSize() # guards for width and height
if w:
self.width = w
if h:
self.height = h
self.Resize()

def OnMouseScroll(self, event):
self.SetCursor(wx.StockCursor(wx.CURSOR_MAGNIFIER))
rotation = event.GetWheelRotation()
self.distance -= rotation * 0.0099
   self.ChangeView()

def OnLeftDragging(self, event):
self.SetCursor(wx.StockCursor(wx.CURSOR_SIZING))
X, Y = event.GetPosition()
self.alpha += (X - self.oldX) * 0.5
self.beta += (Y - self.oldY) * 0.5
self.tip  += (X - self.oldX)
self.turn  += (Y - self.oldY)
self.ChangeView()
self.oldX, self.oldY = X, Y

def OnMotion(self, event):
self.SetCursor(wx.StockCursor(wx.CURSOR_ARROW))

def OnPan(self, event):
self.SetCursor(wx.StockCursor(wx.CURSOR_HAND))
if not isinstance(event, wx.MouseEvent):
return
X, Y = event.GetPosition()
#print 'X: %i, oldX: %i, Y: %i, oldY: %i, xTrans: %i, yTrans: %i' % (X,
self.oldX, Y, self.oldY, (X-self.oldX), (Y-self.oldY))
self.xTrans += (X - self.oldX)
self.yTrans += (Y - self.oldY)
self.ChangeView()
self.oldX = X
self.oldY = Y
#self.xTrans = self.yTrans = 0

def onMiddleDown(self, event):
self.oldX, self.oldY = event.GetPosition()




def onMiddleEndDragging(self, event):
self.SetCursor(wx.StockCursor(wx.CURSOR_ARROW))
print 'middle end dragging', self.xTrans, self.yTrans
self.xTrans =  self.yTrans = 0
#self.oldX, self.oldY = event.GetPosition()


def InitGL(self):

glLightfv(GL_LIGHT0, GL_DIFFUSE,  (0.8, 0.8, 0.8, 1.0))
glLightfv(GL_LIGHT0, GL_AMBIENT,  (0.2, 0.2, 0.2, 1.0))
glLightfv(GL_LIGHT0, GL_POSITION, (1.0, 1.0, 1.0, 0.0))
glEnable(GL_LIGHT0)
# glShadeModel(GL_SMOOTH)
glEnable(GL_LIGHTING)
glEnable(GL_DEPTH_TEST)
glClearColor(0.0, 0.0, 0.0, 1.0)
glClearDepth(1.0)
self.Resize()

def createCube(self):
glPushMatrix()
glLineWidth( 2.0 )
glBegin(GL_LINE_LOOP)
glNormal3f( 0.0, 0.0, 1.0)
glVertex3f( 0.5, 0.5, 0.5)
glVertex3f(-0.5, 0.5, 0.5)
glVertex3f(-0.5,-0.5, 0.5)
glVertex3f( 0.5,-0.5, 0.5)

glNormal3f( 0.0, 0.0,-1.0)
glVertex3f(-0.5,-0.5,-0.5)
glVertex3f(-0.5, 0.5,-0.5)
glVertex3f( 0.5, 0.5,-0.5)
glVertex3f( 0.5,-0.5,-0.5)

glNormal3f( 0.0, 1.0, 0.0)
glVertex3f( 0.5, 0.5, 0.5)
glVertex3f( 0.5, 0.5,-0.5)
glVertex3f(-0.5, 0.5,-0.5)
glVertex3f(-0.5, 0.5, 0.5)

glNormal3f( 0.0,-1.0, 0.0)
glVertex3f(-0.5,-0.5,-0.5)
glVertex3f( 0.5,-0.5,-0.5)
glVertex3f( 0.5,-0.5, 0.5)
glVertex3f(-0.5,-0.5, 0.5)

glNormal3f( 1.0, 0.0, 0.0)
glVertex3f( 0.5, 0.5, 0.5)
glVertex3f( 0.5,-0.5, 0.5)
glVertex3f( 0.5,-0.5,-0.5)
glVertex3f( 0.5, 0.5,-0.5)


glNormal3f(-1.0, 0.0, 0.0)
glVertex3f(-0.5,-0.5,-0.5)
glVertex3f(-0.5,-0.5, 0.5)
glVertex3f(-0.5, 0.5, 0.5)
glVertex3f(-0.5, 0.5,-0.5)
glEnd()
glPopMatrix()



def OnDraw(self):
glutInit()
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT)

glMaterialfv(GL_FRONT, GL_AMBIENT_AND_DIFFUSE, (0.5, 0.5, 1.0, 1.0))
#glutSolidSphere(0.5, 20, 20)
#glutWireCube(1)
# draw six faces of a cube
self.createCube()
if self.axes:
glutInit()
self.ShowAxes()
   #self.createAxes()
self.SwapBuffers()


#-----------------------------------------------------------------------------------------------
def ShowAxes(self):
glPushMatrix()
glLoadIdentity()
  glTranslatef(-1, 2, -5)
glPushMatrix()
print 'turn %f, tip %f ' % (self.turn, self.tip)
glRotate(self.turn/100, 1, 0, 0)
glRotate(self.tip/100, 0, 1, 0)
glPopMatrix()
glDisable(GL_LIGHTING)
glColor3f(1.0, 1.0, 0.0)
glRasterPos3f(-3.8, -5.0, -5.0)
glutBitmapCharacter(GLUT_BITMAP_9_BY_15, ord('x'))
glRasterPos3f(-5.0, -3.8, -5.0)
glutBitmapCharacter(GLUT_BITMAP_9_BY_15, ord('y'))
glRasterPos3f(-5.0, -5.0, -3.8)
glutBitmapCharacter(GLUT_BITMAP_9_BY_15, ord('z'))
glRasterPos3f(-5.0, -5.0, -5.2)
glutBitmapCharacter(GLUT_BITMAP_9_BY_15, ord('0'))
glColor3f(1.0, 0.0, 0.0)
glBegin(GL_LINES)
glVertex3f(-5, -5, -5)
glVertex3f(-4, -5, -5)
#glVertex3f(1, 1, 0)
#glVertex3f(0, 1, 0)
glEnd()

glColor3f(0.0, 0.0, 1.0)
glBegin(GL_LINES)
glVertex3f(-5, -5, -5)
glVertex3f(-5, -5, -4)
#glVertex3f(0, 1, 1)
#glVertex3f(0, 1, 0)
glEnd()

glColor3f(0.0, 1.0, 0.0)
glBegin(GL_LINES)
glVertex3f(-5, -5, -5)
glVertex3f(-5, -4, -5)
#glVertex3f(1, 0, 1)
#glVertex3f(0, 0, 1)
glEnd()
glEnable(GL_LIGHTING)
glPopMatrix()