From: Brendan Kenny <bckenny@gmail.com>

Date: Fri, 13 Jun 2014 15:48:59 -0700

Message-ID: <CAOHrRFBOwu9ZF+iiRo1AmD1umksfGoq5PA+MefBoT8=X6ncXdw@mail.gmail.com>

To: Rik Cabanier <cabanier@gmail.com>

Cc: Dirk Schulze <dschulze@adobe.com>, "public-fx@w3.org" <public-fx@w3.org>

Date: Fri, 13 Jun 2014 15:48:59 -0700

Message-ID: <CAOHrRFBOwu9ZF+iiRo1AmD1umksfGoq5PA+MefBoT8=X6ncXdw@mail.gmail.com>

To: Rik Cabanier <cabanier@gmail.com>

Cc: Dirk Schulze <dschulze@adobe.com>, "public-fx@w3.org" <public-fx@w3.org>

This has come up before, but "column-major" and "row-major" are ambiguous on their own, as the column-major ordering of a matrix is the same as the row-major ordering of the transpose of that matrix, and different graphics API conceptually have their matrices laid out differently (e.g. DOMMatrix is one way[1] while CGAffineTransform in Quartz 2D is the other[2], but since CGAffineTransformMake takes the elements in row-major order, constructing the same 2d transform in each will end up having the same order of arguments). WebGL actually doesn't care which order you feed it matrices since all multiplications with a matrix take place in shaders, and GLSL supports matrix/vector multiplication on the left or right, so it's up to the author to get the convention right. However, in the fixed-function days OpenGL did care, and required the elements to come in the column-major ordering of the form of matrix specified in DOMMatrix. That lightgl.js library actually follows this and there's an explicit transpose before passing matrices into WebGL[3]. Fun Usenet posts on this ambiguity and the root of OpenGL's ordering here: [4]. Multiplying a matrix by a column-vector point on the right has mostly won the day in the computer graphics world, and has always been relatively standard in linear algebra courses, so accepting that and with the conceptual matrix layout given explicitly in [1], then the current spec's column-major enumeration is the ideal one for interoperating with WebGL. Brendan [1] http://dev.w3.org/fxtf/geometry/#DOMMatrix [2] https://developer.apple.com/library/mac/documentation/graphicsimaging/reference/CGAffineTransform/Reference/reference.html (see CGAffineTransformMake) [3] https://github.com/evanw/lightgl.js/blob/master/src/shader.js#L166 [4] http://steve.hollasch.net/cgindex/math/matrix/column-vec.html On Wed, Jun 11, 2014 at 11:13 PM, Rik Cabanier <cabanier@gmail.com> wrote: > > > > On Wed, Jun 11, 2014 at 10:26 PM, Dirk Schulze <dschulze@adobe.com> wrote: > >> >> On Jun 12, 2014, at 7:15 AM, Rik Cabanier <cabanier@gmail.com> wrote: >> >> > All, >> > >> > the current spec says that arrays are in [1] column-major order, but it >> seems that WebGL is in row-major order (ie [2]). >> > Can people confirm this? If so, maybe we should update the spec to >> match. >> >> The spec aims to match CSS Transforms which is column-major order[1]. CSS >> Transforms is also the reason why the indices on the matrix elements seem >> to be the wrong way around… at least compared to mathematical conventions. >> >> It is indeed the question what will be used more. Maybe we can add an >> enumeration enum DOMMatrixOrder { ‘column’, ‘row’ } as argument for >> constructor, getters and setters? What would be the default, still ‘column'? >> > > Well, if CSS already specified it in column order, we should just offer > that. > It's easy enough to swap the elements yourself. Maybe this should be a > note in the spec? > > >> [1] http://dev.w3.org/csswg/css-transforms/#funcdef-matrix3d >> >> > >> > 1: >> http://dev.w3.org/fxtf/geometry/#dom-dommatrixreadonly-tofloat32array >> > 2: https://github.com/evanw/lightgl.js/blob/master/src/matrix.js >> >> >Received on Friday, 13 June 2014 22:49:56 UTC

*
This archive was generated by hypermail 2.4.0
: Friday, 17 January 2020 19:49:49 UTC
*