pyopengl-users Mailing List for PyOpenGL (Page 43)
Brought to you by:
mcfletch
Menu
▾
▴
pyopengl-users — Discussion of all PyOpenGL matters.
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(81) |
Oct
(41) |
Nov
(55) |
Dec
(14) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(34) |
Feb
(3) |
Mar
(16) |
Apr
(5) |
May
(10) |
Jun
(13) |
Jul
(24) |
Aug
(14) |
Sep
(14) |
Oct
(9) |
Nov
(10) |
Dec
(16) |
| 2003 |
Jan
(25) |
Feb
(59) |
Mar
(9) |
Apr
(21) |
May
(54) |
Jun
(4) |
Jul
(16) |
Aug
(19) |
Sep
(19) |
Oct
(15) |
Nov
(13) |
Dec
(22) |
| 2004 |
Jan
(19) |
Feb
(8) |
Mar
(20) |
Apr
(16) |
May
(13) |
Jun
(18) |
Jul
(18) |
Aug
(14) |
Sep
(24) |
Oct
(47) |
Nov
(20) |
Dec
(10) |
| 2005 |
Jan
(23) |
Feb
(31) |
Mar
(11) |
Apr
(29) |
May
(18) |
Jun
(7) |
Jul
(11) |
Aug
(12) |
Sep
(8) |
Oct
(4) |
Nov
(11) |
Dec
(7) |
| 2006 |
Jan
(7) |
Feb
(8) |
Mar
(15) |
Apr
(3) |
May
(8) |
Jun
(25) |
Jul
(19) |
Aug
(3) |
Sep
(17) |
Oct
(27) |
Nov
(24) |
Dec
(9) |
| 2007 |
Jan
(6) |
Feb
(43) |
Mar
(33) |
Apr
(8) |
May
(20) |
Jun
(11) |
Jul
(7) |
Aug
(8) |
Sep
(11) |
Oct
(22) |
Nov
(15) |
Dec
(18) |
| 2008 |
Jan
(14) |
Feb
(6) |
Mar
(6) |
Apr
(37) |
May
(13) |
Jun
(17) |
Jul
(22) |
Aug
(16) |
Sep
(14) |
Oct
(16) |
Nov
(29) |
Dec
(13) |
| 2009 |
Jan
(7) |
Feb
(25) |
Mar
(38) |
Apr
(57) |
May
(12) |
Jun
(32) |
Jul
(32) |
Aug
(35) |
Sep
(10) |
Oct
(28) |
Nov
(16) |
Dec
(49) |
| 2010 |
Jan
(57) |
Feb
(37) |
Mar
(22) |
Apr
(15) |
May
(45) |
Jun
(25) |
Jul
(32) |
Aug
(7) |
Sep
(13) |
Oct
(2) |
Nov
(11) |
Dec
(28) |
| 2011 |
Jan
(35) |
Feb
(39) |
Mar
|
Apr
(25) |
May
(32) |
Jun
(17) |
Jul
(29) |
Aug
(10) |
Sep
(26) |
Oct
(9) |
Nov
(28) |
Dec
(4) |
| 2012 |
Jan
(24) |
Feb
(47) |
Mar
(4) |
Apr
(8) |
May
(9) |
Jun
(6) |
Jul
(4) |
Aug
(1) |
Sep
(4) |
Oct
(28) |
Nov
(2) |
Dec
(2) |
| 2013 |
Jan
(11) |
Feb
(3) |
Mar
(4) |
Apr
(38) |
May
(15) |
Jun
(11) |
Jul
(15) |
Aug
(2) |
Sep
(2) |
Oct
(4) |
Nov
(3) |
Dec
(14) |
| 2014 |
Jan
(24) |
Feb
(31) |
Mar
(28) |
Apr
(16) |
May
(7) |
Jun
(6) |
Jul
(1) |
Aug
(10) |
Sep
(10) |
Oct
(2) |
Nov
|
Dec
|
| 2015 |
Jan
(6) |
Feb
(5) |
Mar
(2) |
Apr
(1) |
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
(2) |
Oct
(1) |
Nov
(19) |
Dec
|
| 2016 |
Jan
(6) |
Feb
(1) |
Mar
(7) |
Apr
|
May
(6) |
Jun
|
Jul
(3) |
Aug
(7) |
Sep
|
Oct
(2) |
Nov
(2) |
Dec
|
| 2017 |
Jan
|
Feb
(6) |
Mar
(8) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(4) |
Sep
(3) |
Oct
(2) |
Nov
|
Dec
|
| 2018 |
Jan
(9) |
Feb
(1) |
Mar
|
Apr
|
May
(1) |
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(6) |
Jun
(1) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
|
Apr
(7) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Jef M. <jef...@gm...> - 2010-01-05 08:57:18
|
PIL 1.1.6 supposedly has a module name ImageGL to convert image files to OpenGL textures. This somehow does not work for me for lack of the _imaginggl module. This is supposedly part of imToolkit according to the comment but google never heard of it. How can I convert image files (e.g. JPG) to PyOpenGL textures ? can I do it with PIL (if so, how) or do I need something else ? Jef |
|
From: Mike C. F. <mcf...@vr...> - 2010-01-04 23:01:34
|
Dick Holmes wrote: > When executing the test programs from the source package, I'm getting > the error message: > > File > "C:\Python25\lib\site-packages\pyopengl-3.0.0b6-py2.5.egg\OpenGL\platform > \baseplatform.py", line 280, in __call__ > self.__name__, self.__name__, > OpenGL.error.NullFunctionError: Attempt to call an undefined function > __glutInit > WithExit, check for bool(__glutInitWithExit) before calling > > I haven't been able to locate this function. Any ideas? I believe this is a bug that was fixed in either the 3.0.0 final or possibly in the 3.0.1 alpha. HTH, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
|
From: Dick H. <en...@ds...> - 2010-01-03 22:39:43
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> </head> <body bgcolor="#ffffff" text="#000000"> <font face="Verdana">When executing the test programs from the source package, I'm getting the error message:<br> <br> File "C:\Python25\lib\site-packages\pyopengl-3.0.0b6-py2.5.egg\OpenGL\platform<br> \baseplatform.py", line 280, in __call__<br> self.__name__, self.__name__,<br> OpenGL.error.NullFunctionError: Attempt to call an undefined function __glutInit<br> WithExit, check for bool(__glutInitWithExit) before calling<br> <br> I haven't been able to locate this function. Any ideas?<br> <br> Thanks!<br> <br> Dick Holmes<br> <br> </font> </body> </html> |
|
From: Ian M. <geo...@gm...> - 2009-12-31 07:41:12
|
Hi, I've been doing a lot of inside work on my rendering library, and I've made a whole bunch of changes that I don't fancy redoing. However, recent code that uses it is crashing in strange ways. The program will run perfectly for a few seconds, and then suddenly, it will crash, on simple calls, like glCallList, glDisable, glUniform1f. In some cases, calling the same function immediately afterward works fine, but the program crashes on subsequent opengl operations. There's no repeatability--sometimes a program will work just fine for as long as I test; then running the same program again later will cause an error almost immediately. It's incredibly strange, and I don't know what to do. I think I must have added a bind to a buffer or something that's not being balanced later. At the moment, I need help figuring out what general situations would cause such problems. I've noticed the errors in fairly complicated code, like certain GPU cloth situations and shadowmapping. Any possible ideas as to what might possibly be causing these errors? Ian |
|
From: Darren H. <da...@dv...> - 2009-12-21 17:35:07
|
Hi Mike, Thanks for the response, a couple more questions inline... On Mon, Dec 21, 2009 at 8:40 AM, Mike C. Fletcher <mcf...@vr...> wrote: > Darren Hart wrote: >> I'm looking for a python library to use to do simple 3D-isometric >> renderings embedded in a gtk cabinet cad program. I'm looking to do >> "solid" renderings with all visible edges in black lines with all the >> visible faces a solid white - I don't want to see the occluded parts >> of the cabinet. (if there is a term to describe this, please educate >> me!). I'd like to be able to convert these to a readily printable >> format. >> > A simple depth buffer will remove the hidden lines. You can either do a > shader or a series of line segments/loops to render the edges you want > to display. Normally those will be *just* those edges which the user > thinks of as edges (not the edge of every triangle), so it's likely > easiest just to draw the lines and have full control over them. Are there likely to be existing shaders for something this "simple" or should I plan to write my own? What do you mean by "just draw the lines"? My plan was to have a model of the cabinet in some yet-to-be-determined format and let the yet-to-be-written IsometricGLArea class render it for me. Is this something that would be part of the model or part of the renderer? Or maybe both? > In > terms of printable formats, that depends on whether you want an > SVG/PDF/vector graphic or a simple bitmaps. Everything will easily > produce bitmap images at screen (low) resolution, and many can render to > an off-screen buffer for higher-resolution images. For a vector image > you can use gl2ps or the like, which attempts to hook the low-level GL > and capture the primitives into a buffer. Failing that, math is your > friend (an likely a better approach for a CAD system if you're intending > to use the output as plans). What are you getting at with "math is your friend" - as in: I should write the conversion to vector graphics by hand for best results? I'm very comfortable with math and have written various matrix transformations etc. several years ago. That said, I'd rather focus my very limited hobby time on the problem I am trying to solve: generate plans with 3d-isometric views for cabinets, rather than writing low-level graphics code for something that isn't particularly unique or compute intensive. >> I've looked at several libraries: python-opengl, python-gtkglext, >> python-visual, OSG, VTK, crystal-space, ogre, etc. I don't know enough >> yet to understand how much of an abstraction I need or which of all of >> these is the best starting point. Seeing as how python-opengl would be >> involved in most of these I thought I'd ask here for advice on which >> of these to start trying to learn more about. >> > Your query really needs to include how comfortable you are with > low-level programming and for what you want to optimize. I am Linux kernel developer by trade (core locking code most recently), so I'd say pretty comfortable with "low-level code". However, I have only a few hours experience with OpenGL and am not particularly interested in learning any more of the nitty-gritty than I have to to accomplish the job at hand. As for what I want to optimize for. I mentioned my goals above. I don't need a high frame rate, just something the user can comfortably rotate to get a good view and then print a high quality image along with the cutlist. Eventually I may want to do full kitchen renderings and walkthroughs - but that is years away - if ever, and I suspect I'll need something more like a scenegraph library for that. > OSG is a huge > hammer, it should be able to handle anything you can throw at it, but > it's also a big 3D scenegraph library you'll need to wrap your head > around and package with your app. Agreed. It also doesn't appear to have a very complete or stable python API. I'd rather not have my tiny little python app require such a huge dependency. > PyOpenGL and GTKGLExt (which is just > an OpenGL visual really) are extremely low-level, if you're happy > slinging shaders and arrays-of-vertices, that might be appropriate. Is PyOpenGL sufficient to embed a "drawingarea"-like widget in a gtk app? Do I need GTKGLExt for that? > Crystal-space and Ogre are more focused on the needs of game developers, > but the engines are large collections of rendering processes nicely > packaged from what I hear. VTK is more focused on visualization of > datasets, from what I hear. Choosing one of the big packages means that > someone has likely done all the work for you. Choosing one of the > low-level packages means you have to code it yourself, but it's just > going to do what you've told it to do. Thanks for the insight, very much appreciated. -- Darren Hart > > HTH, > Mike > > -- > ________________________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://www.vrplumber.com > http://blog.vrplumber.com > > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > PyOpenGL Homepage > http://pyopengl.sourceforge.net > _______________________________________________ > PyOpenGL-Users mailing list > PyO...@li... > https://lists.sourceforge.net/lists/listinfo/pyopengl-users > -- Darren Hart |
|
From: Mike C. F. <mcf...@vr...> - 2009-12-21 16:41:05
|
Darren Hart wrote: > I'm looking for a python library to use to do simple 3D-isometric > renderings embedded in a gtk cabinet cad program. I'm looking to do > "solid" renderings with all visible edges in black lines with all the > visible faces a solid white - I don't want to see the occluded parts > of the cabinet. (if there is a term to describe this, please educate > me!). I'd like to be able to convert these to a readily printable > format. > A simple depth buffer will remove the hidden lines. You can either do a shader or a series of line segments/loops to render the edges you want to display. Normally those will be *just* those edges which the user thinks of as edges (not the edge of every triangle), so it's likely easiest just to draw the lines and have full control over them. In terms of printable formats, that depends on whether you want an SVG/PDF/vector graphic or a simple bitmaps. Everything will easily produce bitmap images at screen (low) resolution, and many can render to an off-screen buffer for higher-resolution images. For a vector image you can use gl2ps or the like, which attempts to hook the low-level GL and capture the primitives into a buffer. Failing that, math is your friend (an likely a better approach for a CAD system if you're intending to use the output as plans). > I've looked at several libraries: python-opengl, python-gtkglext, > python-visual, OSG, VTK, crystal-space, ogre, etc. I don't know enough > yet to understand how much of an abstraction I need or which of all of > these is the best starting point. Seeing as how python-opengl would be > involved in most of these I thought I'd ask here for advice on which > of these to start trying to learn more about. > Your query really needs to include how comfortable you are with low-level programming and for what you want to optimize. OSG is a huge hammer, it should be able to handle anything you can throw at it, but it's also a big 3D scenegraph library you'll need to wrap your head around and package with your app. PyOpenGL and GTKGLExt (which is just an OpenGL visual really) are extremely low-level, if you're happy slinging shaders and arrays-of-vertices, that might be appropriate. Crystal-space and Ogre are more focused on the needs of game developers, but the engines are large collections of rendering processes nicely packaged from what I hear. VTK is more focused on visualization of datasets, from what I hear. Choosing one of the big packages means that someone has likely done all the work for you. Choosing one of the low-level packages means you have to code it yourself, but it's just going to do what you've told it to do. HTH, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
|
From: Darren H. <da...@dv...> - 2009-12-21 16:17:53
|
On Mon, Dec 21, 2009 at 12:00 AM, Frédéric <fre...@gb...> wrote: > On lundi 21 décembre 2009, Darren Hart wrote: > >> I'm looking for a python library to use to do simple 3D-isometric >> renderings embedded in a gtk cabinet cad program. I'm looking to do >> "solid" renderings with all visible edges in black lines with all the >> visible faces a solid white - I don't want to see the occluded parts >> of the cabinet. (if there is a term to describe this, please educate >> me!). I'd like to be able to convert these to a readily printable >> format. >> >> I've looked at several libraries: python-opengl, python-gtkglext, >> python-visual, OSG, VTK, crystal-space, ogre, etc. I don't know enough >> yet to understand how much of an abstraction I need or which of all of >> these is the best starting point. Seeing as how python-opengl would be >> involved in most of these I thought I'd ask here for advice on which >> of these to start trying to learn more about. >> >> Also, is there a model format that would be more appropriate than >> others for this sort of application. > > Did you try vpython? I did, it's listed as python-visual in my list above. It was horribly slow, which may have been a configuration or a hardware incompatibility issue. I haven't seen any "cel shaded" examples with vpython either - have you? All in all I thought it might be an overly simplified abstraction for my needs. -- Darren > > -- > Frédéric > > http://www.gbiloba.org > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > PyOpenGL Homepage > http://pyopengl.sourceforge.net > _______________________________________________ > PyOpenGL-Users mailing list > PyO...@li... > https://lists.sourceforge.net/lists/listinfo/pyopengl-users > -- Darren Hart |
|
From: Frédéric <fre...@gb...> - 2009-12-21 08:16:27
|
On lundi 21 décembre 2009, Darren Hart wrote:
> I'm looking for a python library to use to do simple 3D-isometric
> renderings embedded in a gtk cabinet cad program. I'm looking to do
> "solid" renderings with all visible edges in black lines with all the
> visible faces a solid white - I don't want to see the occluded parts
> of the cabinet. (if there is a term to describe this, please educate
> me!). I'd like to be able to convert these to a readily printable
> format.
>
> I've looked at several libraries: python-opengl, python-gtkglext,
> python-visual, OSG, VTK, crystal-space, ogre, etc. I don't know enough
> yet to understand how much of an abstraction I need or which of all of
> these is the best starting point. Seeing as how python-opengl would be
> involved in most of these I thought I'd ask here for advice on which
> of these to start trying to learn more about.
>
> Also, is there a model format that would be more appropriate than
> others for this sort of application.
Did you try vpython?
--
Frédéric
http://www.gbiloba.org
|
|
From: Darren H. <da...@dv...> - 2009-12-21 01:29:50
|
I'm looking for a python library to use to do simple 3D-isometric renderings embedded in a gtk cabinet cad program. I'm looking to do "solid" renderings with all visible edges in black lines with all the visible faces a solid white - I don't want to see the occluded parts of the cabinet. (if there is a term to describe this, please educate me!). I'd like to be able to convert these to a readily printable format. I've looked at several libraries: python-opengl, python-gtkglext, python-visual, OSG, VTK, crystal-space, ogre, etc. I don't know enough yet to understand how much of an abstraction I need or which of all of these is the best starting point. Seeing as how python-opengl would be involved in most of these I thought I'd ask here for advice on which of these to start trying to learn more about. Also, is there a model format that would be more appropriate than others for this sort of application. -- Darren Hart |
|
From: Timothée L. <tim...@lp...> - 2009-12-15 14:10:52
|
Silverstein a écrit : > >> Thanks for your comment. I understand your idea about the FFT. However >> in my case profiling tells that drawing is the bottleneck, not >> processing. To give you a more precise idea, here is the result >> of cProfile on my application: >> http://imgur.com/deMyT.png >> >> > Can you say a bit about what tool you are using to do the profiling > and where I can get it? It looks very useful. > > Herc > Hi Herc, The profile itself is obtained with a standard python profiling module, called cProfile. My main script is called "friture.py", so I run the following command : python -m cProfile -o output.pstats ./friture.py Then, I get profile statistics in the "output.pstats" file, which is then transformed by a script called "gprof2dot.py" to a ".dot" file that can be processed by Graphviz, which finally gives the output png : ./gprof2dot.py -f pstats output.pstats -n 0.1 -e 0.02| dot -Tpng -o output2.png "dot" is part of Graphviz (www.graphviz.org), and "gprof2dot.py" can be found here: http://code.google.com/p/jrfonseca/wiki/Gprof2Dot Best regards, Timothée |
|
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 |
|
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: 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-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: 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-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: Silverstein <her...@sc...> - 2009-12-11 19:02:44
|
> Thanks for your comment. I understand your idea about the FFT. However > in my case profiling tells that drawing is the bottleneck, not > processing. To give you a more precise idea, here is the result > of cProfile on my application: > http://imgur.com/deMyT.png > > Can you say a bit about what tool you are using to do the profiling and where I can get it? It looks very useful. Herc |
|
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: 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-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: Mike C. F. <mcf...@vr...> - 2009-12-11 15:43:17
|
Cata wrote: > Hi ! > I have a issue . > I use Fedora 12 > > I try this code : > import OpenGL > OpenGL.FORWARD_COMPATIBLE_ONLY = True > from OpenGL.GL import * > from OpenGL.GLU import * > > But i have this errors : > ... > from OpenGL.platform import entrypoint31 > ImportError: cannot import name entrypoint31 > Hmm, I don't see the same with the current bzr head. entrypoint31 was only used in 3.0.0, between 3.0.0 and 3.0.1 the ARB's extension header started providing the information necessary to automate the tracking of deprecated entry points. entrypoint31 was still part of the distribution in the last 3.0.1 beta release, however (i.e. I hadn't removed the file), so you shouldn't see a crash. Can you tell me the PyOpenGL version (python -c "from OpenGL import __version__; print __version__") where you're seeing this? It's possible some release missed the entrypoints31 file when being packed. I've added a test that imports all of GL, GLU and GLUT with deprecations turned on to the PyOpenGL tests. Good luck, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
|
From: René D. <re...@gm...> - 2009-12-11 14:54:55
|
2009/12/11 Ian Mallett <geo...@gm...>:
> Some things definitely change, though--at least they do for me.
>
> Simply replacing "from OpenGL.GL import *" with "from OpenGL.raw.GL import
> *" gives problems.
>
> For example, glGenTextures(1) whines about needing two arguments. Does it
> want a numpy array or something?
>
> Ian
>
hi,
yeah, the raw ones don't do all the nice pythony things for you.
So using import * from the raw ones is probably not a good idea... but
to instead use it only for the slow, or problematic functions.
In this case glGenTextures is much like the C version.
void glGenTextures(GLsizei n, GLuint * textures);
So you need to pass it a pointer to some data where it will write your data.
You can see the argument types like this:
>>> OpenGL.raw.GL.glGenTextures._argtypes_
(<class 'ctypes.c_long'>, <class 'OpenGL.arrays.arraydatatype.GLuintArray'>)
And give it the array to store a GLuint.
>>> a = numpy.array([1], numpy.uint32)
>>> OpenGL.raw.GL.glGenTextures(1, a)
cu,
|
|
From: Mike C. F. <mcf...@vr...> - 2009-12-11 14:50:36
|
Ian Mallett wrote: > Some things definitely change, though--at least they do for me. > > Simply replacing "from OpenGL.GL import *" with "from OpenGL.raw.GL > <http://OpenGL.raw.GL> import *" gives problems. > > For example, glGenTextures(1) whines about needing two arguments. > Does it want a numpy array or something? Any of a numpy array, ctypes array, or ctypes byref( ctypes c_int ) for the single-int case. You'll find that pattern repeating all through your code-base, basically OpenGL seldom allocates memory, so anywhere something "returns" an array in PyOpenGL you will have to allocate the array yourself and pass it into the GL call for the raw APIs. All glGet* calls, for instance, will need to be altered. You'll also find that many array APIs will require the "full" form where you specify data-types, strides and the like (since you're using VBOs already, that shouldn't be a challenge for you). Upshot is, after you've done all that your code should work pretty-much unmodified with any raw OpenGL wrapper (SWIG, pyglet, Cython, etc). HTH, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
|
From: Cata <cat...@gm...> - 2009-12-11 13:49:06
|
Hi !
I have a issue .
I use Fedora 12
I try this code :
import OpenGL
OpenGL.FORWARD_COMPATIBLE_ONLY = True
from OpenGL.GL import *
from OpenGL.GLU import *
But i have this errors :
Error is python
Python 2.6.2 (r262:71600, Aug 21 2009, 12:22:21)
[GCC 4.4.1 20090818 (Red Hat 4.4.1-6)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import OpenGL
>>> OpenGL.FORWARD_COMPATIBLE_ONLY = True
>>> from OpenGL.GL import *
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python2.6/site-packages/OpenGL/GL/__init__.py", line
2, in <module>
from OpenGL.raw.GL import *
File "/usr/lib/python2.6/site-packages/OpenGL/raw/GL/__init__.py",
line 6, in <module>
from OpenGL.raw.GL.constants import *
File "/usr/lib/python2.6/site-packages/OpenGL/raw/GL/constants.py",
line 7, in <module>
from OpenGL import platform, arrays
File "/usr/lib/python2.6/site-packages/OpenGL/platform/__init__.py",
line 36, in <module>
_load()
File "/usr/lib/python2.6/site-packages/OpenGL/platform/__init__.py",
line 27, in _load
plugin_class = plugin.load()
File "/usr/lib/python2.6/site-packages/OpenGL/plugins.py", line 14, in load
return importByName( self.import_path )
File "/usr/lib/python2.6/site-packages/OpenGL/plugins.py", line 28,
in importByName
module = __import__( ".".join(moduleName), {}, {}, moduleName)
File "/usr/lib/python2.6/site-packages/OpenGL/platform/glx.py", line
3, in <module>
from OpenGL.platform import baseplatform, ctypesloader
File "/usr/lib/python2.6/site-packages/OpenGL/platform/baseplatform.py",
line 10, in <module>
from OpenGL.platform import entrypoint31
ImportError: cannot import name entrypoint31
--
My sites:
http://catalin-festila.blogspot.com -about me
http://tv.free-tutorials.org - video tutorials
http://python-catalin.blogspot.com - my python blog
|
|
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 |
74 messages has been excluded from this view by a project administrator.
