Hi All,
I have written a patch which rectifies a cause of confusion among Blender
uses when starting out with matrices and vectors. The patch ensures
consistency between the matrix representation and matrix/vector products so
that they behave in the way that people familiar with math expect. This
On Wed, Dec 7, 2011 at 11:05 PM, Andrew Hale wrote:
> Hi All,
>
> I have written a patch which rectifies a cause of confusion among Blender
> uses when starting out with matrices and vectors. The patch ensures
> consistency between the matrix representation and matrix/vector products so
> that the
Hi Dan,
This patch does not change how the data is stored in Blender or how matrix
operations operate on the data. Currently the representation and
initialisation of matrices actually is wrong, as it is a mix column first
indexing (as used internally in Blender) and row first indexing (as used
whe
Hello Andrew,
Even though this change might be for the better, it has the potential
to break existing scripts. There already was a change in the
vector/matrix multiplication order some months ago, and the result was
that a lot of users complained about broken scripts.
I have to admit that I might
On Fri, Dec 9, 2011 at 7:10 PM, bartius crouch wrote:
> Hello Andrew,
>
> Even though this change might be for the better, it has the potential
> to break existing scripts. There already was a change in the
> vector/matrix multiplication order some months ago, and the result was
> that a lot of us
Hi Andrew,
Can you provide evidence for who is spreading, supporting or enforcing
this "Standard Notation"?
Apart from that - especially when this standard appears disputable -
we can much better ensure we are 100% clear about it in docs. Look at
this wonderful Panda3d page:
http://www.pan
Hi Ton,
I will try to explain better (this is a devilish topic). The problem here
is how matrices are accessed in Python and how the matrix product is
formed. The method of indexing matrices is shown in [1], [2] and [3]. This
method has the method of accessing matrices as
matrix[row_index][column_
Hi Andrew,
I don't think this is the right interpretation, I think column major
storage does explain the behavior, and it's not clear to me what is
wrong assuming that this is the case.
In python and blender C code, matrices are accessed as
matrix[column][row]. When printing the matrix in python,
Hi,
On Fri, Dec 9, 2011 at 11:01 AM, Ton Roosendaal wrote:
> Can you provide evidence for who is spreading, supporting or enforcing
> this "Standard Notation"?
>
> Apart from that - especially when this standard appears disputable -
> we can much better ensure we are 100% clear about it in docs.
Hi Brecht,
So it currently prints columns as rows? This is how users become confused.
This can be fixed as I propose or by changing the repr function. Changing
the repr function will at least make the printed form of the matrix
consistent with it's behaviour in multiplications, if we change the re
Also, note that MatLab stores arrays in column major format but still uses
matrix[row, column] for indexing entries.
On Fri, Dec 9, 2011 at 11:50 PM, Andrew Hale wrote:
> Hi Brecht,
>
> So it currently prints columns as rows? This is how users become confused.
> This can be fixed as I propose or
On Fri, 2011-12-09 at 23:57 +1100, Andrew Hale wrote:
> Also, note that MatLab stores arrays in column major format but still uses
> matrix[row, column] for indexing entries.
numpy also uses row, column indexing
http://docs.scipy.org/doc/numpy/reference/generated/numpy.matrix.html
>>> import num
Perhaps we could consider this as two separate proposals;
1. Change the repr function for matrices so that they print columns as
columns.
2. Change how Python gets/sets data from C so that matrices in Python
maintain the standard math notation of matrix[row][column]
The first should n
By the way, how slices would be handled in this case?
If I recall correctly, currently you can write e.g. matrix[0] to get a
4-vector of X-axis of transform matrix, or e.g. matrix[2][:3] to get
3D-vector of Z-axis.
___
Bf-committers mailing list
Bf-commit
slice works in the patch,
matrix = matrix[0:2]
... would be become the same as...
matrix = matrix.transposed()[0:2]
matrix[2][:3] can be replaced with
# for getting ...
location = matrix.to_translation()
# for setting (unless we add a method) ...
matrix[0][2], matrix[1][2], matrix[2][2] = locat
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']
# n
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
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
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 t
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 tru
20 matches
Mail list logo
