pyopengl-devel Mailing List for PyOpenGL (Page 19)
Brought to you by:
mcfletch
Menu
▾
▴
pyopengl-devel — Discussion of PyOpenGL development.
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
(4) |
Nov
(9) |
Dec
(2) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(1) |
Feb
(6) |
Mar
(3) |
Apr
(5) |
May
(10) |
Jun
(6) |
Jul
(10) |
Aug
|
Sep
(3) |
Oct
(9) |
Nov
(20) |
Dec
(31) |
| 2003 |
Jan
(36) |
Feb
(44) |
Mar
(16) |
Apr
(35) |
May
(59) |
Jun
(17) |
Jul
(11) |
Aug
(14) |
Sep
(9) |
Oct
(29) |
Nov
(10) |
Dec
(5) |
| 2004 |
Jan
(17) |
Feb
(8) |
Mar
(6) |
Apr
(3) |
May
(4) |
Jun
(2) |
Jul
(42) |
Aug
(7) |
Sep
(17) |
Oct
(32) |
Nov
(7) |
Dec
(5) |
| 2005 |
Jan
(11) |
Feb
(11) |
Mar
(7) |
Apr
(8) |
May
(3) |
Jun
(3) |
Jul
(3) |
Aug
(5) |
Sep
|
Oct
(2) |
Nov
(5) |
Dec
(1) |
| 2006 |
Jan
(1) |
Feb
(2) |
Mar
(5) |
Apr
(6) |
May
(9) |
Jun
(6) |
Jul
(7) |
Aug
(8) |
Sep
(8) |
Oct
(23) |
Nov
(29) |
Dec
(5) |
| 2007 |
Jan
(4) |
Feb
(3) |
Mar
(7) |
Apr
(10) |
May
(7) |
Jun
(12) |
Jul
(4) |
Aug
(2) |
Sep
(2) |
Oct
(5) |
Nov
(6) |
Dec
(3) |
| 2008 |
Jan
(38) |
Feb
(10) |
Mar
(3) |
Apr
(13) |
May
(8) |
Jun
(12) |
Jul
(6) |
Aug
(3) |
Sep
(2) |
Oct
(7) |
Nov
(21) |
Dec
(1) |
| 2009 |
Jan
(7) |
Feb
(8) |
Mar
(4) |
Apr
(6) |
May
(4) |
Jun
(4) |
Jul
(38) |
Aug
(4) |
Sep
|
Oct
(3) |
Nov
(16) |
Dec
|
| 2010 |
Jan
(4) |
Feb
(17) |
Mar
(2) |
Apr
(6) |
May
(1) |
Jun
(4) |
Jul
(1) |
Aug
(2) |
Sep
(1) |
Oct
(10) |
Nov
(3) |
Dec
(8) |
| 2011 |
Jan
|
Feb
(2) |
Mar
|
Apr
(6) |
May
(3) |
Jun
(19) |
Jul
(6) |
Aug
(2) |
Sep
(5) |
Oct
|
Nov
(6) |
Dec
(6) |
| 2012 |
Jan
(8) |
Feb
(3) |
Mar
(26) |
Apr
(12) |
May
(2) |
Jun
(8) |
Jul
(6) |
Aug
(4) |
Sep
(1) |
Oct
(10) |
Nov
(5) |
Dec
(1) |
| 2013 |
Jan
(2) |
Feb
(5) |
Mar
(1) |
Apr
(3) |
May
(6) |
Jun
|
Jul
(7) |
Aug
|
Sep
(4) |
Oct
(1) |
Nov
(4) |
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(6) |
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
(2) |
Nov
(1) |
Dec
(1) |
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
(1) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2019 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: SourceForge.net <no...@so...> - 2007-12-14 08:46:53
|
Bugs item #1850600, was opened at 2007-12-14 09:46 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1850600&group_id=5988 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: GL Group: v3.0.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Toon Verstraelen (tovrstra) Assigned to: Nobody/Anonymous (nobody) Summary: glMultMatrix does not work correctly with transposed arrays Initial Comment: Hello, In the example attached, it shown that the function glMultMatrixf does not work correctly with transposed arrays. Apparently, the strides of a numpy.array object are ignored. This problem is present in version 3.0.0a6. It was not present in the 2.x versions. In the program bug.py, the relevant part is marked by comments 'BEGIN INTERESTING PART' and 'END INTERESTING PART'. When transf.transpose() is given as argument, glGetFloatv(GL_MODELVIEW_MATRIX) clearly shows the problem. When transf.transpose().copy() is given as argument, the problem is 'fixed', but not in a very satisfying way. cheers, Toon ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1850600&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2007-11-22 21:03:36
|
Bugs item #1836665, was opened at 2007-11-22 23:03 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1836665&group_id=5988 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Demo Group: v3.0.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Janto Dreijer (janto_d) Assigned to: Nobody/Anonymous (nobody) Summary: demo/redbook/fog.py nonworking Initial Comment: It seems an old version (pre-2002?) of fog.py is still distributed. There is a working version attached to https://sourceforge.net/tracker/?func=detail&atid=105988&aid=617949&group_id=5988 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1836665&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2007-11-09 01:36:50
|
Bugs item #1828695, was opened at 2007-11-08 17:36 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1828695&group_id=5988 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: v3.0.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: [Win32] TypeError: 'staticmethod' object is not callable Initial Comment: WindowsXP SP2 Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on win32 OpenGL-ctypes latest CVS File "c:\python25\lib\site-packages\PyOpenGL-3.0.0b1-py2.5.egg\OpenGL\platform\win32.py", line 69, in safeGetError return glGetError() TypeError: 'staticmethod' object is not callable On any OpenGL call in Win32. Culprit seems to be found at OpenGL/platform/win32.py : line 72: glGetError = staticmethod( Win32Platform.OpenGL.glGetError ) Naive removal of the 'staticmethod' call remedies the error. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1828695&group_id=5988 |
|
From: JoN <jo...@we...> - 2007-11-07 10:36:08
|
I've narrowed it down to DEFINITELY the glClear call, nothing to do with GLUT as far as I can see. Jon Quoting JoN <jo...@we...>: > > Hello > I get an "out of memory" error, it appears on a glClear called by GLUT. > > The environment is: > > Python 2.5.1 > PyOpenGL-3.0.0a6 > PyOpenGL-Demo-3.0.0a6 > > Windows XP SP2 (Actually, come to think of it....I had no problems before > SP2!) > > > If I run lesson6.py from the NeHe demos (actually it happens on other progs > including ones I wrote myself that used to work), I get: > > C:\Python25\Lib\site-packages\PyOpenGL_Demo-3.0.0a6-py2.5.egg\PyOpenGL-Demo\NeHe > >lesson6.py > Hit ESC key to quit. > Traceback (most recent call last): > File "build\bdist.win32\egg\OpenGL\GLUT\special.py", line 107, in safeCall > return function( *args, **named ) > File > "C:\Python25\Lib\site-packages\PyOpenGL_Demo-3.0.0a6-py2.5.egg\PyOpenGL-D > emo\NeHe\lesson6.py", line 117, in DrawGLScene > glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT) # Clear The Screen > And T > he Depth Buffer > File "build\bdist.win32\egg\OpenGL\error.py", line 188, in glCheckError > baseOperation = baseOperation, > GLError: GLError( > err = 1285, > description = 'out of memory', > baseOperation = glClear, > cArguments = (16640,) > ) > GLUT callback forcing low-level exit on error: GLError( > err = 1285, > description = 'out of memory', > baseOperation = glClear, > cArguments = (16640,) > ) > > C:\Python25\Lib\site-packages\PyOpenGL_Demo-3.0.0a6-py2.5.egg\PyOpenGL-Demo\NeHe > > > > > Any clues? Mike? Anybody? > > > Best Regs > Jon > > > > > > -------------------------------------------------------------------- > Come and visit Web Prophets Website at http://www.webprophets.net.au > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > PyOpenGL Homepage > http://pyopengl.sourceforge.net > _______________________________________________ > PyOpenGL-Devel mailing list > PyO...@li... > https://lists.sourceforge.net/lists/listinfo/pyopengl-devel > -------------------------------------------------------------------- Come and visit Web Prophets Website at http://www.webprophets.net.au |
|
From: SourceForge.net <no...@so...> - 2007-11-06 22:35:04
|
Bugs item #1827190, was opened at 2007-11-06 23:35 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1827190&group_id=5988 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: v3.0.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Chris Waters (crwaters) Assigned to: Nobody/Anonymous (nobody) Summary: Default (Numpy) array return values not accepted Initial Comment: The values returned by the default array type, numpy, are not accepted by OpenGL; more importantly, they are not accepted by the respective set/bind functions. This output is from the attached test file, run with the latest CVS revision: glGenTextures(1) -> 1 (<type 'long'>) glGenTextures(2) -> [2 3] (list: <type 'numpy.ndarray'>, elements: <type 'numpy.uint32'>) Calling: glBindTexture(GL_TEXTURE_2D, 1) (created from glGenTextures(1)) No Exceptions Calling: glBindTexture(GL_TEXTURE_2D, 2) (created from glGenTextures(2), element 0) Exception Caught: argument 2: <type 'exceptions.TypeError'>: wrong type The returned type of the array is numpy.ndarray, with each element having the type numpy.uint32. This element type is also not immediately convertable to a function argument type such as GLuint. The return type of glGenTextures(1), however, is of the type long due to the special-case functionality. This is not the case for functions that do not handle special cases similar to this, such as OpenGL.GL.EXT.framebuffer_object.glGenFramebuffersEXT A quick global work-around is to change the array type to ctypes after importing OpenGL: from OpenGL.arrays import formathandler formathandler.FormatHandler.chooseOutput( 'ctypesarrays' ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1827190&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2007-11-06 21:45:07
|
Patches item #1827167, was opened at 2007-11-06 22:45 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305988&aid=1827167&group_id=5988 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: GL Group: v3.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Chris Waters (crwaters) Assigned to: Nobody/Anonymous (nobody) Summary: glGet Constant Sizes for EXT_framebuffer_object Initial Comment: Added glGet sizes to states defined in EXT_framebuffer_object. The following constants were given sizes: GL_MAX_RENDERBUFFER_SIZE_EXT GL_FRAMEBUFFER_BINDING_EXT GL_RENDERBUFFER_BINDING_EXT GL_MAX_COLOR_ATTACHMENTS_EXT Sizes were added to: src/glgetsizes.csv Updated OpenGL/raw/GL/EXT/framebuffer_object.py using: src/get_gl_extensions.py ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305988&aid=1827167&group_id=5988 |
|
From: JoN <jo...@we...> - 2007-11-06 06:06:24
|
Hello
I get an "out of memory" error, it appears on a glClear called by GLUT.
The environment is:
Python 2.5.1
PyOpenGL-3.0.0a6
PyOpenGL-Demo-3.0.0a6
Windows XP SP2 (Actually, come to think of it....I had no problems before SP2!)
If I run lesson6.py from the NeHe demos (actually it happens on other progs
including ones I wrote myself that used to work), I get:
C:\Python25\Lib\site-packages\PyOpenGL_Demo-3.0.0a6-py2.5.egg\PyOpenGL-Demo\NeHe
>lesson6.py
Hit ESC key to quit.
Traceback (most recent call last):
File "build\bdist.win32\egg\OpenGL\GLUT\special.py", line 107, in safeCall
return function( *args, **named )
File "C:\Python25\Lib\site-packages\PyOpenGL_Demo-3.0.0a6-py2.5.egg\PyOpenGL-D
emo\NeHe\lesson6.py", line 117, in DrawGLScene
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT) # Clear The Screen And T
he Depth Buffer
File "build\bdist.win32\egg\OpenGL\error.py", line 188, in glCheckError
baseOperation = baseOperation,
GLError: GLError(
err = 1285,
description = 'out of memory',
baseOperation = glClear,
cArguments = (16640,)
)
GLUT callback forcing low-level exit on error: GLError(
err = 1285,
description = 'out of memory',
baseOperation = glClear,
cArguments = (16640,)
)
C:\Python25\Lib\site-packages\PyOpenGL_Demo-3.0.0a6-py2.5.egg\PyOpenGL-Demo\NeHe
>
Any clues? Mike? Anybody?
Best Regs
Jon
--------------------------------------------------------------------
Come and visit Web Prophets Website at http://www.webprophets.net.au
|
|
From: SourceForge.net <no...@so...> - 2007-10-25 10:58:16
|
Bugs item #1737282, was opened at 2007-06-14 08:38 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1737282&group_id=5988 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: GLUT Group: v3.0.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Seg fault on Ubuntu Fiesty x86-64 - 3.0.0a6 Initial Comment: With Python 2.5,Python-2.5.tar.bz2 numpy, numpy-1.0.tar.gz PyOpenGL, PyOpenGL-3.0.0a6.tar.gz OpenGL-ctypes/OpenGL/tests$ python test_glutwindow.py newArguments ['test_glutwindow.py'] Segmentation fault (core dumped) This occurs on line 78 glutInitDisplayMode( GLUT_DOUBLE | GLUT_RGB ) ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2007-10-25 03:58 Message: Logged In: NO What's going on this bug is still present in Ubuntu Gutsy (64 bits version), are pyopengl abandoned? or is there a secret bugfix? Nothing has happened with this bug for 4 month. A segfault on 64-bits Linux has to be considered a quite severe bug. I'm very new to Python but I need it for a course in 3d rendering at school so if there is some debugging I can do please let me know, but I think it's quite easy to reproduce. /Björn ---------------------------------------------------------------------- Comment By: Gary Orser (orser) Date: 2007-06-14 10:53 Message: Logged In: YES user_id=82696 Originator: NO Forgot to add: The script I used to build this python, generates a python that doesn't seg fault on Fiesty 32bit. It also seg faults, on SuSE 10.1 64 bit. This must be some sort of 64 bit issue. ---------------------------------------------------------------------- Comment By: Gary Orser (orser) Date: 2007-06-14 08:48 Message: Logged In: YES user_id=82696 Originator: NO Forgot to add: The script I used to build this python, generates a python that doesn't seg fault on Fiesty 32bit. It also seg faults, on SuSE 10.1 64 bit. This must be some sort of 64 bit issue. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1737282&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2007-10-24 14:29:05
|
Bugs item #1819348, was opened at 2007-10-24 07:29 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1819348&group_id=5988 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: GL Group: v3.0.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: OpenGL.GL.GL_ALL_ATTRIB_BITS has bad value Initial Comment: On a Mac OS X 10.4.9 straightforward tarball build (PyOpenGL-3.0.0a6) the value of the constant OpenGL.GL.GL_ALL_ATTRIB_BITS is wrong (so glPushAttrib(GL_ALL_ATTRIB_BITS) won't work). The gl.h header says #define GL_ALL_ATTRIB_BITS 0x000fffff but the value is 4294967295. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1819348&group_id=5988 |
|
From: IvO <ivo...@gm...> - 2007-10-15 00:00:48
|
After some code inspection I figured out that using registerChecker is
not enough ... then,
I did:
from OpenGL.error import ErrorChecker
from OpenGL.GL import *
from OpenGL.GLU import *
from OpenGL.GLUT import *
. . .
...
...
if __name__ == '__main__':
ErrorChecker._currentChecker=ErrorChecker.nullGetError #
main()
The performance increase was huge.
Perhaps it's a bug.
Saludos,
IvO
|
|
From: Joshua R. <jos...@us...> - 2007-10-06 19:41:31
|
Note that with the patch applied you still can't pickle constants using version 2 of the pickle protocol, only versions 0 and 1. I think that an implementation of __getnewargs__ might be needed, though I'm in a bit over my head with this stuff to be honest. - Josh |
|
From: Joshua R. <jos...@us...> - 2007-10-05 17:30:10
|
Makes it possible to store pickled renderable objects that have e.g. GL_TRIANGLES as part of their state. |
|
From: SourceForge.net <no...@so...> - 2007-09-14 03:13:19
|
Bugs item #1794394, was opened at 2007-09-13 23:13 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1794394&group_id=5988 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Satyajit Sarangi (ssarangi) Assigned to: Nobody/Anonymous (nobody) Summary: crash with pyopengl Initial Comment: Hi, whenever I try to run applications from within an IDE like IDLE or PyScripter then the program runs correctly but when I exit it, it gives me an error of unreferenced memory location read and crashes. Please help. Thanks, Satyajit ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1794394&group_id=5988 |
|
From: JoN <jo...@we...> - 2007-09-10 03:15:01
|
Hope this hasn't been already covered. The "Next-gen" OpenGL, that is supposed to throw a lot of the previous arrangments out the window and NOT be backwards compatible - are people already thinking about that here in PyOpenGL developer land? Just curious. Jon -------------------------------------------------------------------- Come and visit Web Prophets Website at http://www.webprophets.net.au |
|
From: Etienne D. <ti...@sy...> - 2007-08-14 01:54:31
|
I'm a user of PyOpenGL working on Linux/OS X. Yesterday I decided to
test PyOpenGL 3-ctypes on OS X.
The test machine is an old Powerbook Titanium G4 667 running 10.3.9! I
took the CVS version of PyOpenGL and compile the latest version
(1.0.3-2) of Numpy.
tests.py ran without problem:
Ran 10 tests in 3.793s
OK
And I took the time to test the demo files. Here are the results:
OpenGL/Demo
GLE/cone.py YES
GLE/helix.py YES
GLE/texas.py YES
GLUT/gears.py YES
GLUT/molehill.py YES
GLUT/tom/arraytest.py YES
GLUT/tom/checker.py YES
GLUT/tom/cone.py YES
GLUT/tom/conechecker.py YES
GLUT/tom/conesave.py YES
GLUT/tom/lorentz.py NO (Bus error)
GLUT/tom/text.py YES
NeHe/lesson1.py YES
NeHe/lesson2.py YES
NeHe/lesson3.py YES
NeHe/lesson4.py YES
NeHe/lesson5.py YES
NeHe/lesson6.py YES
NeHe/lesson6-multi.py YES
NeHe/lesson13.py (win32 specific)
NeHe/lesson18.py YES (but "L" doesn't change lightning)
NeHe/lesson41.py YES
NeHe/lesson42.py YES (but slow, maybe that's normal!)
NeHe/lesson43/lesson43.py NO (ValueError: Unable to locate true type
font 'Test.ttf' but the font is there?)
NeHe/lesson44/lesson44.py DON'T KNOW (The flare is visible only when
the end of the cylinder face the screen?)
NeHe/lesson45.py YES (after adding Terrain.bmp to the directory, it
was not there)
I also test one of my project and I think I found a bug in
glGenTextures. If I'm not wrong, glGenTextures is suppose to return an
array of GLuint. But when you generates only one texture it return a
GLuint and when you generates more then one it returns an array of
numpy.uint32 ?
I can resume the two cases with this code:
CASE 1
...init
textures = glGenTextures(1)
glBindTexture(GL_TEXTURE_RECTANGLE_EXT, textures[0])
File "./test.py", line 164, in ?
glBindTexture(GL_TEXTURE_RECTANGLE_EXT, textures[0])
TypeError: unsubscriptable object
CASE 2
...init
textures = glGenTextures(2)
glBindTexture(GL_TEXTURE_RECTANGLE_EXT, textures[0])
File "./test.py", line 164, in ?
glBindTexture(GL_TEXTURE_RECTANGLE_EXT, textures[0])
ctypes.ArgumentError: argument 2: exceptions.TypeError: wrong type
BUT if you do this, it works...
...init
textures = glGenTextures(1)
glBindTexture(GL_TEXTURE_RECTANGLE_EXT, textures)
Have an idea ? The problem is probably in the def of glGenTextures in
exceptions.py but I don't understand "annotations". So I was not able
to patch it.
Also I did a new extension (a really easy one!)
OpenGL.GL.EXT.texture_rectangle.
If you're curious, here is the project I did with PyOpenGL:
http://www2.ville.montreal.qc.ca/museumsnature/ars_natura/ars_natura.htm
Etienne Desautels
|
|
From: SourceForge.net <no...@so...> - 2007-08-06 23:41:08
|
Bugs item #1704764, was opened at 2007-04-21 02:13 Message generated for change (Comment added) made by bobl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1704764&group_id=5988 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: glBindTexture raises OverflowError in 2.0.1.09 Initial Comment: I'm running the Debian python-opengl package that shows as version 2.0.1.09. Code: self._texture = glGenTextures(1) glBindTexture(GL_TEXTURE_2D, self._texture) raises glBindTexture(GL_TEXTURE_2D, self._texture) OverflowError: long int too large to convert to int I saw some mailing list post claiming the bug was fixed in the .07 version, looks like someone reintroduced it again. ---------------------------------------------------------------------- Comment By: Bob Lewis (bobl) Date: 2007-08-06 16:41 Message: Logged In: YES user_id=135353 Originator: NO This happened to me. The problem appeared to be that I was calling glGenTextures() before the program had called glCreateWindow(). Calling glGenTextures() after glCreateWindow() fixed it. A proper fix, however, would be to make glGenTextures() raise a more meaningful exception if it's called at the wrong time. Even better, fix glGenTextures() so that it can be called any time. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2007-07-25 02:55 Message: Logged In: NO confirmed on =dev-python/pyopengl-2.0.1.09-r1 on gentoo ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1704764&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2007-07-25 09:55:27
|
Bugs item #1704764, was opened at 2007-04-21 02:13 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1704764&group_id=5988 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: glBindTexture raises OverflowError in 2.0.1.09 Initial Comment: I'm running the Debian python-opengl package that shows as version 2.0.1.09. Code: self._texture = glGenTextures(1) glBindTexture(GL_TEXTURE_2D, self._texture) raises glBindTexture(GL_TEXTURE_2D, self._texture) OverflowError: long int too large to convert to int I saw some mailing list post claiming the bug was fixed in the .07 version, looks like someone reintroduced it again. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2007-07-25 02:55 Message: Logged In: NO confirmed on =dev-python/pyopengl-2.0.1.09-r1 on gentoo ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1704764&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2007-07-12 09:55:32
|
Bugs item #1315434, was opened at 2005-10-06 16:46 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1315434&group_id=5988 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tk Group: v2.0.1 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Segfault with OpenGL.Tk under Linux Initial Comment: Here's the problem: dusty:~ $ python Python 2.4.1 (#1, Apr 5 2005, 11:00:51) [GCC 3.4.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import OpenGL.Tk Segmentation fault Pyopengl is version 2.0.2.01 Distro is Arch Linux dusty:~ $ uname -a Linux buchuki 2.6.13-ARCH #1 SMP Fri Sep 30 13:08:16 CEST 2005 i686 AMD Athlon(tm) 64 Processor 3200+ AuthenticAMD GNU/Linux The OpenGL.Tk demos that come with OpenGL don't work, but they work fine under Windows. Dusty ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2007-07-12 02:55 Message: Logged In: NO Ubuntu Bug: https://bugs.launchpad.net/ubuntu/+source/pyopengl/+bug/80656 ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2007-07-12 02:53 Message: Logged In: NO Same problem, Ubuntu Feisty. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-02-24 06:02 Message: Logged In: NO I had the same problem with SuSE 10.0 Deinstallation of the SuSe version and re-compilation of the latest PyOpenGL version gave the same result. After several unsuccessfull trials I found a solution by (only) recompiling Togl-1.6 (with the tcl/tk headers from Suse's tcl/tk-version) and replacing Togl.so in /usr/lib/python/site-packages/OpenGL/Tk/linux2-tk8.4/Togl.so ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1315434&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2007-07-12 09:53:25
|
Bugs item #1315434, was opened at 2005-10-06 16:46 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1315434&group_id=5988 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tk Group: v2.0.1 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Segfault with OpenGL.Tk under Linux Initial Comment: Here's the problem: dusty:~ $ python Python 2.4.1 (#1, Apr 5 2005, 11:00:51) [GCC 3.4.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import OpenGL.Tk Segmentation fault Pyopengl is version 2.0.2.01 Distro is Arch Linux dusty:~ $ uname -a Linux buchuki 2.6.13-ARCH #1 SMP Fri Sep 30 13:08:16 CEST 2005 i686 AMD Athlon(tm) 64 Processor 3200+ AuthenticAMD GNU/Linux The OpenGL.Tk demos that come with OpenGL don't work, but they work fine under Windows. Dusty ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2007-07-12 02:53 Message: Logged In: NO Same problem, Ubuntu Feisty. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-02-24 06:02 Message: Logged In: NO I had the same problem with SuSE 10.0 Deinstallation of the SuSe version and re-compilation of the latest PyOpenGL version gave the same result. After several unsuccessfull trials I found a solution by (only) recompiling Togl-1.6 (with the tcl/tk headers from Suse's tcl/tk-version) and replacing Togl.so in /usr/lib/python/site-packages/OpenGL/Tk/linux2-tk8.4/Togl.so ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1315434&group_id=5988 |
|
From: Mike C. F. <mcf...@vr...> - 2007-07-09 02:18:34
|
I've been eliminating the hard-coded platform implementation restriction (i.e. allowing people to write plug-ins for supporting other platforms). In doing so I've had to rewrite the platform implementations. I don't have a real Win32 or OS-X environment on which to test, however. Anyway, if someone could check out the code from CVS on those platforms, run setup.py develop, and then test to see if we have working extensions, GLUT, GLE and the like, that would be helpful. There's also an experimental script in the src directory for downloading/installing the GLUT and GLE dlls automatically on Win32 in case someone wants to try that. I've also made it possible to completely disable error checking by setting a flag before you import the various modules (OpenGL.ERROR_CHECKING). Have fun all, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
|
From: SourceForge.net <no...@so...> - 2007-06-27 19:05:01
|
Bugs item #1744414, was opened at 2007-06-27 12:04 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1744414&group_id=5988 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: GL Group: v3.0.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: ctypes.ArgumentError in glReadPixels Initial Comment: We're running problems with glReadPixels throwing an exception. Here's the backtrace: Traceback (most recent call last): File "/store/home/mukaissi/MetNetVis/MetNetVis/UI/graphdrawwidget.py", line 155, in mousePressEvent index=GL.glReadPixels(event.x,event.y,1,1,GL.GL_RGB,GL.GL_UNSIGNED_BYTE) File "/store/home/mukaissi/software/PyOpenGL-3.0.0a6/OpenGL/GL/images.py", line 279, in glReadPixels ctypes.c_void_p( arrayType.dataPointer(array)) ctypes.ArgumentError: argument 1: <type 'exceptions.TypeError'>: wrong type Adding a few prints to see the types of the involved variables they seem to be ok: array: [[[0 0 0]]] <type 'numpy.ndarray'> arrayType: <class 'OpenGL.arrays.arraydatatype.GLubyteArray'> <type '_ctypes.PointerType'> dataPointer: 20509152 <type 'long'> This is using 3.0.0a6 on an x86_64 (RHEL) system. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1744414&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2007-06-25 21:54:08
|
Bugs item #1743168, was opened at 2007-06-25 14:54 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1743168&group_id=5988 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: GL Group: v3.0.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: ctypes.ArgumentError in glReadPixels Initial Comment: We're running problems with glReadPixels throwing an exception. Here's the backtrace: Traceback (most recent call last): File "/store/home/mukaissi/MetNetVis/MetNetVis/UI/graphdrawwidget.py", line 155, in mousePressEvent index=GL.glReadPixels(event.x,event.y,1,1,GL.GL_RGB,GL.GL_UNSIGNED_BYTE) File "/store/home/mukaissi/software/PyOpenGL-3.0.0a6/OpenGL/GL/images.py", line 279, in glReadPixels ctypes.c_void_p( arrayType.dataPointer(array)) ctypes.ArgumentError: argument 1: <type 'exceptions.TypeError'>: wrong type Adding a few prints to see the types of the involved variables they seem to be ok: array: [[[0 0 0]]] <type 'numpy.ndarray'> arrayType: <class 'OpenGL.arrays.arraydatatype.GLubyteArray'> <type '_ctypes.PointerType'> dataPointer: 20509152 <type 'long'> This is using 3.0.0a6 on an x86_64 (RHEL) system. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1743168&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2007-06-25 15:21:15
|
Bugs item #1742909, was opened at 2007-06-25 08:21 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1742909&group_id=5988 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: GL Group: v3.0.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: ctypes.ArgumentError in glReadPixels Initial Comment: We're running problems with glReadPixels throwing an exception. Here's the backtrace: Traceback (most recent call last): File "/store/home/mukaissi/MetNetVis/MetNetVis/UI/graphdrawwidget.py", line 155, in mousePressEvent index=GL.glReadPixels(event.x,event.y,1,1,GL.GL_RGB,GL.GL_UNSIGNED_BYTE) File "/store/home/mukaissi/software/PyOpenGL-3.0.0a6/OpenGL/GL/images.py", line 279, in glReadPixels ctypes.c_void_p( arrayType.dataPointer(array)) ctypes.ArgumentError: argument 1: <type 'exceptions.TypeError'>: wrong type Adding a few prints to see the types of the involved variables they seem to be ok: array: [[[0 0 0]]] <type 'numpy.ndarray'> arrayType: <class 'OpenGL.arrays.arraydatatype.GLubyteArray'> <type '_ctypes.PointerType'> dataPointer: 20509152 <type 'long'> This is using 3.0.0a6 on an x86_64 (RHEL) system. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1742909&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2007-06-25 00:39:52
|
Bugs item #1742607, was opened at 2007-06-24 17:39 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1742607&group_id=5988 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: GL Group: v3.0.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: ctypes.ArgumentError in glReadPixels Initial Comment: We're running problems with glReadPixels throwing an exception. Here's the backtrace: Traceback (most recent call last): File "/store/home/mukaissi/MetNetVis/MetNetVis/UI/graphdrawwidget.py", line 155, in mousePressEvent index=GL.glReadPixels(event.x,event.y,1,1,GL.GL_RGB,GL.GL_UNSIGNED_BYTE) File "/store/home/mukaissi/software/PyOpenGL-3.0.0a6/OpenGL/GL/images.py", line 279, in glReadPixels ctypes.c_void_p( arrayType.dataPointer(array)) ctypes.ArgumentError: argument 1: <type 'exceptions.TypeError'>: wrong type Adding a few prints to see the types of the involved variables they seem to be ok: array: [[[0 0 0]]] <type 'numpy.ndarray'> arrayType: <class 'OpenGL.arrays.arraydatatype.GLubyteArray'> <type '_ctypes.PointerType'> dataPointer: 20509152 <type 'long'> This is using 3.0.0a6 on an x86_64 (RHEL) system. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1742607&group_id=5988 |
|
From: <ir...@gm...> - 2007-06-20 23:23:35
|
Hi: Profiling a pyopengl application I have been developing I obtained this results: ncalls tottime percall cumtime percall filename:lineno(function) 213189 11.436 0.000 26.370 0.000 globjects.py:27(render) 2145235 6.653 0.000 12.704 0.000 error.py:162(glCheckError) 2144179 6.050 0.000 6.050 0.000 win32.py:72(safeGetError) Where render is the function that does the main work of the app. As you can see, error checking takes almost one half of the real work time. I think it could be a good idea to be able to disable error checking once you know your code works ok. After Reading http://pyopengl.sourceforge.net/ctypes/using.html, I tried this: from OpenGL import error def foobar(): pass error.ErrorChecker.registerChecker(foobar) But there is no gain in performance. Regards, Jorge |
32 messages has been excluded from this view by a project administrator.
