[ pyopengl-Bugs-1850600 ] glMultMatrix does not work correctly with transposed arrays

"SourceForge.net" <[email protected]>
Newsgroups gmane.comp.python.opengl.devel
Message-ID <[email protected]>
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

-------------------------------------------------------------------------
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.