pyopengl-users Mailing List for PyOpenGL (Page 64)
Brought to you by:
mcfletch
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: Neal H. <nh...@do...> - 2008-01-08 20:53:50
|
Hi, I tried to find the answer myself -- I really did -- but now I seem to be at a dead end. This worked in 2.0.1.09.dfsg.1-0.3 on ubuntu feisty: def handleSelect( self, index ): """Handle menu item selection by calling the handler specified in the menu description.""" try: name, fn = self.dispatchTable[index] except: return if callable(fn): fn() def create_menu( self, items ): """Create the open GL menu based on the menu descriptor in 'items'.""" id = glutCreateMenu( self.handleSelect ) ... but not in 3.0.0 on ubutnu gutsy. On that last line ("id = glutCreateMenu...") I get: Traceback (most recent call last): File "./viewframe", line 21, in <module> app = FrameViewer( fd=framedata ) File "../OpenGL/GLFramework.py", line 90, in __init__ self.init_GL() File "../OpenGL/GLFramework.py", line 358, in init_GL m = GLMenu( menu ) File "../OpenGL/GLFramework.py", line 853, in __init__ self.create_menu( items ) File "../OpenGL/GLFramework.py", line 868, in create_menu id = glutCreateMenu( self.handleSelect ) File "/usr/lib/python2.5/site-packages/OpenGL/GLUT/special.py", line 165, in glutCreateMenu result = simple.glutCreateMenu( cCallback ) ctypes.ArgumentError: argument 1: <type 'exceptions.TypeError'>: expected CFunctionType instance instead of CFunctionType ----------------------------------- Some of the other problems I had when searching for solution: 1. In the documentation, http://pyopengl.sourceforge.net/documentation/manual/glutCreateMenu.3GLUT.xml clicking on the Python Sample Code link at the bottom results in a server timeout (cvs.sourceforge...) 2. Ubuntu feisty had the Demo/suit/GLUT.py file, but there was nothing obvious from looking at that (of course, it was on a system whose version worked). 3. Ubuntu gutsy doesan't have that file, nor could I find it in any of the places I looked. Thanks neal -- Neal Holtz http://cee.carleton.ca/~nholtz Dept. of Civil and Environmental Engineering, Carleton University, Ottawa, Ontario, Canada K1S 5B6. nh...@do... |
From: Dirk R. <di...@li...> - 2008-01-08 16:00:46
|
Hi Adeola, Adeola Bannis wrote: > Well, > > Now I have a recognisable image that just seems to be "twisted funny" > (not again...), after I decided to use GL_UNSIGNED_BYTE instead of > GL_FLOAT. I think the strange orientation of my picture might just be > due to placing the corners in the wrong order or some such. Last time, > I resolved the whole "twisted funny" problem with an offset of +/-1. > It's also a bit dark, but that's definitely fixable. Here's a picture > of the "funny looking" image to compare to the "good" image I sent > earlier. > > Thank you so much for all your help - I think the ctypes call made the > difference between rendering gook and rendering the texture. I don't have much experience with PyOpenGL, but I do with OpenGL, so take the following with a grain of salt. The most common reason for 'twisted funny' images is forgetting to set GL_PACK_ALIGNMENT resp. GL_UNPACK_ALIGNMENT to 1 in glPixelStore. By default OpenGL assumes image rows to start on 32-bit aligned addresses, which for RGB byte images is only true if the width is a multiple of 4. Hope it helps Dirk |
From: Adeola B. <the...@gm...> - 2008-01-08 15:10:25
|
Well, Now I have a recognisable image that just seems to be "twisted funny" (not again...), after I decided to use GL_UNSIGNED_BYTE instead of GL_FLOAT. I think the strange orientation of my picture might just be due to placing the corners in the wrong order or some such. Last time, I resolved the whole "twisted funny" problem with an offset of +/-1. It's also a bit dark, but that's definitely fixable. Here's a picture of the "funny looking" image to compare to the "good" image I sent earlier. Thank you so much for all your help - I think the ctypes call made the difference between rendering gook and rendering the texture. Adeola On Jan 5, 2008 5:03 PM, Mike C. Fletcher <mcf...@vr...> wrote: > Adeola Bannis wrote: > > Thanks Mike, > > > > It wasn't so much a script I sent as a class definition. There > > probably should have been some main function for testing, but I didn't > > feel like writing up the wxApp. > > > > I don't currently have OpenGLContext installed, so I can't (yet) > > directly run your code. > > The +1 in the dimensions were necessary in my code before, at least in > > the horizontal direction - otherwise the image had a characteristic > > "twist". I had already tried it without them, but with little > > improvement. If you're interested I've attached the image I get with > > pylab.imshow() and the image I get on my GLCanvas. > > > > I tried the image.ctypes.data_as() conversion, but then my program > > segfaults whenever it gets to the gluBuild2DMipmaps call. > > > The problem I'm having here is that I can't reproduce your failure, as > your code doesn't seem to include the failing code (though as I > mentioned, the off-by-one dimensions are suspicious). I've got my > float-based image displaying properly with the code I sent you. The > most likely sources of segfaulting is that you're passing a > non-contiguous array, or you are passing dimensions that are too large. > Either one will cause OpenGL to overstep it's array bounds. In your > code you are calling contiguous and then throwing away the result IIRC, > any chance you intended to use those results? > > Good luck, > > Mike > > -- > ________________________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://www.vrplumber.com > http://blog.vrplumber.com > > |
From: Keszegh C. <el...@ma...> - 2008-01-07 20:08:18
|
Hi All, I have installed the latest release (from CVS), and wanted to try the basics with shaders. There were some problems with the default install: basplatform.py:234 func = functionTypeFor( self.DLL )( should be func = platform.PLATFORM.functionTypeFor( self.DLL )( Another issue, when i try to use the Pythonic interface of some extension (glShaderSource) with python objects, it doesnt exists. It seems, that the extensions could only be queried with valid OpenGL context (only on windows?). So they are unavailable (null-functions) at module load time, and the wrappers get not defined. If i force to define the wrappers they work. Is there a pythonic way how initialization can be done? My last problem is with glutReshapeFunc. After the second call of the callback the program exists. What am i doing wrong? The source is attached. Please consider that i'm new to python ;) Regards, Csaba -- |
From: Hart's A. <bha...@ya...> - 2008-01-05 23:09:37
|
Hi Mike, sorry for the late reply, i just tried your saveimage.py but am unable to run it, it crashes with this error glibc detected *** python: free(): invalid pointer: 0x08860808 i'm using the latest release of OpenGLContext, i installed from source via python setup.py install - no errors i could see. I think my problem might be in Ubuntu, python2.5 in Gusty seems to crash pretty often. I did try adjusting to a narrower z-range as you suggest in my own tests, but that had no effect. I will test on a Nvida machine next week, maybe my problems are from the ATI drivers. -brett ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs |
From: Mike C. F. <mcf...@vr...> - 2008-01-05 22:03:18
|
Adeola Bannis wrote: > Thanks Mike, > > It wasn't so much a script I sent as a class definition. There > probably should have been some main function for testing, but I didn't > feel like writing up the wxApp. > > I don't currently have OpenGLContext installed, so I can't (yet) > directly run your code. > The +1 in the dimensions were necessary in my code before, at least in > the horizontal direction - otherwise the image had a characteristic > "twist". I had already tried it without them, but with little > improvement. If you're interested I've attached the image I get with > pylab.imshow() and the image I get on my GLCanvas. > > I tried the image.ctypes.data_as() conversion, but then my program > segfaults whenever it gets to the gluBuild2DMipmaps call. > The problem I'm having here is that I can't reproduce your failure, as your code doesn't seem to include the failing code (though as I mentioned, the off-by-one dimensions are suspicious). I've got my float-based image displaying properly with the code I sent you. The most likely sources of segfaulting is that you're passing a non-contiguous array, or you are passing dimensions that are too large. Either one will cause OpenGL to overstep it's array bounds. In your code you are calling contiguous and then throwing away the result IIRC, any chance you intended to use those results? Good luck, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
From: Adeola B. <the...@gm...> - 2008-01-05 19:31:30
|
Thanks Mike, It wasn't so much a script I sent as a class definition. There probably should have been some main function for testing, but I didn't feel like writing up the wxApp. I don't currently have OpenGLContext installed, so I can't (yet) directly run your code. The +1 in the dimensions were necessary in my code before, at least in the horizontal direction - otherwise the image had a characteristic "twist". I had already tried it without them, but with little improvement. If you're interested I've attached the image I get with pylab.imshow() and the image I get on my GLCanvas. I tried the image.ctypes.data_as() conversion, but then my program segfaults whenever it gets to the gluBuild2DMipmaps call. On Jan 4, 2008 3:56 PM, Mike C. Fletcher <mcf...@vr...> wrote: > When I alter your code to actually run (the attached script doesn't seem > to do anything) I wind up with a working script. It does point to a bug > in the current PyOpenGL 3.0.0b1's handling of void pointer arrays (they > are supposed to auto-convert numpy arrays, but I had to explicitly > extract a void pointer to make it work). I note that your spec for the > image size is wrong, you're adding 1 to the dimensions, which should not > be necessary, and could have the effect you described (garbled, with > black pixels). > > I've attached what I'm running, so you can point out what's different. > > Enjoy, > Mike > > -- > ________________________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://www.vrplumber.com > http://blog.vrplumber.com > > |
From: Mike C. F. <mcf...@vr...> - 2008-01-04 20:56:17
|
Adeola Bannis wrote: > Hi everyone, > > I'm doing a project using wxPython and pyopengl, and I seem to have a > problem rendering textures. This is code that worked before my hard > drive had a meltdown, but not since I re-installed everything. > > I've determined the problem is in the OpenGL part of my program. I do > some calculations to generate a 2D numpy array that holds the image > data, and pylab.imshow() shows me the image as it is meant to be. I > used the same algorithm in Octave and MATLAB, and all are giving me > the right picture. > > However, using pyOpenGL and the numpyhandler functions (http://cours- > info.iut-bm.univ-fcomte.fr/docs/python/OpenGL/ > OpenGL.arrays.numpymodule.NumpyHandler-class.html) doesn't seem to > work. I get a garbled screen pocked with black pixels. I am including > my openGL code below. What am I doing wrong? > > And yes, I did make the dtype of my array 'float32'. > When I alter your code to actually run (the attached script doesn't seem to do anything) I wind up with a working script. It does point to a bug in the current PyOpenGL 3.0.0b1's handling of void pointer arrays (they are supposed to auto-convert numpy arrays, but I had to explicitly extract a void pointer to make it work). I note that your spec for the image size is wrong, you're adding 1 to the dimensions, which should not be necessary, and could have the effect you described (garbled, with black pixels). I've attached what I'm running, so you can point out what's different. Enjoy, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
From: Adeola B. <the...@gm...> - 2008-01-04 19:18:39
|
Hi everyone, I'm doing a project using wxPython and pyopengl, and I seem to have a problem rendering textures. This is code that worked before my hard drive had a meltdown, but not since I re-installed everything. I've determined the problem is in the OpenGL part of my program. I do some calculations to generate a 2D numpy array that holds the image data, and pylab.imshow() shows me the image as it is meant to be. I used the same algorithm in Octave and MATLAB, and all are giving me the right picture. However, using pyOpenGL and the numpyhandler functions (http://cours- info.iut-bm.univ-fcomte.fr/docs/python/OpenGL/ OpenGL.arrays.numpymodule.NumpyHandler-class.html) doesn't seem to work. I get a garbled screen pocked with black pixels. I am including my openGL code below. What am I doing wrong? And yes, I did make the dtype of my array 'float32'. -------code snippets------ import wx from wx.glcanvas import GLCanvas from OpenGL.GLU import * from OpenGL.GL import * from OpenGL.arrays.numpymodule import NumpyHandler PC = 1 RI = 0 class myGLCanvas(GLCanvas): def __init__(self, parent): GLCanvas.__init__(self, parent,-1) wx.EVT_PAINT(self, self.OnPaint) self.init = 0 self.mode = -1 # making a texture for the range image self.texture = glGenTextures(1) # making a spot for the point cloud points self.cloud = None return def OnPaint(self,event): dc = wx.PaintDC(self) self.SetCurrent() if not self.init: self.InitGL() self.init = 1 self.OnDraw() return def OnDraw(self): glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT) if self.mode == RI: self.drawRange() elif self.mode == PC: self.drawCloud() def InitGL(self): glClearColor(0.0, 0.0, 0.0, 0.0); glClearDepth(1.0) glEnable(GL_DEPTH_TEST) glDepthFunc(GL_LEQUAL) glClear(GL_COLOR_BUFFER_BIT) glPixelStorei(GL_UNPACK_ALIGNMENT, 1) glPixelStorei(GL_PACK_ALIGNMENT, 1) #NTSC colour scales... glPixelTransferf(GL_RED_SCALE, 0.299); glPixelTransferf(GL_GREEN_SCALE, 0.587); glPixelTransferf(GL_BLUE_SCALE, 0.114); glMatrixMode(GL_PROJECTION) glLoadIdentity() glOrtho(0.0,1.0,0,1.0,-1.0,1.0) glMatrixMode(GL_MODELVIEW) glLoadIdentity() return def rangeImage(self, image): glBindTexture(GL_TEXTURE_2D, self.texture) glTexEnvf( GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE ) glTexParameterf (GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR) glTexParameterf (GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR) glTexParameterf (GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_REPEAT) glTexParameterf (GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_REPEAT) # flatten it into a list so the OpenGL calls work n = NumpyHandler() fI = image.flatten() flatImage = n.dataPointer(n.contiguous(fI)) print n.contiguous(fI) gluBuild2DMipmaps(GL_TEXTURE_2D, 1, image.shape[0]+1, image.shape[1]+1, GL_LUMINANCE, GL_FLOAT, flatImage) self.mode = RI self.OnDraw() def drawRange(self): ''' Controls the actual drawing of the range image''' glMatrixMode(GL_MODELVIEW) glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT) glColor3f(1.0,1.0,1.0) glEnable(GL_TEXTURE_2D) glBindTexture(GL_TEXTURE_2D, self.texture) glBegin(GL_TRIANGLE_FAN) glTexCoord2d(1,1); glVertex3f(0.0, 0.0, 0.0) glTexCoord2d(1,0); glVertex3f(0.0, 1.0, 0.0) glTexCoord2d(0,0); glVertex3f(1.0, 1.0, 0.0) glTexCoord2d(0,1); glVertex3f(1.0, 0.0, 0.0) glEnd() self.SwapBuffers() --------end snippet----------- |
From: Mike C. F. <mcf...@vr...> - 2008-01-02 04:30:42
|
Festila Catalin wrote: > Hello! I use linux-debian . > I use Standard Install (setuptools/egg based) and not work for glprint.py glprint is a Win32-only demonstration (it's an adaptation of of a NeHe tutorial that uses wgl* calls to render text). That said, the problems you're encountering are not likely due to that issue. Setting up OpenGLContext is rather difficult at the moment. I've just put together .egg and source distributions for all of the dependencies and registering them in the Python Package index. The following *should* work, but hasn't been tested on a Linux machine yet (just haven't had time to build a chroot or image in which to work): easy_install OpenGLContext easy_install SimpleParse easy_install TTFQuery OpenGLContext 2.1 (released today) is, incidentally, the first release to be compatible with PyOpenGL 3.x. Eventually Debian might have an OpenGLContext package, but until then the easy_install path is probably the "correct" way. Good luck, Mike > 1.What is the correct method to install OpenGLContext on my debian ? > > 2.The text on site say :" OpenGLContext is a learning environment for > PyOpenGL. " but is so hard to install :( -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
From: Festila C. <cat...@gm...> - 2008-01-01 13:52:12
|
Hello! I use linux-debian . I use Standard Install (setuptools/egg based) and not work for glprint.py I try python glprint.py Traceback (most recent call last): File "glprint.py ", line 25, in ? from OpenGLContext.wxinteractivecontext import wxInteractiveContext File "/usr/lib/python2.4/site-packages/OpenGLContext/wxinteractivecontext.py", line 2, in ? from OpenGLContext import interactivecontext, wxcontext, context, viewplatformmixin File "/usr/lib/python2.4/site-packages/OpenGLContext/interactivecontext.py", line 2, in ? from OpenGLContext import context File "/usr/lib/python2.4/site-packages/OpenGLContext/context.py", line 33, in ? from OpenGLContext import renderpass, visitor, texturecache File "/usr/lib/python2.4/site-packages/OpenGLContext/renderpass.py", line 16, in ? from OpenGLContext import visitor, rendervisitor, displaylist, frustum, utilities File "/usr/lib/python2.4/site-packages/OpenGLContext/visitor.py", line 3, in ? from OpenGLContext.scenegraph import nodepath File "/usr/lib/python2.4/site-packages/OpenGLContext/scenegraph/nodepath.py", line 3, in ? from vrml.vrml97 import nodepath, nodetypes File "/usr/lib/python2.4/site-packages/vrml/vrml97/nodepath.py", line 4, in ? from vrml import nodepath File "/usr/lib/python2.4/site-packages/vrml/nodepath.py", line 3, in ? from vrml import node, weaktuple File "/usr/lib/python2.4/site-packages/vrml/node.py", line 6, in ? from vrml import field, fieldtypes, weaklist, weakkeydictfix File "/usr/lib/python2.4/site-packages/vrml/field.py", line 2, in ? from dispatch import dispatcher, robustapply ImportError: cannot import name dispatcher I try to install OpenGLContext-2.0.0c1 on my home directory , but i have some problems . First PyDispatcher-2.0.0 . I put files from arhive over ~/OpenGLContext-2.0.0c1$ python setup.pyinstall running install running build running build_py copying ./extensionmanager.py -> build/lib/pydispatch ... copying ./tests/indexedlinesetobject.py -> build/lib/pydispatch/tests copying ./tests/cubebackgroundobject.py -> build/lib/pydispatch/tests copying ./tests/getteximage.py -> build/lib/pydispatch/tests error: package directory './examples' does not exit 1.What is the correct method to install OpenGLContext on my debian ? 2.The text on site say :" OpenGLContext is a learning environment for PyOpenGL. " but is so hard to install :( Thanks ! |
From: Jordan H. <rap...@gm...> - 2008-01-01 09:34:38
|
Hey there, I'm attempting to create dynamic, context-sensitive pop-up menus with the glutCreateMenu() and associated functions. My most significant issue at the moment is that triggering a pop-up menu (ie, clicking the mouse button to which the menu is bound) correctly causes the menu to appear, but selecting any option from the list causes Python to throw an Access Violation error originating in glutMainLoop(): Traceback (most recent call last): File "C:\Utilities\OpenGL\My Prog.py", line 1176, in <module> main() File "C:\Utilities\OpenGL\My Prog.py", line 274, in main glutMainLoop() WindowsError: exception: access violation writing 0x00000000 The given memory address is usually very low, 0x00000000 or 0x00000001 (I don't know whether this is significant or helpful). The error causes the rendering window to hang, and the python interpreter returns to a command prompt, as if the running program had ended. The rendering window must be forced to end and close by Windows. I wonder whether this error stems from the fact I'm simply trying to stretch the GLUT popup menus beyond their intended capabilities in a clumsy way, or if it's got something to do with conflicting glutMouseFunc() bindings when the popups try to add in their own callbacks on top of the context-based picking functions I'm already using (exactly how do the popups effect the bindings I'm already using? Does the next mouse-click to follow the opening of a popup menu get ignored by the currently bound MouseFunc callback and get handled by a seperate, specific popup handler?). The latter seems unlikely as I've tried doing some isolated testing of the most basic popup-functionality (where glutMouseFunc() isn't otherwise defined, except indirectly through glutAttachMenu()), and the Access Violation still occurs when a menu selection is made. Any suggestions? Thanks, Jordan |
From: Mike C. F. <mcf...@vr...> - 2007-12-31 05:29:33
|
Jordan Hume wrote: > Hi, > > I'm new to OpenGL programming, and I'm having problems creating popup > menus with glutCreateMenu() in PyOpenGL. When I call > glutCreateMenu(FunctionName), Python throws a TypeError: > > File "build\bdist.win32\egg\OpenGL\GLUT\special.py", line 165, in > glutCreateMenu > result = simple.glutCreateMenu( cCallback ) > ArgumentError: argument 1: <type 'exceptions.TypeError'>: expected > CFunctionType instance instead of CFunctionType > > This error confuses me - I read the 'expected' part to mean "Python > wanted cheese, but instead got... cheese." I'm sorry if I'm missing > something blatantly obvious here, but can someone please help me by > explaining why Python says it wants cheese and then won't eat the > cheese I give it? An approximation of (hopefully all) the > relavent code is below: I just fixed a critical bug in win32 callback handling. Most likely you're seeing that. If you are seeing this on 3.0.0b1, then we may have more problems there, if not, please upgrade and see if that fixes the problem. HTH, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
From: Jordan H. <rap...@gm...> - 2007-12-31 03:44:03
|
Hi, I'm new to OpenGL programming, and I'm having problems creating popup menus with glutCreateMenu() in PyOpenGL. When I call glutCreateMenu(FunctionName), Python throws a TypeError: File "build\bdist.win32\egg\OpenGL\GLUT\special.py", line 165, in glutCreateMenu result = simple.glutCreateMenu( cCallback ) ArgumentError: argument 1: <type 'exceptions.TypeError'>: expected CFunctionType instance instead of CFunctionType This error confuses me - I read the 'expected' part to mean "Python wanted cheese, but instead got... cheese." I'm sorry if I'm missing something blatantly obvious here, but can someone please help me by explaining why Python says it wants cheese and then won't eat the cheese I give it? An approximation of (hopefully all) the relavent code is below: ________________________________________ MenuA = 0 MenuA = 0 def InitGL(): ## Initialize PyOpenGL def InitPopupMenus(): global MenuA, MenuB ## Note that these menus should get swapped during execution using glutSetMenu() & glutAttachMenu() MenuA = glutCreateMenu(HandlePopupMenuClick) ## This line throws the error glutAddMenuEntry("Option 1", "OPTION1") glutAddMenuEntry("Option 2", "OPTION2") glutAddMenuEntry("Option 3", "OPTION3") MenuB = glutCreateMenu(HandlePopupMenuClick) ## This line would throw the error, too glutAddMenuEntry("Option 1", "OPTION1") glutAddMenuEntry("OPtion 4", "OPTION4") ######## ## All the relavent Display, Reshape, backend functions and the like ######## def HandlePopupMenuClick(Value): ## Process popup menu selection def Main(): ##Initialize GLUT, register Display, Reshape, Idle etc. functions InitGL() InitPopupMenus() glutMainLoop() Main() ________________________________________ Thanks, J. |
From: Mike C. F. <mcf...@vr...> - 2007-12-29 23:40:26
|
Hart's Antler wrote: > --- "Mike C. Fletcher" <mcf...@vr...> wrote: > ... > i dont have a stripped down example, but the code is just 3 lines you can insert into any pyopengl > demo. > data = glReadPixels(0,0,x,y, GL_DEPTH_COMPONENT, GL_UNSIGNED_BYTE) # note x,y are screen size > img = Image.fromstring( 'L', (x,y), data ) # requires PIL > img.save( 'z.bmp' ) # when you open z.bmp you will find that it is blank - all white. > I can reproduce the effect you are reporting if I have a large frustum where the near and far clipping plans are at .01 and 1000 respectively. If I bring those down so that the geometry is just bracketed by the clipping planes, the depth buffer "image" shows up as black for that touching the front clipping plane (lowest depth) and white for that touching the back clipping plane (highest depth). That is, the wrapper *seems* to be working fine (though the extremely high (.999+) values in the float mode with a large frustum surprise me, they *seem* to represent real depth values). The code I'm using to test is available in the CVS here: http://pyopengl.cvs.sourceforge.net/pyopengl/OpenGLContext/tests/saveimage.py?view=markup You can see the commented-out code that uses GL_FLOAT type and maps the values to the 0-255 range using array operations as well. I'm open to the possibility that something is going wrong in the wrapper, but it *looks* like something unexpected in the GL, rather than something wrong with the wrapper. This URL http://www.opengl.org/resources/faq/technical/depthbuffer.htm would seem to suggest that the likely culprit for this kind of error is specifying a zNear which is too near to the camera. Hope this helps, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
From: Hart's A. <bha...@ya...> - 2007-12-28 19:32:46
|
--- "Mike C. Fletcher" <mcf...@vr...> wrote: > Hart's Antler wrote: > > I am using the latest pyopengl (ctypes based) release for Ubuntu Gusty. I am unable to read > the > > zbuffer using glreadpixels GL_DEPTH_COMPONENT, my function had worked before with the much > older > > pyopengl2.x series. I'm not sure if this is a bug in new ctypes-pyopengl or is it my ATI > drivers > > not supporting that feature. I'm wondering if anybody has had any luck doing this? One note > is > > that i can read the zbuffer directly into a texture (for shadows) with no problem using > glCopyTexSub2d. > > > If you can send me a sample script that demonstrates the problem I can > far more easily fix the bug. It does sound like a bug, incidentally. > The image handling code is completely rewritten, so it's not unlikely > there would be differences between the old and new implementations. > i dont have a stripped down example, but the code is just 3 lines you can insert into any pyopengl demo. data = glReadPixels(0,0,x,y, GL_DEPTH_COMPONENT, GL_UNSIGNED_BYTE) # note x,y are screen size img = Image.fromstring( 'L', (x,y), data ) # requires PIL img.save( 'z.bmp' ) # when you open z.bmp you will find that it is blank - all white. ____________________________________________________________________________________ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping |
From: Mike C. F. <mcf...@vr...> - 2007-12-28 18:55:52
|
Hart's Antler wrote: > I am using the latest pyopengl (ctypes based) release for Ubuntu Gusty. I am unable to read the > zbuffer using glreadpixels GL_DEPTH_COMPONENT, my function had worked before with the much older > pyopengl2.x series. I'm not sure if this is a bug in new ctypes-pyopengl or is it my ATI drivers > not supporting that feature. I'm wondering if anybody has had any luck doing this? One note is > that i can read the zbuffer directly into a texture (for shadows) with no problem using glCopyTexSub2d. > If you can send me a sample script that demonstrates the problem I can far more easily fix the bug. It does sound like a bug, incidentally. The image handling code is completely rewritten, so it's not unlikely there would be differences between the old and new implementations. Take care, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
From: Hart's A. <bha...@ya...> - 2007-12-28 18:44:27
|
I am using the latest pyopengl (ctypes based) release for Ubuntu Gusty. I am unable to read the zbuffer using glreadpixels GL_DEPTH_COMPONENT, my function had worked before with the much older pyopengl2.x series. I'm not sure if this is a bug in new ctypes-pyopengl or is it my ATI drivers not supporting that feature. I'm wondering if anybody has had any luck doing this? One note is that i can read the zbuffer directly into a texture (for shadows) with no problem using glCopyTexSub2d. ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs |
From: Andrew W. <and...@al...> - 2007-12-24 14:34:57
|
Take a look at the pyfx project; I've gotten their version of pycg to work. http://graphics.cs.lth.se/pyfx/download/ Thanks Andrew On Dec 24, 2007 3:30 AM, JoN <jo...@we...> wrote: > Hello > > I am trying to run lesson47 from the NeHe site, the python implementation. > > I have Python 2.5 on Win32 (doze XP). > Other Python stuff runs Ok. > > Trying to import the Cg module. > > I found an old version of PyCg but its made using SWIG which I don't > understand > (not about to either unless I'm driven to it). It can't import its own > _Cg.dll, > I dont know why, the installer put everything in site-packages. > > Is there a more current verson of PyCg around or are we all stuffed on > this point? > > Or is it a path/setup problem and there is something I can change to make > it import? > > Best Regs > > Jon Holdsworth > > -------------------------------------------------------------------- > Come and visit Web Prophets Website at http://www.webprophets.net.au > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > PyOpenGL Homepage > http://pyopengl.sourceforge.net > _______________________________________________ > PyOpenGL-Users mailing list > PyO...@li... > https://lists.sourceforge.net/lists/listinfo/pyopengl-users > |
From: JoN <jo...@we...> - 2007-12-24 11:29:30
|
Hello I am trying to run lesson47 from the NeHe site, the python implementation. I have Python 2.5 on Win32 (doze XP). Other Python stuff runs Ok. Trying to import the Cg module. I found an old version of PyCg but its made using SWIG which I don't understand (not about to either unless I'm driven to it). It can't import its own _Cg.dll, I dont know why, the installer put everything in site-packages. Is there a more current verson of PyCg around or are we all stuffed on this point? Or is it a path/setup problem and there is something I can change to make it import? Best Regs Jon Holdsworth -------------------------------------------------------------------- Come and visit Web Prophets Website at http://www.webprophets.net.au |
From: David B. <whi...@gm...> - 2007-12-20 06:25:03
|
On Dec 16, 2007 12:32 PM, Mike C. Fletcher <mcf...@vr...> wrote: > David Bronke wrote: > > I'm using GL_SELECT to select objects in my application, and I'm > > getting some strange behavior. It seems that the selection buffer is > > never reset, even though I am calling glRenderMode (GL_RENDER) after > > selection, and am calling glSelectBuffer () before each selection. > > Here's my code: > ... > > GL.glRenderMode (mode) > That's the line that should reset the internal counter inside your > OpenGL implementation that determines how many results should be returned: > > An internal index into buffer is reset to 0 whenever selection mode > is entered. Each time a hit record is copied into buffer, the index > is incremented to point to the cell just past the end of the block > of names - that is, to the next available cell. If the hit record is > larger than the number of remaining locations in buffer, as much > data as can fit is copied, and the overflow flag is set. If the name > stack is empty when a hit record is copied, that record consists of > 0 followed by the minimum and maximum depth values. > > We do a little bit of custom code, but AFAICS we should not be able to > influence the number of hits returned by the selection buffer (see > OpenGL/GL/selection.py and OpenGL/GL/pointers.py for the actual code). > That is, when you enter the mode the count should be reset. When you > exit the mode it returns the internal count. > > The buffer remaining the same should *not* be a problem, incidentally, > even if it were. We copy the reported number of records out of the > buffer, and GL should be writing new records for every record it reports > as having been copied in, so though there might be "garbage" at the end > of the array, it should *not* affect your results or the number of them > reported. > > Any ideas what I'm doing wrong? > It might be easiest to debug if you printed out the names of each > element you are seeing in the buffer. Stop after the first few frames > and check to see *how* those names are getting added. If you can > disable the display-list usage (i.e. call the rendering code each time) Actually, I don't use display lists for the actual geometry at all; that's all done in immediate mode, as are the glLoadName calls. I'm not using Push/Pop, because I don't really have any nested geometry... would it be advisable to switch over to Push/Pop anyway? I was missing the closing glPopName() call in paintGL() though, so I put that back in, and realized that my way of calculating the names needed to change. I was trying to coerce the signed int object ids generated by python's id() call into unsigned ints so I could use them as names, and then get them back as valid ids... instead I just switched to an auto-increment ID for the objects, which seems to work great. I'm pretty sure the root of the problem was the lack of a glPopName() at the end of paintGL(), since effectively the name stack was simply growing without bound until it overflowed the select buffer. Thanks for the help! you should be able to trace through and see each call to glPushName and > glPopName. If you are not balancing those two you may be getting a > run-away stack of names that are left on the stacks between runs. You > could use an assert that GL_NAME_STACK_DEPTH is 0 to be sure you've done > it, if you don't want to disable display lists. > > Good luck, > Mike > > -- > ________________________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://www.vrplumber.com > http://blog.vrplumber.com > > -- David H. Bronke Vice President of Project Development G33X Nexus Entertainment http://www.g33xnexus.com/ v3sw5/7Hhw5/6ln4pr6Ock3ma7u7+8Lw3/7Tm3l6+7Gi2e4t4Mb7Hen5g8+9ORPa22s6MSr7p6 hackerkey.com Support Web Standards! http://www.webstandards.org/ |
From: Mike C. F. <mcf...@vr...> - 2007-12-16 21:12:22
|
altern wrote: > sorry, this was on windows XP with python 2.5 and pyopengl3.0.0a6-py2.5.egg > > altern(e)k dio: > >> hi >> >> I am porting an old app to the new PyOPenGL and I get an error at >> >> glRectfv( vlist[0], vlist[2] ) >> >> It says >> >> "wrappercall types.Argument.Error: ("argument 1: <type >> 'exceptions.TypeError'>: byref() argument must be ctypes instance, not >> 'tuple', [(-5.5, -5.5), <OpenGL.arrays.listsc_floatArray_2 object at >> 0x02x10210>])" >> Neat, it was a pretty stupid little bug. I wrapped the function with a type annotation for the first argument and then immediately threw away that annotated function when I wrapped the base function again to annotate the second argument. That said, I wasn't able to reproduce the precise error (though I got lots of other wonky errors with glRectf as a result of the problem). Hopefully that will take care of your issue too, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
From: Mike C. F. <mcf...@vr...> - 2007-12-16 20:25:08
|
duncan duncan wrote: > Hello to everyone. > > I am writing an application that should show the same object on > multiple MDI windows (of a Qt Application), which are the classic > orthogonal views. > > My idea is to have a common routine to draw the object on the 4 > windows (every one has its own opengl view) and then > set the viewport and/or the point of view to look at the object to see > the correct orthogonal view > (for 3 of them, the fourth is not a problem for now). > > Is this a good idea or there are other, more suitable, methods ? > You can either create 4 contexts with shared data, or create a single context that you subdivide with viewports. IIRC it's easier to work with the first. Either way, it's a perfectly fine way to go about the work AFAIK. Take care, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
From: Mike C. F. <mcf...@vr...> - 2007-12-16 20:21:31
|
David McNab wrote: > Hi all, > > I've been developing a python app using the FLTK widgets (via pyFLTK). > > A critical part of the app is drawing video frames onto a GL window via > glDrawPixels. (FLTK offers very basic support for GL windows, via its > Fl_GL_Window class). > > At the moment, it's working nicely as long as I pass the pixels data in > RGB format. But video editing works mainly with YCbCr format data, and > converting the data into RGB format is very costly for CPU cycles - > takes around 20ms on my 2GHz box. > > I've been told on #opengl that there is a way to set up an GL window so > that if passed YCbCr data, it will display with correct colours. > > I'm a complete n00b with all things GL, I haven't got weeks to meditate > on the Red Book etc. > > Is there a simple straightforward way via PyOpenGL to set up a GL window > so that it can work with YCbCr data passed in via glDrawPixels? > Afraid this is well out of my experience range. From 40 minutes or so of reading around and looking into the code that people are using, it seems there's an approach that can be used with fragment shaders for certain types of data, but that it won't work for every YUV data type out there. There are some other extensions that are specifically targeted at the task, but they seem to be reasonably rare. GStreamer seems to have a "bad" plugin that renders to OpenGL, but it's a "bad" plugin. http://www.mdk.org.pl/2007/11/17/gl-colorspace-conversions Sorry I don't have more information to give, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
From: Mike C. F. <mcf...@vr...> - 2007-12-16 19:37:44
|
Arthur Marsh wrote: > Hi, I have a nearly ten year old PII-266 with Cirrus Logic graphics card > that runs the Python game "bouncy" under Debian unstable albeit very > slowly. > > I tried running this on an AMD Duron machine with GForce3 Ti200 graphics > card and the free "nv" X.org driver, and received the following error. > The error persisted when using the "vesa" X.org driver. > > Any ideas? > I've just successfully run bouncy on an AMD64 Gentoo box with the PyOpenGL version in CVS. There were a few missing aliases for functions (old "convenient" names that didn't get reproduced in PyOpenGL). I've added a bit more debugging to the load-library operation so that you can see what library name was passed and what it resulted in attempting to load. The error does *not* look like a "glut is not installed" error (I've just tested with GLUT removed on my machine and the glx module loads fine without it). It looks more like a problem with linkage between your GLUT library and the GL library, or something about how we load them, anyway (the line in question *should* be attempting to load GLUT (at least in CVS), but the error is that GL is not found). Good luck, Mike ... > from OpenGL.platform.glx import * > File "/usr/lib/python2.4/site-packages/OpenGL/platform/glx.py", line > 29, in ? > mode=ctypes.RTLD_GLOBAL > File > "/usr/lib/python2.4/site-packages/OpenGL/platform/ctypesloader.py", line > 37, in loadLibrary > return dllType( name, mode ) > File "/usr/lib/python2.4/site-packages/ctypes/__init__.py", line 340, > in __init__ > self._handle = _dlopen(self._name, mode) > OSError: GL: cannot open shared object file: No such file or directory > ... -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |