Thread: [PyOpenGL-Users] OpenGL 3x compatibility
Brought to you by:
mcfletch
From: Prashant S. <ani...@ya...> - 2009-12-09 04:11:35
|
Hi, I am re-writing an old application using Python/PyOpenGL. It's only using 2D graphics such as glRect, texture based fonts, curves etc. Selection is based on old functions, "glSelectWithCallback" and "getScreenToGLCoord". Shall I continue using these functions or Is there a new mechanism to select objects using OpenGL 3.x? Application is using display list method to cache drawing operation. I would still still prefer to use this method but I have a concerned about using current version and future versions of PyOpenGL. Thanks Prashant The INTERNET now has a personality. YOURS! See your Yahoo! Homepage. http://in.yahoo.com/ |
From: Mike C. F. <mcf...@vr...> - 2009-12-09 05:42:20
|
Prashant Saxena wrote: > Hi, > > I am re-writing an old application using Python/PyOpenGL. It's only using 2D graphics such as glRect, texture based fonts, curves etc. Selection is based on old functions, "glSelectWithCallback" and "getScreenToGLCoord". > Shall I continue using these functions or Is there a new mechanism to select objects using OpenGL 3.x? > > Application is using display list method to cache drawing operation. I would still still prefer to use this method but I have a concerned about using current version and future versions of PyOpenGL. > You shouldn't need to recode the old application, really. While the ARB OpenGL 3.0 release declared all sorts of things deprecated, the vendors have since back-tracked and have all basically committed to supporting the legacy stuff for the foreseeable future. Particularly if you want to continue using display-lists, there's not going to be much point making the *rest* of your application legacy free. 50% of the work of going "legacy free" is moving to array-based (and by extension, VBO-based) rendering, rather than display-lists and individual calls. If you're not converting the rendering code to use arrays/vbos you likely aren't going to want to make the rest of your code legacy free (e.g. moving to shaders for rendering). Regarding selection under 3.x legacy-free, it's intended to be done with either colour-buffer selection or projection of vectors into your scenegraph (i.e. math). Colour-buffer selection can be seen in the OpenGLContext "flat" rendering pass module. PyOpenGL is unlikely to stop supporting the legacy entry points any time soon, given that they have effectively been de-deprecated by the vendors (and since almost everything written in PyOpenGL uses them)... you shouldn't use them for new code, really, but even there I'm feeling it's so much easier to get started with them that even the "legacy free" OpenGLContext shader tutorials use the legacy entry points to start out with. HTH, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
From: Prashant S. <ani...@ya...> - 2009-12-10 07:12:12
|
Hi, Are there any docs, article available for the deprecated function equivalent in 3.x api. Converting old school code completely using new api would be difficult with out good docs and references. For example glEnableClientState(GL_COLOR_ARRAY) glEnableClientState(GL_VERTEX_ARRAY) glColorPointer(4, GL_FLOAT, 0, self.colors) glVertexPointer(2, GL_FLOAT, 0, self.vertices) glPushMatrix() glTranslatef(self.x, self.y, 0) # glDrawArrays(GL_QUADS, 0, 4) glPopMatrix() # Disable vertex arrays glDisableClientState(GL_VERTEX_ARRAY) glDisableClientState(GL_COLOR_ARRAY) This is new way to draw quads using array method but glPushMatrix, glPopMatrix, glTranslate & glColor has been deprecated. Prashant The INTERNET now has a personality. YOURS! See your Yahoo! Homepage. http://in.yahoo.com/ |
From: Mike C. F. <mcf...@vr...> - 2009-12-10 16:11:58
|
Prashant Saxena wrote: > Hi, > > Are there any docs, article available for the deprecated function equivalent in 3.x api. Converting old school code completely > using new api would be difficult with out good docs and references. > > For example > > glEnableClientState(GL_COLOR_ARRAY) > glEnableClientState(GL_VERTEX_ARRAY) > > glColorPointer(4, GL_FLOAT, 0, self.colors) > glVertexPointer(2, GL_FLOAT, 0, self.vertices) > > glPushMatrix() > glTranslatef(self.x, self.y, 0) # > glDrawArrays(GL_QUADS, 0, 4) > glPopMatrix() > > # Disable vertex arrays > glDisableClientState(GL_VERTEX_ARRAY) > glDisableClientState(GL_COLOR_ARRAY) > > This is new way to draw quads using array method but glPushMatrix, glPopMatrix, glTranslate & glColor has been deprecated. > Actually, that's the pretty-old-but-not-quite-the-oldest way to draw quads (it's from OpenGL 1.1, January 1997), which is about 1/2 of the way to legacy free. To go legacy-free you then convert the code to use shader attributes instead of the hard-coded color, vertex, texture-coordinate etc. arrays (that's a trivial textual change) and write shaders to render *all* of the quads with a single call (that's a bit of work if you don't know GLSL yet). Oh, and quads are deprecated... you render two triangles... Matrix operations are deprecated in their entirety, with only shader-uniform matrices being available, i.e. you define a uniform called "mv_matrix", another called "norm_matrix" and calculate the matrices, passing them fully-formed to the shader alongside your data for each object. Point form description of what needs to happen is on the deprecations page[1]. At this point I'd say "move to using arrays (and VBOs), investigate shaders" is the best path to take, rather than trying to go fully legacy-free all in one go. Legacy-free operation has a higher barrier to entry than the original OpenGL API, and when you go legacy free you either have to provide fallback code for older hardware or just give up on the less featureful hardware (e.g. my 2-year-old laptop with a crappy Intel Integrated Graphics chip doesn't support GLSL at all). I'm trying to write a series of introductory tutorials[2] for legacy-free operation, but I'm short on time (perennially), so you might not want to hold your breath on it. HTH, Mike [1] http://pyopengl.sourceforge.net/documentation/deprecations.html [2] http://pyopengl.sourceforge.net/context/tutorials/index.xhtml -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
From: Gijs <in...@bs...> - 2009-12-10 22:28:42
|
On 10-12-2009 17:11, Mike C. Fletcher wrote: > Prashant Saxena wrote: >> Hi, >> >> Are there any docs, article available for the deprecated function equivalent in 3.x api. Converting old school code completely >> using new api would be difficult with out good docs and references. >> >> For example >> >> glEnableClientState(GL_COLOR_ARRAY) >> glEnableClientState(GL_VERTEX_ARRAY) >> >> glColorPointer(4, GL_FLOAT, 0, self.colors) >> glVertexPointer(2, GL_FLOAT, 0, self.vertices) >> >> glPushMatrix() >> glTranslatef(self.x, self.y, 0) # >> glDrawArrays(GL_QUADS, 0, 4) >> glPopMatrix() >> >> # Disable vertex arrays >> glDisableClientState(GL_VERTEX_ARRAY) >> glDisableClientState(GL_COLOR_ARRAY) >> >> This is new way to draw quads using array method but glPushMatrix, glPopMatrix, glTranslate& glColor has been deprecated. >> > Actually, that's the pretty-old-but-not-quite-the-oldest way to draw > quads (it's from OpenGL 1.1, January 1997), which is about 1/2 of the > way to legacy free. To go legacy-free you then convert the code to use > shader attributes instead of the hard-coded color, vertex, > texture-coordinate etc. arrays (that's a trivial textual change) and > write shaders to render *all* of the quads with a single call (that's a > bit of work if you don't know GLSL yet). Oh, and quads are > deprecated... you render two triangles... > > Matrix operations are deprecated in their entirety, with only > shader-uniform matrices being available, i.e. you define a uniform > called "mv_matrix", another called "norm_matrix" and calculate the > matrices, passing them fully-formed to the shader alongside your data > for each object. Point form description of what needs to happen is on > the deprecations page[1]. > > At this point I'd say "move to using arrays (and VBOs), investigate > shaders" is the best path to take, rather than trying to go fully > legacy-free all in one go. Legacy-free operation has a higher barrier > to entry than the original OpenGL API, and when you go legacy free you > either have to provide fallback code for older hardware or just give up > on the less featureful hardware (e.g. my 2-year-old laptop with a crappy > Intel Integrated Graphics chip doesn't support GLSL at all). I'm trying > to write a series of introductory tutorials[2] for legacy-free > operation, but I'm short on time (perennially), so you might not want to > hold your breath on it. > > HTH, > Mike > > [1] http://pyopengl.sourceforge.net/documentation/deprecations.html > [2] http://pyopengl.sourceforge.net/context/tutorials/index.xhtml > Nice to have some documentation/examples on OpenGL 3.x code. I spend quite a bit of time trying to find documentation for it but it seems to be very very sparse on the net. I know roughly how to replace most functions, though glRotate and glScale will probably be a bit annoying to do in shaders. However, I've never found a good replacement for display lists. Nor do I understand why they are deprecated at all. The usual answer how to replace display lists is to convert "it" to VBOs. But display lists can contain a whole lot more than just vertex/color/tex data. Quite a lot of commands can be compiled into display lists as well. I use it to bind all my input textures for my shaders for instance. Sometimes I use different input textures so I use different display lists for those, which can save quite a bunch of extra calls. But I can't really find any replacement that does stuff like this in the new OpenGL 3.x functions. Do you have any idea Mike? Regards, Gijs |
From: Mike C. F. <mcf...@vr...> - 2009-12-11 16:04:17
|
Greg Ewing wrote: > Gijs wrote: > >> I've never found a good replacement for >> display lists. Nor do I understand why they are deprecated at all. >> > > This worries me, too. My guess is they are reasoning that there > is no performance advantage in using display lists if you use > vertex arrays and/or VBOs instead of glVertex calls. > > This might possibly be true, *if* you're programming in C. But > it's not true at all in Python where function calls are expensive. > A display list can wrap up a sequence of just about any kind of > call, including lighting, texture, matrix changes, etc., into > something that can be fired off using just one Python call, > and that can give you a huge speed advantage. > > I'm hoping that something akin to display lists will continue > to be available, maybe in glu or another library, if they are > dropped from the core of GL. > > Personally I'm ignoring GL 3.0 for now and hoping it's just > a bad dream that will go away. As long as 2.x still works, > I'll continue to use it. If it ever stops working, and there > isn't a compatibility library available already, I'll write > one myself to cover the things I don't want to do without. > Display lists are definitely the more flexible path. They are currently being implemented in the GL/drivers rather than in hardware. Basically they just record your high-level GL commands and play them back (in C) when you call them. There's no reason you couldn't implement that in C, Cython, or what have you. It will, however, top out at a certain level of complexity and doesn't particularly allow for more "modern" rendering effects. For most PyOpenGL users, not a big deal and a bridge API would be fine. You're going to be transferring your data on each rendering pass, but if you've got a small data-set, no problem. More involved/advanced implementations could even compile down to VBOs and shaders for you... but given that the GPU manufacturers consider that too much effort, it might not be worth it. For the broader OpenGL market, VBOs, FBOs, PBOs and shaders are a more open-ended solutions. Basically there's just no way to do most of the things people want to provide in "real" game engines these days with display lists. While PyOpenGL's "market" tends to be people doing simple data-visualization and people wanting to learn 3d graphics, OpenGL is chasing a different market. The vendors seem to have realized that killing off the "legacy" market isn't a good idea for their bottom line, so I'd guess the 2.x APIs will be around for a good while. Enjoy, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
From: Mike C. F. <mcf...@vr...> - 2009-12-13 20:42:57
|
Mike C. Fletcher wrote: > Greg Ewing wrote: > ... > Basically there's just no way to do most of the > things people want to provide in "real" game engines these days with > display lists. > Ah, Greg clipped this in his reply, so I missed that he was responding to this idea rather than the sentence before it. My sentence was over-stated; you *could* use display-lists combined with shaders, vbos, fbos, etceteras... it just wouldn't make sense for a C/C++ coded engine. Display-listing geometry *at the vertex level* just isn't useful unless your driver is going to optimize the heck out of the resulting display list (which they don't). Using display-lists to configure VBOs and the like, by contrast, might be useful for Python coders, but wouldn't do anything useful for C/C++ coders. Enjoy, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
From: Ian M. <geo...@gm...> - 2009-12-11 03:23:32
|
I was thinking of just computing the matrices in the main and then passing those as uniforms, similarly to the present setup, instead of trying to define a series of transformations and pass those in. Not sure if that's what you mean. Simply add a part in each of the drawing functions (e.g., I have stuff like object.draw_vbo(shader)) that passes in the current matrix, and then redefine glScalef, glRotatef, etc. to change a hardcoded matrix. Then you can code in legacy style. Still not sure why they decided to change it. IMO, the matrix setup works beautifully. There can only be negative performance consequences from not implementing it in hardware. Ian |
From: Greg E. <gre...@ca...> - 2009-12-11 10:35:36
|
Gijs wrote: > I've never found a good replacement for > display lists. Nor do I understand why they are deprecated at all. This worries me, too. My guess is they are reasoning that there is no performance advantage in using display lists if you use vertex arrays and/or VBOs instead of glVertex calls. This might possibly be true, *if* you're programming in C. But it's not true at all in Python where function calls are expensive. A display list can wrap up a sequence of just about any kind of call, including lighting, texture, matrix changes, etc., into something that can be fired off using just one Python call, and that can give you a huge speed advantage. I'm hoping that something akin to display lists will continue to be available, maybe in glu or another library, if they are dropped from the core of GL. Personally I'm ignoring GL 3.0 for now and hoping it's just a bad dream that will go away. As long as 2.x still works, I'll continue to use it. If it ever stops working, and there isn't a compatibility library available already, I'll write one myself to cover the things I don't want to do without. -- Greg |
From: Greg E. <gre...@ca...> - 2009-12-11 21:55:53
|
Mike C. Fletcher wrote: > For the broader OpenGL market, VBOs, FBOs, PBOs and shaders are a more > open-ended solutions. You're speaking as if VBOs/shaders and display lists are mutually exclusive, but they're not. You can put all your vertex data into VBOs, and compile calls using the VBOs, along with switching shaders and textures etc., into the display lists. There are certainly limits to what can be achieved that way, but in a Python context it's still a very useful tool to have available, IMO. Also, some of the limitations are only there because of the way display lists have traditionally worked in OpenGL. A reimplementation of the idea in a separate library would allow room for improvements. One could envisage a "GL display list language" that allows parameter passing, loops, procedure calls, etc... that would be compiled into some efficiently-executable form, maybe even native code. -- Greg |
From: Mike C. F. <mcf...@vr...> - 2009-12-13 20:36:29
|
Greg Ewing wrote: > Mike C. Fletcher wrote: > > >> For the broader OpenGL market, VBOs, FBOs, PBOs and shaders are a more >> open-ended solutions. >> > > You're speaking as if VBOs/shaders and display lists are > mutually exclusive, but they're not. You can put all your > vertex data into VBOs, and compile calls using the VBOs, > along with switching shaders and textures etc., into the > display lists. > > There are certainly limits to what can be achieved that > way, but in a Python context it's still a very useful tool > to have available, IMO. > Sure, but the key there is "in a Python context", other languages have compilers that give them native speed *without* needing display lists. Since display lists are just implemented in the driver using C, the general 3d programming populace, the "broader OpenGL market", who almost exclusively use C/C++ for programming OpenGL, has no particular use for them. They can get exactly the same speed by just writing code to make the OpenGL calls in C/C++ and they don't have to worry about display-list restrictions or anything else. OpenGL is deprecating this functionality because for the broader market (read C programmers) it is of little or no use. There's absolutely nothing stopping you from creating a display-list implementation for Python, but when you sit down to do it... well... it's close to the same amount of work as creating a scenegraph engine that does what you want with direct C-level calls at native speed... which can be as flexible and optimized as you need for your particular rendering task and can do frustum culling, LOD-ing and the like while it's rendering rather than being restricted to always playing back the same sequence of commands. There's likely a "market" for such a library among, for instance, PyOpenGL's traditional users, but the OpenGL ARB isn't interested in that market segment AFAICS. Just trying to explain why it seems to be happening... I have no input or special insight into the ARB's decision processes, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
From: Greg E. <gre...@ca...> - 2009-12-13 22:25:48
|
Mike C. Fletcher wrote: > OpenGL is deprecating this > functionality because for the broader market (read C programmers) it is > of little or no use. Yes, it's understandable from that point of view. It's just a bit disappointing that they're ignoring the interpreted language community. > it's close to the same amount of work as creating a scenegraph engine > that does what you want with direct C-level calls at native speed... > which can be as flexible and optimized as you need for your particular > rendering task But making it optimised for your particular rendering task means writing a new scenegraph engine for each application. Whereas a display list is a very simple and general mechanism that can be reused for many applications. -- Greg |
From: Mike C. F. <mcf...@vr...> - 2009-12-14 01:45:18
|
Greg Ewing wrote: > Mike C. Fletcher wrote: > >> OpenGL is deprecating this >> functionality because for the broader market (read C programmers) it is >> of little or no use. >> > > Yes, it's understandable from that point of view. It's just a > bit disappointing that they're ignoring the interpreted language > community. > > >> it's close to the same amount of work as creating a scenegraph engine >> that does what you want with direct C-level calls at native speed... >> which can be as flexible and optimized as you need for your particular >> rendering task >> > > But making it optimised for your particular rendering task means > writing a new scenegraph engine for each application. Whereas a > display list is a very simple and general mechanism that can be > reused for many applications. > Or, and really, IMO, this is the thing that needs to happen; certain interpreted languages (i.e. Python) need to get off their posteriors and start producing near-native speeds for this kind of task. PyPy had some interesting code a year or two ago that could use ctypes type declarations to specialize code-paths for serious performance wins. Making that more general and available in a production-ready Python would be my preferred approach to the problem :) . The various Javascript VMs have shown that dynamism can be optimized... it just takes some non-trivial work at the interpreter level. Have fun, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
From: Mike C. F. <mcf...@vr...> - 2009-12-11 16:00:18
|
Ian Mallett wrote: > I was thinking of just computing the matrices in the main and then > passing those as uniforms, similarly to the present setup, instead of > trying to define a series of transformations and pass those in. Not > sure if that's what you mean. > > Simply add a part in each of the drawing functions (e.g., I have stuff > like object.draw_vbo(shader)) that passes in the current matrix, and > then redefine glScalef, glRotatef, etc. to change a hardcoded matrix. > Then you can code in legacy style. > > Still not sure why they decided to change it. IMO, the matrix setup > works beautifully. There can only be negative performance > consequences from not implementing it in hardware. The basic idea is that since most (professional) game engines wind up computing the final transformation matrix anyway, why have the GL *also* compute it. That allows them to (in theory) reduce the complexity of the GL (though since the deprecations were reversed, it didn't work :) ). You can see how this works in OpenGLContext's "flat" render pass. Calculating the matrix in full on the CPU lets it do frustum culling, depth-sorting, etceteras, then pass the same matrix into the GL with a couple of calls. Thing is, there hasn't been a hardware implementation of glRotate/glScale/glTranslate in a long time, from what I'm told. The GL has just been implementing all of the "legacy" transformation code in simple (read not-very-optimized) C code in the driver which then passed the results into the shader it was building under the covers to render the legacy shading model. Your "workstation" graphics cards were basically just better-optimized drivers for approximately the same hardware. The performance is thus ~ the same if you do the calculations in C (or numpy) or "in the GL". The hardware doesn't do the work, incidentally, because it costs silicon and, as mentioned, "real world" engines don't need it. That said, I don't *agree* with deprecating the functionality myself, I still think the idea of the transformation matrix stack are a useful first-step for new OpenGL programmers, I'm just repeating the arguments that I've received from others as to why it was done. HTH, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
From: Ian M. <geo...@gm...> - 2009-12-11 18:07:02
|
On Fri, Dec 11, 2009 at 7:41 AM, Mike C. Fletcher <mcf...@vr...>wrote: > Thing is, there hasn't been a hardware implementation of > glRotate/glScale/glTranslate in a long time, from what I'm told. The GL > has just been implementing all of the "legacy" transformation code in > simple (read not-very-optimized) C code in the driver which then passed > the results into the shader it was building under the covers to render > the legacy shading model. > I stand corrected. However, not-very optimized C code is better than optimized Python code, I assume . . . |
From: Greg E. <gre...@ca...> - 2009-12-14 22:13:16
|
Mike C. Fletcher wrote: > That said, I don't *agree* with deprecating the functionality myself, I > still think the idea of the transformation matrix stack are a useful > first-step for new OpenGL programmers What's more, if the stack is being implemented in software, it would be trivial to provide a way of getting back the current matrix at next to zero cost so that the calling code can do whatever it needs with it. -- Greg |