To follow up on this topic, Andrews patch has been committed, and I've
added a 'col' attribute for scripts that still need column access
still,
2.61: mat[2] = 1, 2, 3
2.62: mat.col[2] = 1, 2, 3
See:
http://wiki.blender.org/index.php/User:TrumanBlending/Matrix_Indexing#Cheat_Sheet
Scripts in trunk are all be up to date, some addons still need updating,
On Mon, Dec 19, 2011 at 11:28 AM, Morten Mikkelsen wrote:
> I am sorry I am a little late to the party but just thought I'd air my
> opinion.
>
> So since the order was fixed in blender's C code we now have what in math
> sense is a clear
> column major order ie. read from right to left. Thus translation for
> instance is the 4. column of a matrix
> and the vectors we transform are column vectors. In C terminology the
> translation is of course not the fourth
> column but the fourth row. The C terminology of course relates to the
> memory layout of a doubly indexed array (in C).
>
> Given that python is a high level language and memory layout is not exposed
> for a double indexed array (not a python programmer :)? it would imo make
> the most sense to use the mathematical interpretation of what a column is
> and then when a user asks for say the fourth column he'd get entries (in
> memory) 12, 13, 14 and 15 which is our translation/offset.
>
> I think adhering to the mathematical interpretation is more useful from
> python level than C memory layout of a doubly indexed array.
>
> This is my opinion.
>
> Cheers,
>
> Morten.
>
>
>
>
> On Sun, Dec 18, 2011 at 4:07 PM, Campbell Barton wrote:
>
>> Discussed this with Andrew and Benoit further, From their feedback I
>> gather row-major is the convention with math libs, so I propose to go
>> ahead with this within the next 2 weeks.
>>
>>
>> Rationale & general comments (re-iterating whats been said somewhat)...
>>
>> - Either way can be rationalized - depending on how strongly you want
>> to draw between python `mathutils` and OpenGL (or CG convention in
>> general), its a valid point but python devs are not coding OpenGL
>> typically.
>>
>> - Docs that discuss this issue for C/C++ apis I think don't really
>> apply IMHO, (panda3d doc for example). since the internal layout and
>> what is passed to OpenGL/DirectX need to be consistent in those cases.
>>
>> - Row major fits in with numpy - a popular python math module which
>> has some overlap with mathutils and some script devs are already using
>> with blender.
>>
>> - Will add a better __str__ function for matrix types which isn't so
>> confusing (this was needed anyway).
>>
>>
>>
>> Regarding the change,
>>
>> - Will update existing scripts in SVN
>>
>> - Will add docs describing the difference between mathutils & opengl
>> ordering.
>>
>> --
>> - Campbell
>>
>>
>> On Thu, Dec 15, 2011 at 10:15 PM, Andrew Hale
>> wrote:
>> > Hi all,
>> >
>> > With the controlled chaos of the release (and what a release!) dying
>> down,
>> > I felt I should write again to more succinctly express the issue as I see
>> > it:
>> >
>> > The issue here is not how we index arrays internally (i.e. in C) as this
>> > has concerns around the layout in memory etc. The issue is that once we
>> > expose this data to the user via Python, we currently break the extremely
>> > well established mathematical convention of indexing the row first. This
>> is
>> > where my concern lies. Since we translate from C to a Python matrix
>> > already, it is a relatively simple change to maintain the mathematical
>> > convention of row first indexing.
>> >
>> > I do not know of another major mathematical package which indexes by
>> column
>> > first; Mathematica, GNU Octave, MatLab, Fortran and Numpy all use row
>> first
>> > indexing. It is also the case that Fortran, GNU Octave and MatLab use
>> > column major storage for their matrices but maintain the mathematical
>> > convention of row first indexing.
>> >
>> > Thanks again,
>> > Andrew
>> >
>> > On Sat, Dec 10, 2011 at 9:05 AM, Campbell Barton > >wrote:
>> >
>> >> Changes to the __repr__ function should evaluate, since this is common
>> >> practice,
>> >> see: http://docs.python.org/py3k/library/functions.html#repr
>> >>
>> >> currently mathutils and bpy do this where possible, eg.
>> >>
>> >> >>> Euler()
>> >> Euler((0.0, 0.0, 0.0), 'XYZ')
>> >>
>> >> >>> bpy.context.object
>> >> bpy.data.objects['Armature']
>> >>
>> >> # note how str does _not_ always do this, though for mathutils we only
>> >> have repr at the moment.
>> >> >>> print(bpy.context.object)
>> >> ''
>> >>
>> >>
>> >> If we want a better way to represent mathutils data, I'd prefer to use
>> >> __str__, or add a method that returns a pretty formatted matrix.
>> >>
>> >> Another reason this would be nice is repr on floats gives hard to read
>> >> results sometimes, a custom printing function can give aligned columns
>> >> without too many decimal places, same goes for vectors and other
>> >> types.
>> >> eg:
>> >>
>> >> Matrix(((1.0, 3.142857074737549, 0.0, 0.0),
>> >> (0.0,
