Thread: [PyOpenGL-Devel] [ pyopengl-Bugs-1850600 ] glMultMatrix does not work correctly with transposed arr
Brought to you by:
mcfletch
Menu
▾
▴
pyopengl-devel
|
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...> - 2008-01-07 15:35:53
|
Bugs item #1850600, was opened at 2007-12-14 03:46 Message generated for change (Comment added) made by mcfletch 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 ---------------------------------------------------------------------- >Comment By: Mike C. Fletcher (mcfletch) Date: 2008-01-07 10:35 Message: Logged In: YES user_id=34901 Originator: NO I'll take a look at the test case. PyOpenGL 2.x was doing a copy *all* the time, so it was always using the unsatisfying solution. PyOpenGL 3.x *tries* not to do a copy, but it *should* do a copy (in the same manor) under the covers... it doesn't try to figure out your array strides or the like. In this case it's apparently failing to do the copy when it should. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1850600&group_id=5988 |
|
From: SourceForge.net <no...@so...> - 2008-01-07 16:52:00
|
Bugs item #1850600, was opened at 2007-12-14 03:46 Message generated for change (Comment added) made by mcfletch 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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Toon Verstraelen (tovrstra) >Assigned to: Mike C. Fletcher (mcfletch) 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 ---------------------------------------------------------------------- >Comment By: Mike C. Fletcher (mcfletch) Date: 2008-01-07 11:52 Message: Logged In: YES user_id=34901 Originator: NO Code that was supposed to force to contiguous as a side-effect does not, in fact, force to contiguous form. CVS now uses an explicit function to force to contiguous. Test case added. ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2008-01-07 10:35 Message: Logged In: YES user_id=34901 Originator: NO I'll take a look at the test case. PyOpenGL 2.x was doing a copy *all* the time, so it was always using the unsatisfying solution. PyOpenGL 3.x *tries* not to do a copy, but it *should* do a copy (in the same manor) under the covers... it doesn't try to figure out your array strides or the like. In this case it's apparently failing to do the copy when it should. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105988&aid=1850600&group_id=5988 |
Thanks for helping keep SourceForge clean.
X