Thread: [PyOpenGL-Users] features from OpenGL > 1.1
Brought to you by:
mcfletch
From: Andrew S. <and...@ad...> - 2003-09-24 07:46:37
|
I'm trying to understand what/how/if PyOpenGL deals with multiple versions of OpenGL. For example, if I run PyOpenGL on a machine with OpenGL 1.3 libraries, I should have multitexturing abilities built-in (e.g. glActiveTexture() function). This is specified in the OpenGL 1.3 spec: http://www.opengl.org/developers/documentation/version1_3/glspec13.pdf Another example is that with OpenGL 1.2, the GL_CLAMP_TO_EDGE constant should be defined. However, PyOpenGL doesn't provide these names in the GL module when run on an appropriate system. I wonder if this is simply an oversight which would be easily fixed, a purposeful omission because runtime GL version checking and name exporting may be tricky, or has never been thought about. Incidentally, on linux, I can get around the missing glActiveTexture() function by using ctypes to load the function. (On Windows, I get an error that the arguments must be 4 bytes longer... I haven't tracked this down, though.) Another workaround is that some OpenGL 1.3 drivers (nVidia) still support the multitexturing ARB extension, but others (ATI) don't. This success with ctypes and the continued good things I hear about Pyrex make me wonder if maybe the PyOpenGL build system could be simplified by getting away from SWIG and using these two technologies? So, what's the story? Anyone know? |
From: Mike C. F. <mcf...@ro...> - 2003-09-25 05:23:30
|
Andrew Straw wrote: > I'm trying to understand what/how/if PyOpenGL deals with multiple > versions of OpenGL. For example, if I run PyOpenGL on a machine with > OpenGL 1.3 libraries, I should have multitexturing abilities built-in > (e.g. glActiveTexture() function). This is specified in the OpenGL > 1.3 spec: > http://www.opengl.org/developers/documentation/version1_3/glspec13.pdf PyOpenGL is currently limited to OpenGL 1.1. At the moment, I don't have drivers which support features from OpenGL 1.2 or above. There are a few extensions that, if I get the time, I might code up wrappers for, but they aren't the fun/sexy stuff for new hardware, I only have a Radeon 7500. > Incidentally, on linux, I can get around the missing glActiveTexture() > function by using ctypes to load the function. (On Windows, I get an > error that the arguments must be 4 bytes longer... I haven't tracked > this down, though.) Don't know. > Another workaround is that some OpenGL 1.3 drivers (nVidia) still > support the multitexturing ARB extension, but others (ATI) don't. Hmm, strange. They really should be providing OpenGL 1.1 drivers with the extensions alongside the 1.3 drivers... sigh. Not that it would help much, as we don't have the extensions in many (most) cases. > This success with ctypes and the continued good things I hear about > Pyrex make me wonder if maybe the PyOpenGL build system could be > simplified by getting away from SWIG and using these two technologies? ctypes is likely to be too slow for more than a few functions, as there's a lot of manipulation required to make the Python objects OpenGL compatible. Pyrex is possible, but in the end, it's almost the same problem as with the SWIG system, you wind up needing to extend Pyrex to support polymorphic array parameters, to provide the bridge code for various Python-ised calls, etceteras. Code complexity doesn't go down much AFAICS... that said, if someone wants to prove me wrong, I'd be delighted :) . I'd be more interested in seeing someone model the whole problem in Python with a code-generator to create SWIG, Pyrex or Ctypes code for any given function so that we could try them all out alongside one another (and maybe add a straight C code generator to see if that makes things easier...). Oh well. > So, what's the story? Anyone know? HTH, Mike _______________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://members.rogers.com/mcfletch/ |
From: Andrew S. <as...@in...> - 2003-09-25 06:32:46
|
Mike C. Fletcher wrote: > Andrew Straw wrote: > >> I'm trying to understand what/how/if PyOpenGL deals with multiple >> versions of OpenGL. For example, if I run PyOpenGL on a machine with >> OpenGL 1.3 libraries, I should have multitexturing abilities built-in >> (e.g. glActiveTexture() function). This is specified in the OpenGL >> 1.3 spec: >> http://www.opengl.org/developers/documentation/version1_3/glspec13.pdf > > > PyOpenGL is currently limited to OpenGL 1.1. At the moment, I don't > have drivers which support features from OpenGL 1.2 or above. You can always run Mesa to get OpenGL 1.4. (It's not HW accelerated, but it'll at least let you test.) > There are > a few extensions that, if I get the time, I might code up wrappers for, > but they aren't the fun/sexy stuff for new hardware, I only have a > Radeon 7500. OK, but my question really is: how does/would PyOpenGL deal with the concept that at build time I might not have access to OpenGL > 1.1 libs, but may want to run later (without re-compiling) on a system with later libs. It seems that as long as you have header files that support OpenGL > 1.1 (easy to get), we should be able to provide a correct and complete interface to the dynamic library, regardless of version at build and run time. Perhaps on PyOpenGL load-time, PyOpenGL could call glGetString(GL_VERSION) to figure out which names to load into its namespace. Does this seem like a reasonable idea? Do any of the supported platforms statically link OpenGL libs? (That sounds really silly, but...) From what I've learned about the PyOpenGL system, many of the tricky wrapping issues have already been taken care of, so it would "simply" be a matter of creating this load-time system and adding the interface code for the new calls. The reason for this email is that I see a few numbers in the PyOpenGL source that I'm not exactly sure what they mean, and I wonder if this road was gone down before, or at least started. (e.g. in interface_util.c there are heaps of "#ifndef GL_VERSION_1_2" type conditionals, although this clearly points to a build-time rather than run time interface selection, which is non-optimal.) >> Another workaround is that some OpenGL 1.3 drivers (nVidia) still >> support the multitexturing ARB extension, but others (ATI) don't. > > Hmm, strange. They really should be providing OpenGL 1.1 drivers with > the extensions alongside the 1.3 drivers... sigh. Not that it would > help much, as we don't have the extensions in many (most) cases. Luckily we do have the ARB multitexturing extension, which is pretty darn useful! (It is a pain that ATI doesn't seem to support it with their Windows OpenGL 1.3 drivers.) >> This success with ctypes and the continued good things I hear about >> Pyrex make me wonder if maybe the PyOpenGL build system could be >> simplified by getting away from SWIG and using these two technologies? > > ctypes is likely to be too slow for more than a few functions, as > there's a lot of manipulation required to make the Python objects OpenGL > compatible. Pyrex is possible, but in the end, it's almost the same > problem as with the SWIG system, you wind up needing to extend Pyrex to > support polymorphic array parameters, to provide the bridge code for > various Python-ised calls, etceteras. Code complexity doesn't go down > much AFAICS... that said, if someone wants to prove me wrong, I'd be > delighted :) . I'd be more interested in seeing someone model the whole > problem in Python with a code-generator to create SWIG, Pyrex or Ctypes > code for any given function so that we could try them all out alongside > one another (and maybe add a straight C code generator to see if that > makes things easier...). Oh well. Sounds like fun for a rainy month... But I guess there's no point worrying about this until someone has time to dive in and tackle it. Which may never happen given that they may not get a speed boost over the current SWIG system. (It's good to hear you think SWIG will result in the fastest interface, since with OpenGL that's probably what people care about most.) Cheers! Andrew |