pyopengl-devel Mailing List for PyOpenGL
Brought to you by:
mcfletch
You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
(4) |
Nov
(9) |
Dec
(2) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(1) |
Feb
(6) |
Mar
(3) |
Apr
(5) |
May
(10) |
Jun
(6) |
Jul
(10) |
Aug
|
Sep
(3) |
Oct
(9) |
Nov
(20) |
Dec
(31) |
2003 |
Jan
(36) |
Feb
(44) |
Mar
(16) |
Apr
(35) |
May
(59) |
Jun
(17) |
Jul
(11) |
Aug
(14) |
Sep
(9) |
Oct
(29) |
Nov
(10) |
Dec
(5) |
2004 |
Jan
(17) |
Feb
(8) |
Mar
(6) |
Apr
(3) |
May
(4) |
Jun
(2) |
Jul
(42) |
Aug
(7) |
Sep
(17) |
Oct
(32) |
Nov
(7) |
Dec
(5) |
2005 |
Jan
(11) |
Feb
(11) |
Mar
(7) |
Apr
(8) |
May
(3) |
Jun
(3) |
Jul
(3) |
Aug
(5) |
Sep
|
Oct
(2) |
Nov
(5) |
Dec
(1) |
2006 |
Jan
(1) |
Feb
(2) |
Mar
(5) |
Apr
(6) |
May
(9) |
Jun
(6) |
Jul
(7) |
Aug
(8) |
Sep
(8) |
Oct
(23) |
Nov
(29) |
Dec
(5) |
2007 |
Jan
(4) |
Feb
(3) |
Mar
(7) |
Apr
(10) |
May
(7) |
Jun
(12) |
Jul
(4) |
Aug
(2) |
Sep
(2) |
Oct
(5) |
Nov
(6) |
Dec
(3) |
2008 |
Jan
(38) |
Feb
(10) |
Mar
(3) |
Apr
(13) |
May
(8) |
Jun
(12) |
Jul
(6) |
Aug
(3) |
Sep
(2) |
Oct
(7) |
Nov
(21) |
Dec
(1) |
2009 |
Jan
(7) |
Feb
(8) |
Mar
(4) |
Apr
(6) |
May
(4) |
Jun
(4) |
Jul
(38) |
Aug
(4) |
Sep
|
Oct
(3) |
Nov
(16) |
Dec
|
2010 |
Jan
(4) |
Feb
(17) |
Mar
(2) |
Apr
(6) |
May
(1) |
Jun
(4) |
Jul
(1) |
Aug
(2) |
Sep
(1) |
Oct
(10) |
Nov
(3) |
Dec
(8) |
2011 |
Jan
|
Feb
(2) |
Mar
|
Apr
(6) |
May
(3) |
Jun
(19) |
Jul
(6) |
Aug
(2) |
Sep
(5) |
Oct
|
Nov
(6) |
Dec
(6) |
2012 |
Jan
(8) |
Feb
(3) |
Mar
(26) |
Apr
(12) |
May
(2) |
Jun
(8) |
Jul
(6) |
Aug
(4) |
Sep
(1) |
Oct
(10) |
Nov
(5) |
Dec
(1) |
2013 |
Jan
(2) |
Feb
(5) |
Mar
(1) |
Apr
(3) |
May
(6) |
Jun
|
Jul
(7) |
Aug
|
Sep
(4) |
Oct
(1) |
Nov
(4) |
Dec
|
2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(6) |
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
(2) |
Nov
(1) |
Dec
(1) |
2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2016 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2017 |
Jan
|
Feb
(1) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2019 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Grzegorz B. <g.b...@uw...> - 2024-07-18 10:46:15
|
A short time ago, the NumPy 2.0 was released. Unfortunately, NumPy 2.0 is not binary compatible with packages compiled against NumPy 1.x. In contradiction, packages compiled against numpy 2.0 should be compatible with the previous NumPy release. Try to compile from source ends with error `src/numpy_formathandler.pyx:22:42: 'Py_intptr_t' is not a type identifier` Is it planned to create a new release compiled against numpy 2.0? Regards, Grzegorz Bokota PS. I'm one of cibuildwheel maintainers and if you use this tool and need to help feel free to ask. |
From: Mike C. F. <mcf...@vr...> - 2021-05-09 00:51:20
|
Best description for the project's status would be "far down my priority list". I seem to get around 1-2 days/year for PyOpenGL and related projects on average. With that I barely keep up with bug-fixes and new releases of the core library. Much of the porting work for OpenGLContext to Python3 is done, but the set of dependencies there is *far* deeper than PyOpenGL itself, and while they are slowly getting ported, the strong emphasis is on "slowly". My apologies to anyone finding the library somewhat run down. I'm afraid after 20+ years of maintenance on a project I don't actually use myself, my spark has died down to an ember. The amount of busy-work created by the Python3 porting just sucked the joy out, especially as the end result was worse than the original... I guess what I'm saying is while I do try to check into the project every once in a while, it's really only from a sense of duty than actual interest any more. Take care, Mike On 2021-05-08 8:36 a.m., Barak Korren wrote: > Hi, > > I've been trying to learn a bit about PyOpenGL and OpenGLContext and > the state of things does not seem to be encouraging. > While PyOpenGL is installable, OpenGLContext does not seem to be. > After a bit a of searching I managed to find the code in GitHub (The > docs referred me to LaunchPad and Bazaar which I really hope aren't > still being used), and the version there was at least installable, but > I quickly found out it contains a lot of what seems to be Python 3 > incompatible code. > > Bottom line is that I couldn't even get past the first tutorial. > > I guess I could roll my sleeves and hack a bit at OpenGLContext to at > least get the tutorials to work on Python 3, but would it be worth my > time? Is there anyone that is interested in keeping these projects > going? Given that the latest commits seem to have been made two years > ago I'm not so sure about that. > > (BTW, there is a PR on the GitHub repo that tries to fix one of the > issue I've seen as well) > > Regards, > Barak. > > > _______________________________________________ > PyOpenGL Homepage > http://pyopengl.sourceforge.net > _______________________________________________ > PyOpenGL-Devel mailing list > PyO...@li... > https://lists.sourceforge.net/lists/listinfo/pyopengl-devel -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
From: Barak K. <bar...@gm...> - 2021-05-08 12:37:06
|
Hi, I've been trying to learn a bit about PyOpenGL and OpenGLContext and the state of things does not seem to be encouraging. While PyOpenGL is installable, OpenGLContext does not seem to be. After a bit a of searching I managed to find the code in GitHub (The docs referred me to LaunchPad and Bazaar which I really hope aren't still being used), and the version there was at least installable, but I quickly found out it contains a lot of what seems to be Python 3 incompatible code. Bottom line is that I couldn't even get past the first tutorial. I guess I could roll my sleeves and hack a bit at OpenGLContext to at least get the tutorials to work on Python 3, but would it be worth my time? Is there anyone that is interested in keeping these projects going? Given that the latest commits seem to have been made two years ago I'm not so sure about that. (BTW, there is a PR on the GitHub repo that tries to fix one of the issue I've seen as well) Regards, Barak. |
From: Andrew P. L. <bs...@al...> - 2019-07-07 09:01:48
|
I can't seem to find a way to file a bug on the project. What is considered the most appropriate place to do so nowadays? Thanks, -a |
From: Mike C. F. <mcf...@vr...> - 2019-01-23 04:10:13
|
On 2019-01-19 6:42 p.m., Matthew Matl wrote: > Hi Mike, > > Big fan of PyOpenGL! Just wanted to offer this simple patch for the > most recent version of master, which adds a handle for OSMesa's > OSMesaCreateContextAttribs > <https://github.com/anholt/mesa/blob/01e511233b24872b08bff862ff692dfb5b22c1f4/include/GL/osmesa.h#L167> function. > This function allows for users to create OSMesa contexts with core > profiles, which is hugely useful for supporting offscreen rendering > with modern (>=3.3) shaders. > > My only concern is that this function is new in Mesa 11.2, which was > released on April 4, 2016, so this might not work with older Mesa > versions. Not sure if the compilation system will handle this smoothly > or not. Suggestions are welcome, happy to help modify this as needed. Hi Matthew, Thanks for the patch. It's merged to master. I've also filled in couple of other missing functions from my local osmesa.h file. There's no compilation system, entry points are looked up at run-time, so there's no problem having entry points that aren't universally available. I don't actually have any osmesa test-code to run with, so at the moment I can't confirm that the changes work, but hopefully you can confirm after the next release. Take care, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
From: Matthew M. <mat...@gm...> - 2019-01-19 23:42:28
|
Hi Mike, Big fan of PyOpenGL! Just wanted to offer this simple patch for the most recent version of master, which adds a handle for OSMesa's OSMesaCreateContextAttribs <https://github.com/anholt/mesa/blob/01e511233b24872b08bff862ff692dfb5b22c1f4/include/GL/osmesa.h#L167> function. This function allows for users to create OSMesa contexts with core profiles, which is hugely useful for supporting offscreen rendering with modern (>=3.3) shaders. My only concern is that this function is new in Mesa 11.2, which was released on April 4, 2016, so this might not work with older Mesa versions. Not sure if the compilation system will handle this smoothly or not. Suggestions are welcome, happy to help modify this as needed. Best, Matthew Matl UC Berkeley EECS PhD Candidate |
From: GaryBCoder <gar...@gm...> - 2019-01-14 15:22:26
|
Hello, I'm curious about the development status of PyOpenGL. pypi.org shows that the last release was v3.1.0 in Jun 2014, but that there was a pre-release of v3.1.3b2 in Nov 2018 - however I don't see any discussion of new release work going in any of the mailing lists. So are we headed toward a new release maybe? I'm asking because I'm working through the OpenGL Programming Guide and am sticking to the 8th edition because the 9th edition covers OpenGL 4.5 - and http://pyopengl.sourceforge.net/ says that the current release of PyOpenGL only supports OpenGL 4.4. Thanks, Gary |
From: Tiago N. <ti...@gm...> - 2017-09-01 17:56:03
|
Hi, My application has the requirement to run in environments that might not provide hardware-accelerated OpenGL (such as Remote Desktop on Windows). Since we'd like to use hardware acceleration if available, we have code that detects the local support at runtime and loads a bundled GL lib (Mesa+llvmpipe) if necessary. As far as I understand it, PyOpenGL uses ctypes to load the GL lib at runtime. On Windows, I can update the PATH environment variable to have PyOpenGL find my OpenGL32.dll first, and it works as expected. On Linux, it looks like ctypes does a straight dlopen() on the candidate names (libGL.so, libGL.so.1, etc). Apparently it's too late to update LD_LIBRARY_PATH to have the loader find my lib first (ref: https://stackoverflow.com/questions/856116/changing-ld-library-path-at-runtime-for-ctypes), so PyOpenGL finds another dynamic library and I end up with two loaded libs, which as expected doesn't work. My application has other, non-Python OpenGL dependencies and those are resolved by loading (via ctypes) the full name to our bundled libGL.so, so PyOpenGL is our last remaining loose end. I'm writing to ask if my reasoning here is correct and if PyOpenGL has another mechanism through which I could say "load this dynamic lib please". I did some research but couldn't find anything. If no mechanism is available, would the maintainers be interested in adding it? I figured an environment variable called something like PYOPENGL_GL_LIB_FILE and pointing to the full path of my local libGL.so would be interesting, and that would solve my issue. I would be glad to work on a patch to add this feature, as it looks like I might have to patch our local PyOpenGL build anyway. Thank you, Tiago |
From: Axel V. <va...@ma...> - 2017-04-29 22:21:37
|
Hi there, I was using Python3 with PyOpenGL 3.1.1 partially updating vbos as numpy array through the slice operator, when I ran into a bug. 1. When figuring out the step size, arrayByCount fails for numpy.float32 in my case and any other numpy data type, as the arg is not an array. 2. I think start and stop was swapped when figuring out when to copy the whole array I hope I got the fix right which I attached with the modified vbo.py as well as the diff. Axel. |
From: Joel P. <joe...@ho...> - 2017-02-20 21:02:09
|
I have a very simple script: #!/usr/bin/python3 import OpenGL from OpenGL.GL import * Running this script with python 3.5.1 on an updated ubuntu 16.04 causes the following stack trace: Traceback (most recent call last): File "test.py", line 3, in <module> from OpenGL.GL import * File "/usr/lib/python3/dist-packages/OpenGL/GL/__init__.py", line 3, in <module> from OpenGL.GL.VERSION.GL_1_1 import * File "/usr/lib/python3/dist-packages/OpenGL/GL/VERSION/GL_1_1.py", line 10, in <module> from OpenGL import platform, constants, constant, arrays File "/usr/lib/python3/dist-packages/OpenGL/arrays/__init__.py", line 22, in <module> formathandler.FormatHandler.loadAll() File "/usr/lib/python3/dist-packages/OpenGL/arrays/formathandler.py", line 28, in loadAll cls.loadPlugin( entrypoint ) File "/usr/lib/python3/dist-packages/OpenGL/arrays/formathandler.py", line 35, in loadPlugin plugin_class = entrypoint.load() File "/usr/lib/python3/dist-packages/OpenGL/plugins.py", line 14, in load return importByName( self.import_path ) File "/usr/lib/python3/dist-packages/OpenGL/plugins.py", line 28, in importByName module = __import__( ".".join(moduleName), {}, {}, moduleName) File "/usr/lib/python3/dist-packages/OpenGL/arrays/vbo.py", line 430, in <module> def mapVBO( vbo, access=GL.GL_READ_WRITE ): AttributeError: module 'OpenGL.GL' has no attribute 'GL_READ_WRITE' Running exactly the same script with python 2.7.12 does not cause any crash. The installed version of pyopengl is 3.0.2. Is this a bug with pyopengl, and is this mailing list then the appropriate place to report it? |
From: Geert H. V. <gee...@gm...> - 2016-04-06 10:13:22
|
Hey guys, Just wanted to report a bug I found in glReadPixels which has caused me major annoyance yesterday. glReadPixels returns a numpy array with a specific datatype. I found out that the shape parameter given to this array has the rows and columns switched. This will not be a problem for most users, as the flattened array will be interpreted correctly. If one however does some operations on it, like transposes or left right swapping, this results in a corrupted image. For me there was an easy workaround by using: data = data.reshape((data.shape[1],data.shape[0])) However, it would be nice if this was fixed in future versions. It can be fixed in multiple points of the source code, like this line in OpenGL/GL/images.py: array = imageData = images.SetupPixelRead( format, (width,height), type ) Only width and height need to be swapped for it to work. I tested this on both a windows and a linux distribution but would like someone else to test it as well to rule out any stupidity. I believe the cause of the bug is the way OpenGL presents the array data is not consistent with the standard way numpy expects it. Kind regards, Geert Henk Visser |
From: matthew s. <mat...@gm...> - 2015-10-20 17:40:00
|
So here a year later i thought I would give you an update on this. I really only started working on this again about a month ago, but i've made decent progress since. Still a lot of stuff to do, but i've made decent progress at reading the xml registry(only really need to do extensions now), and generating a binding. Didn't end up using your code though plus i've never been a fan of ElementTree fan. So I ended up making a wrapper around xml.parser.expat to do the parsing of the xml registry. I still have a lot of ideas and plans for this, mainly: - Wrapper layer that is mostly compatible with pyopengl. - Basic context creation code for various platforms (no late binding for gl calls) - Various run-time, and generation-time options to customize the binding depending on the needs of a project. The code is here: https://github.com/mdsitton/pyogl If you have any feedback I would be glad to hear it. Thanks, Matthew On Thu, Oct 2, 2014 at 10:41 PM, Mike C. Fletcher <mcf...@vr...> wrote: > On 02/10/14 16:15, matthew sitton wrote: > > So i have been thinking about starting my own opengl binding for > > python, but i thought why not come here and post some of what i am > > wanting out of an opengl binding. > > Sounds fun, be aware that there are actually a *lot* of Python OpenGL > bindings, so you might want to survey them first to see if there is a > jump-start available. > > > Make "Modern OpenGL" a first class citizen. Mainly this would involve > > the following in my opinion: > > - Provide a math library (Something generally equivalent to GLM or > others) > > Math libraries are a hard one IMO. > > GLM is something like 20,000 lines of code, Numpy is huge (quarter of a > million LOC or so). A wrapper around GLM would be great, something > sip-based (or the like) that would let you use GLM vectors etc naturally > from Python would be cool. Thing is, that really sounds like a separate > project (both in terms of scope and focus) from PyOpenGL. Similarly, > while I have a library of code for using Numpy in my scenegraph it > doesn't seem like something that should be dropped into PyOpenGL. > > Basic problem in my mind is that any sufficiently > useful/clean/attractive math library likely should be its own project, > potentially with support in PyOpenGL for it (e.g. as Numpy is directly > supported). > > > - Support opengl profiles, core forward compatible, and compatibility > > based off of the xml registry. > > Sure, using the Registry is pretty much a given, I would think. I'm not > sure whether you'll see a huge advantage to the core vs. compatibility > profiles, I suppose memory usage and start-up might be better. > > > - This would also mean providing imports for opengl functionality > > levels, so if you import OpenGL 3.3 core, you would be returned a > > module that contains all of the required Features at that > > functionality level, and none of the removed features. > > Should be pretty straightforward to do that. The registry has all of the > information for generating those namespaces. However, currently the > manually-wrapped code is all tied into the current module-per-extension > structure. > > > I also think it would be interesting to experiment with reorganization > > of the code to provide an abstraction of ctypes so that a cffi backend > > could be introduced. This should allow PyOpenGL to run under pypy with > > improved performance. > > I believe there's actually a fork of PyOpenGL somewhere that did a > ctypes -> cffi translation. I don't know if there was any performance > improvements. I wouldn't get my hopes up *too* much as a *lot* of the > overhead in PyOpenGL is due to munging the parameters to functions to > make APIs "pythonic", that overhead is significantly reduced by the > OpenGL_accelerate module, which likely won't be useful under PyPy. > Something like Pyglet, which uses the C api directly should give you a > much better bang-for-the-buck improvement in a cffi translation (IIRC > they may have already done that translation too). > > > I have also been thinking about digging into the source, and figuring > > out how the whole thing works better. That way i could contribute to > > the project. I read through this document: > > http://pyopengl.sourceforge.net/documentation/development.html > > However i suspect that its outdated. > > Yup, it's definitely outdated, the whole raw-wrapper hierarchy is now > generated from the XML registry. You can start reading at > `src/xml_generate.py` which is the overall runner that regenerates the > automated wrappers. In particular, if you want to generate your own > wrappers you'll likely want to look at `src/xmlreg.py` which takes the > xml and generates an in-memory model of the APIs. The module > `src/codegenerator.py` is the stuff that actually spits out the modules > and packages. You should pretty easily be able to modify that to spit > out a different style of wrapper. > > I'd say just go ahead and play with generating a wrapper in a form you > feel is good. PyOpenGL tries to be newbie-friendly and does a *lot* of > stuff that really shouldn't be done if you are concerned about creating > a fast engine. Really, if you want to build a fast engine you likely > don't care much about the API you are using, so using a raw wrapper > (i.e. direct cffi or Cython access to unvarnished C-style API) is likely > what you want; you're going to build abstractions over it anyway, so you > don't need them at the API level; pyglet is the obvious example of how > to make that work. > > Things I'd suggest doing if you want a simple, clean, fast API: > > * no lists/tuples/incorrect-formats; demand a binary-compatible, > buffer-protocol-supporting (or native cffi/ctypes) data-type for all > pointer/array parameters > * no pointer management; just let the user crash if they forget to > keep the object pointer around, maybe provide a debug mode that uses > weakref-based logging to display which objects are being deallocated > to make it easier to debug crashes > * don't muck about with the low-level API unnecessarily, every time > you imply parameters or unpack values to be "friendly" you increase > the overhead > * drop GLX, GLU, GLUT, WGL > * don't provide context-checking or the like to try to catch errors, > just let the crashes happen > * use a gl-object with attribute lookup instead of actual modules, so > you only need to load those entry points that get used (note, you'll > get error reports that this makes IDEs unable to find names, sorry > about that) > > I believe you'll find that's *basically* pyglet's automated wrappers, or > SWIG's automated wrappers. I think there's even a Cython wrapper that > basically follows this approach. > > Anyway, go for it. I'm happy to give you assistance on how to use the > PyOpenGL/src tools to generate your own wrapper, and if something is > obviously better I'm happy to look at adopting it for PyOpenGL. If you > want to do something like adding a function to the OpenGL root namespace > (something like) get_feature('GL_VERSION_1_1',profile='core') just to > get started playing, that would be fine too. > > Have fun, > Mike > > -- > ________________________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://www.vrplumber.com > http://blog.vrplumber.com > > > > ------------------------------------------------------------------------------ > Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer > Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports > Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper > Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer > > http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk > _______________________________________________ > PyOpenGL Homepage > http://pyopengl.sourceforge.net > _______________________________________________ > PyOpenGL-Devel mailing list > PyO...@li... > https://lists.sourceforge.net/lists/listinfo/pyopengl-devel > |
From: Steven S. <sc...@ug...> - 2014-12-23 03:02:10
|
I'm running into the following error (Python 3.4.2, PyOpenGL v3.1.0): File "/usr/local/lib/python3.4/dist-packages/OpenGL/GLES2/VERSION/GLES2_2_0.py", line 370, in glGetAttribLocation if name[-1] != _NULL_8_BYTE: NameError: name '_NULL_8_BYTE' is not defined Which seems straightforward enough -- it looks like OpenGL/GLES2/VERSION/GLES2_2_0.py is missing an import. Adding the following line sorts it out: from OpenGL._bytes _NULL_8_BYTE |
From: paul m. <pau...@gm...> - 2014-11-11 22:33:34
|
Howdy, I am using PyOpenGL 3.1.0 with OSMesa for off-screen rendering. This worked fine until I attempted to use the ARB_fragment_program extension to use a custom fragment program (please don't question my use of ARB_vertex_program - I need to support an ancient OpenGL configuration). When calling OpenGL.GL.ARB.fragment_program.glGenProgramsARB, my program crashes with an 'Unhashable type' error: File "/.../glimage_funcs.py", line 126, in init glimg.fragmentProgram = arbfp.glGenProgramsARB(1) File "/.../python2.7/site-packages/OpenGL/latebind.py", line 45, in __call__ return self._finalCall( *args, **named ) File "/.../python2.7/site-packages/OpenGL/wrapper.py", line 657, in wrapperCall result = wrappedOperation( *cArguments ) File "/.../python2.7/site-packages/OpenGL/platform/baseplatform.py", line 401, in __call__ if self.load(): File "/.../python2.7/site-packages/OpenGL/platform/baseplatform.py", line 390, in load error_checker = self.error_checker, File "/.../python2.7/site-packages/OpenGL/platform/baseplatform.py", line 148, in constructFunction if (not is_core) and not self.checkExtension( extension ): File "/.../python2.7/site-packages/OpenGL/platform/baseplatform.py", line 261, in checkExtension set = contextdata.getValue( 'extensions', context=context ) File "/.../python2.7/site-packages/OpenGL/contextdata.py", line 106, in getValue contextStorage = storage.get( context ) TypeError: unhashable type I have tried disabling OpenGL.contextdata with: OpenGL.ERROR_ON_COPY = True OpenGL.STORE_POINTERS = False (as detailed in the OpenGL.contextdata module documentation), but this has no effect. Any ideas on how to overcome this? Thanks very much, Paul McCarthy |
From: Mike C. F. <mcf...@vr...> - 2014-10-03 03:41:21
|
On 02/10/14 16:15, matthew sitton wrote: > So i have been thinking about starting my own opengl binding for > python, but i thought why not come here and post some of what i am > wanting out of an opengl binding. Sounds fun, be aware that there are actually a *lot* of Python OpenGL bindings, so you might want to survey them first to see if there is a jump-start available. > Make "Modern OpenGL" a first class citizen. Mainly this would involve > the following in my opinion: > - Provide a math library (Something generally equivalent to GLM or others) Math libraries are a hard one IMO. GLM is something like 20,000 lines of code, Numpy is huge (quarter of a million LOC or so). A wrapper around GLM would be great, something sip-based (or the like) that would let you use GLM vectors etc naturally from Python would be cool. Thing is, that really sounds like a separate project (both in terms of scope and focus) from PyOpenGL. Similarly, while I have a library of code for using Numpy in my scenegraph it doesn't seem like something that should be dropped into PyOpenGL. Basic problem in my mind is that any sufficiently useful/clean/attractive math library likely should be its own project, potentially with support in PyOpenGL for it (e.g. as Numpy is directly supported). > - Support opengl profiles, core forward compatible, and compatibility > based off of the xml registry. Sure, using the Registry is pretty much a given, I would think. I'm not sure whether you'll see a huge advantage to the core vs. compatibility profiles, I suppose memory usage and start-up might be better. > - This would also mean providing imports for opengl functionality > levels, so if you import OpenGL 3.3 core, you would be returned a > module that contains all of the required Features at that > functionality level, and none of the removed features. Should be pretty straightforward to do that. The registry has all of the information for generating those namespaces. However, currently the manually-wrapped code is all tied into the current module-per-extension structure. > I also think it would be interesting to experiment with reorganization > of the code to provide an abstraction of ctypes so that a cffi backend > could be introduced. This should allow PyOpenGL to run under pypy with > improved performance. I believe there's actually a fork of PyOpenGL somewhere that did a ctypes -> cffi translation. I don't know if there was any performance improvements. I wouldn't get my hopes up *too* much as a *lot* of the overhead in PyOpenGL is due to munging the parameters to functions to make APIs "pythonic", that overhead is significantly reduced by the OpenGL_accelerate module, which likely won't be useful under PyPy. Something like Pyglet, which uses the C api directly should give you a much better bang-for-the-buck improvement in a cffi translation (IIRC they may have already done that translation too). > I have also been thinking about digging into the source, and figuring > out how the whole thing works better. That way i could contribute to > the project. I read through this document: > http://pyopengl.sourceforge.net/documentation/development.html > However i suspect that its outdated. Yup, it's definitely outdated, the whole raw-wrapper hierarchy is now generated from the XML registry. You can start reading at `src/xml_generate.py` which is the overall runner that regenerates the automated wrappers. In particular, if you want to generate your own wrappers you'll likely want to look at `src/xmlreg.py` which takes the xml and generates an in-memory model of the APIs. The module `src/codegenerator.py` is the stuff that actually spits out the modules and packages. You should pretty easily be able to modify that to spit out a different style of wrapper. I'd say just go ahead and play with generating a wrapper in a form you feel is good. PyOpenGL tries to be newbie-friendly and does a *lot* of stuff that really shouldn't be done if you are concerned about creating a fast engine. Really, if you want to build a fast engine you likely don't care much about the API you are using, so using a raw wrapper (i.e. direct cffi or Cython access to unvarnished C-style API) is likely what you want; you're going to build abstractions over it anyway, so you don't need them at the API level; pyglet is the obvious example of how to make that work. Things I'd suggest doing if you want a simple, clean, fast API: * no lists/tuples/incorrect-formats; demand a binary-compatible, buffer-protocol-supporting (or native cffi/ctypes) data-type for all pointer/array parameters * no pointer management; just let the user crash if they forget to keep the object pointer around, maybe provide a debug mode that uses weakref-based logging to display which objects are being deallocated to make it easier to debug crashes * don't muck about with the low-level API unnecessarily, every time you imply parameters or unpack values to be "friendly" you increase the overhead * drop GLX, GLU, GLUT, WGL * don't provide context-checking or the like to try to catch errors, just let the crashes happen * use a gl-object with attribute lookup instead of actual modules, so you only need to load those entry points that get used (note, you'll get error reports that this makes IDEs unable to find names, sorry about that) I believe you'll find that's *basically* pyglet's automated wrappers, or SWIG's automated wrappers. I think there's even a Cython wrapper that basically follows this approach. Anyway, go for it. I'm happy to give you assistance on how to use the PyOpenGL/src tools to generate your own wrapper, and if something is obviously better I'm happy to look at adopting it for PyOpenGL. If you want to do something like adding a function to the OpenGL root namespace (something like) get_feature('GL_VERSION_1_1',profile='core') just to get started playing, that would be fine too. Have fun, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
From: matthew s. <mat...@gm...> - 2014-10-02 20:15:25
|
So i have been thinking about starting my own opengl binding for python, but i thought why not come here and post some of what i am wanting out of an opengl binding. Make "Modern OpenGL" a first class citizen. Mainly this would involve the following in my opinion: - Provide a math library (Something generally equivalent to GLM or others) - Support opengl profiles, core forward compatible, and compatibility based off of the xml registry. - This would also mean providing imports for opengl functionality levels, so if you import OpenGL 3.3 core, you would be returned a module that contains all of the required Features at that functionality level, and none of the removed features. I also think it would be interesting to experiment with reorganization of the code to provide an abstraction of ctypes so that a cffi backend could be introduced. This should allow PyOpenGL to run under pypy with improved performance. I have also been thinking about digging into the source, and figuring out how the whole thing works better. That way i could contribute to the project. I read through this document: http://pyopengl.sourceforge.net/documentation/development.html However i suspect that its outdated. |
From: Mike C. F. <mcf...@vr...> - 2014-09-09 13:05:54
|
On 09/08/2014 06:31 PM, Karl Koscher wrote: > Thanks for the quick response. Attached is a simple Python script > which will reproduce the bug without any special hardware. I'm running > gnuradio 3.7.2.2 and PyOpenGL 3.1.0a3 for Python 2.7. AFAIK this is > only a problem on Windows. Here's the traceback: Oh, that's *weird*, apparently the ulong type doesn't work the same way on win32? I'll have to get some time to boot into windows and look into that. Thanks, Mike > TypeError: ("No array-type handler for type <class 'ctypes.c_ulong'> > (value: c_ulong(0L)) registered", > <OpenGL.converters.CallFuncPyConverter object at 0x041F6930>) > > > I've also attached a patch which seems to fix the problem. > > > > On Mon, Sep 8, 2014 at 6:34 AM, Mike C. Fletcher > <mcf...@vr... <mailto:mcf...@vr...>> wrote: > > On 09/08/2014 03:48 AM, Karl Koscher wrote: >> I'm running GNU Radio on Windows and was trying to figure out why >> the WX FFT display wasn't working. It looks like glGenTextures(1) >> is the culprit. An argument of 1 is special-cased for >> backwards-compatibility, but this seems to break. Commenting this >> special case out fixes the FFT display. >> >> I think the problem is that a single ulong is passed in to the >> underlying function, but it always expects an array of ulongs. I >> think an array should still be passed in, with the first element >> of the array returned in the special case (instead of the array >> itself). >> >> Of course, this is all voodoo magic to me, so perhaps there's a >> good reason for the code the way it is. It would be nice for it >> to work on Windows without hacking the code, though. > > In ctypes, passing in a <ulong> variable acts as a single-element > *ulong, so that *shouldn't* be the issue. However, it is always > possible that we've got a bug in the handling. Thing is, I can't > see anything wrong with the gnuradio code, and without a traceback > or other error to tell me *what* went wrong, I can't investigate > further. I'm assuming that gnuradio would require a piece of > hardware to run, which suggests I wouldn't be able to reproduce > the error easily here. > > What would help is: > > * report your (gnuradio and) PyOpenGL version > * include a traceback > * include the patch for what you changed to make it work > > It *looks* like the wrapper is actually entirely unneeded these > days (it basically duplicates the code in the automated wrapping), > but without knowing *how* the code is failing I can't actually be > sure eliminating the wrapper entirely would fix your problem. > From what I can see gnuradio is only ever calling glGenTextures(1) > in a very standard/simple way. > > Take care, > Mike > > -- > ________________________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://www.vrplumber.com > http://blog.vrplumber.com > > > ------------------------------------------------------------------------------ > Want excitement? > Manually upgrade your production database. > When you want reliability, choose Perforce > Perforce version control. Predictably reliable. > http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk > _______________________________________________ > PyOpenGL Homepage > http://pyopengl.sourceforge.net > _______________________________________________ > PyOpenGL-Devel mailing list > PyO...@li... > <mailto:PyO...@li...> > https://lists.sourceforge.net/lists/listinfo/pyopengl-devel > > -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
From: Karl K. <sup...@cs...> - 2014-09-08 22:32:03
|
--- OpenGL/GL/exceptional.py Mon Sep 8 15:26:21 2014 +++ OpenGL/GL/exceptional-new.py Mon Sep 8 15:24:24 2014 @@ -182,12 +182,12 @@ """ if count <= 0: raise ValueError( """Can't generate 0 or fewer textures""" ) - elif count == 1 and _configflags.SIZE_1_ARRAY_UNPACK: - # this traditionally returned a single int/long, so we'll continue to - # do so, even though it would be easier not to bother. - textures = constants.GLuint( 0 ) - baseFunction( count, textures) - return textures.value + #elif count == 1 and _configflags.SIZE_1_ARRAY_UNPACK: + # # this traditionally returned a single int/long, so we'll continue to + # # do so, even though it would be easier not to bother. + # textures = constants.GLuint( 0 ) + # baseFunction( count, textures) + # return textures.value else: textures = arrays.GLuintArray.zeros( (count,)) baseFunction( count, textures) |
From: Mike C. F. <mcf...@vr...> - 2014-09-08 13:34:22
|
On 09/08/2014 03:48 AM, Karl Koscher wrote: > I'm running GNU Radio on Windows and was trying to figure out why the > WX FFT display wasn't working. It looks like glGenTextures(1) is the > culprit. An argument of 1 is special-cased for > backwards-compatibility, but this seems to break. Commenting this > special case out fixes the FFT display. > > I think the problem is that a single ulong is passed in to the > underlying function, but it always expects an array of ulongs. I think > an array should still be passed in, with the first element of the > array returned in the special case (instead of the array itself). > > Of course, this is all voodoo magic to me, so perhaps there's a good > reason for the code the way it is. It would be nice for it to work on > Windows without hacking the code, though. In ctypes, passing in a <ulong> variable acts as a single-element *ulong, so that *shouldn't* be the issue. However, it is always possible that we've got a bug in the handling. Thing is, I can't see anything wrong with the gnuradio code, and without a traceback or other error to tell me *what* went wrong, I can't investigate further. I'm assuming that gnuradio would require a piece of hardware to run, which suggests I wouldn't be able to reproduce the error easily here. What would help is: * report your (gnuradio and) PyOpenGL version * include a traceback * include the patch for what you changed to make it work It *looks* like the wrapper is actually entirely unneeded these days (it basically duplicates the code in the automated wrapping), but without knowing *how* the code is failing I can't actually be sure eliminating the wrapper entirely would fix your problem. From what I can see gnuradio is only ever calling glGenTextures(1) in a very standard/simple way. Take care, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
From: Karl K. <sup...@cs...> - 2014-09-08 08:08:54
|
I'm running GNU Radio on Windows and was trying to figure out why the WX FFT display wasn't working. It looks like glGenTextures(1) is the culprit. An argument of 1 is special-cased for backwards-compatibility, but this seems to break. Commenting this special case out fixes the FFT display. I think the problem is that a single ulong is passed in to the underlying function, but it always expects an array of ulongs. I think an array should still be passed in, with the first element of the array returned in the special case (instead of the array itself). Of course, this is all voodoo magic to me, so perhaps there's a good reason for the code the way it is. It would be nice for it to work on Windows without hacking the code, though. |
From: Ian M. <ia...@ge...> - 2014-05-27 19:45:48
|
On Tue, May 27, 2014 at 3:44 AM, Sam Bull <sam...@se...> wrote: > On lun, 2014-05-26 at 23:10 -0700, Ian Mallett wrote: > > I spot-checked it just now: there are three chapters dedicated to (now > > completely) deprecated APIs (inc. display lists and GLU). What they > > did have of GL 3, 4 functionality still used deprecated APIs > > (glVertex3f, etc.). My guess is that the current edition continues the > > trend, leaving a lot of legacy cruft in there. > > Fortunately, you're wrong. The book has never mentioned display lists, > glVertex3f and the like. The book approaches it as this is the new-style > OpenGL, it's all shaders, VBOs etc., we're not going to look at > old-style (which is probably why it took so long for them to rewrite > this edition). The whole book is focused on how to use OpenGL 3.3-4.3, > and doesn't even look at old style OpenGL anymore. > > > Oooo excellent. I might be able to recommend it again. Thanks. > So, with the new style, as I understand it, it's not even possible to > use the old OpenGL 2 pipeline (which is why it's not really mentioned in > the book anymore). For example, you need a basic shader to draw even the > most primitive shape, you can't use glVertex3f() etc. to draw a simple > shape, you would have to use a VBO and shader. > Correct. With, say, a GL 4 context, although it's not a GL error to call into deprecated APIs (it just might not do as you expect; in my experience it has no effect), it will be reported as a "high severity" error if you created the context as a debug context (which, if you're using C-level APIs, you should do). Ian |
From: Sam B. <sam...@se...> - 2014-05-27 10:44:53
|
On lun, 2014-05-26 at 23:10 -0700, Ian Mallett wrote: > I spot-checked it just now: there are three chapters dedicated to (now > completely) deprecated APIs (inc. display lists and GLU). What they > did have of GL 3, 4 functionality still used deprecated APIs > (glVertex3f, etc.). My guess is that the current edition continues the > trend, leaving a lot of legacy cruft in there. Fortunately, you're wrong. The book has never mentioned display lists, glVertex3f and the like. The book approaches it as this is the new-style OpenGL, it's all shaders, VBOs etc., we're not going to look at old-style (which is probably why it took so long for them to rewrite this edition). The whole book is focused on how to use OpenGL 3.3-4.3, and doesn't even look at old style OpenGL anymore. So, with the new style, as I understand it, it's not even possible to use the old OpenGL 2 pipeline (which is why it's not really mentioned in the book anymore). For example, you need a basic shader to draw even the most primitive shape, you can't use glVertex3f() etc. to draw a simple shape, you would have to use a VBO and shader. |
From: Ian M. <ia...@ge...> - 2014-05-27 06:11:14
|
On Sun, May 25, 2014 at 6:20 AM, Sam Bull <sam...@se...> wrote: > On sab, 2014-05-24 at 10:16 -0700, Ian Mallett wrote: > > I have been reading the "red-book" how well does it translate > > to Py? > > Pretty much directly. Keep in mind that the red book is OpenGL 2, > > which is technically deprecated. It's not going away anytime soon, but > > you should be aware that GL 3, 4 are now standard. > > The current edition, is for 4.3, which is what I've been reading. It > includes the glsl stuff, so it's kind of the red/orange book now. > To clarify: I have a slightly older edition of the Red Book (ostensibly for GL 3.0 and 3.1). However, in my experience, it really only discusses GL 2 technology. I haven't had much use for it other than as a bookshelf reference for the hard-to-Google. I spot-checked it just now: there are three chapters dedicated to (now completely) deprecated APIs (inc. display lists and GLU). What they did have of GL 3, 4 functionality still used deprecated APIs (glVertex3f, etc.). My guess is that the current edition continues the trend, leaving a lot of legacy cruft in there. ---- My recommendation, if you're serious about learning OpenGL, is to learn C || C++ and then start writing some simple OpenGL 2 applications. There are loads of examples of these, and the technology is both well-understood and easy to use. Once you get comfortable with this (which may take several years--weeks or months, at least), then I'd start playing with modern APIs (GL 3 and on). This will give you a feel for how to use the graphics pipeline, as well as a deep understanding of it. Regarding language choice, I got *a lot* out of PyOpenGL (having taught myself Python and PyOpenGL). Python is a wonderful language to learn, and PyOpenGL is a great tool, but for advanced OpenGL (> GL 2), I have found C-like-languages' directness advantageous. Ian |
From: Sam B. <sam...@se...> - 2014-05-25 13:37:36
|
On sab, 2014-05-24 at 10:16 -0700, Ian Mallett wrote: > I have been reading the "red-book" how well does it translate > to Py? > Pretty much directly. Keep in mind that the red book is OpenGL 2, > which is technically deprecated. It's not going away anytime soon, but > you should be aware that GL 3, 4 are now standard. The current edition, is for 4.3, which is what I've been reading. It includes the glsl stuff, so it's kind of the red/orange book now. http://www.amazon.co.uk/OpenGL-Programming-Guide-Official-Learning/dp/0321773039/ref=sr_1_1/277-3182922-3536901?ie=UTF8&qid=1401023378&sr=8-1&keywords=opengl+redbook As said, it's pretty much a direct comparison. There are a couple of minor differences, but you work them out pretty easily, and will likely find yourself just using the C OpenGL docs. For example, lists will be automatically converted when OpenGL expects an array, and sometimes you might not have an argument for the length of the array, as that information is in the Python object anyway. |
From: Ian M. <ia...@ge...> - 2014-05-24 17:17:08
|
On Thu, May 22, 2014 at 3:53 PM, Rik <ric...@ya...> wrote: > Can someone point me to, or send a test program? I'm on a windows box, > also? My PyOpenGL base code<http://geometrian.com/programming/tutorials/OpenGL%20Program%20Shell.py.txt>is well-worn, simple code for a "hello world" into 3D OpenGL. > I have been reading the "red-book" how well does it translate to Py? Pretty much directly. Keep in mind that the red book is OpenGL 2, which is technically deprecated. It's not going away anytime soon, but you should be aware that GL 3, 4 are now standard. > I luv Py! But was learning c\c++ to learn opengl thanks for adding me > I can't parse this. C/C++ and OpenGL are wonderful together, since much of the low-level stuff OpenGL needs is naturally represented by the language. > Oh, if there is a FAQ's??? I didn't see it? Sorry. > GIYF > {/•Rik•\} > Ian |