glsdk-devel

[Glsdk-devel] [GLM] open questions with the matrix api

[H. H. <hen...@gm...>]

There are some open questions in the mathlib's matrix api and I would like
to hear your opinions.

Do the matrices need member-wise constructors? For example, do we need
something like this:

GLMmat2f mat;
glmMatSet2f (&mat, 1.0f, 2.0f, 3.0f, 4.0f);

I suppose the user never needs to do anything like this, instead they use th
higher level entry-point such as Identity and Rotate.

However, there might be a need for constructing matrices from vectors.

GLMvec3f a, b, c;
GLMmat3f mat;
glmMatSet3f (&mat, &a, &b, &c);

At the moment, I have these entry-points and the matrices are constructed
'column-wise'. For example, the previous code creates this kind of matrix:

| a.x a.y a.z |
| b.x b.y b.z |
| c.x c.y c.z |

Should the matrices be build row-wise instead? There is an advantage in
this, as matrix rows define the coordinate axes in a 3D coordinate space.
However, OpenGL defines the matrix memory layout as column-wise, so I guess
it is a kind of more logical to build them column-wise from the vectors.

-- 
Henri 'henux' Häkkinen

Re: [Glsdk-devel] [GLM] open questions with the matrix api

[Branan R. <br...@gm...>]

I believe OpenGL defines a matrix constructed from vectors like this:
| a.x b.x c.x |
| a.y b.y c.y |
| a.z b.z c.z |

We should do the same for consistency.

Branan

On Sun, Aug 24, 2008 at 9:27 AM, Henri Häkkinen <hen...@gm...> wrote:
> There are some open questions in the mathlib's matrix api and I would like
> to hear your opinions.
>
> Do the matrices need member-wise constructors? For example, do we need
> something like this:
>
> GLMmat2f mat;
> glmMatSet2f (&mat, 1.0f, 2.0f, 3.0f, 4.0f);
>
> I suppose the user never needs to do anything like this, instead they use th
> higher level entry-point such as Identity and Rotate.
>
> However, there might be a need for constructing matrices from vectors.
>
> GLMvec3f a, b, c;
> GLMmat3f mat;
> glmMatSet3f (&mat, &a, &b, &c);
>
> At the moment, I have these entry-points and the matrices are constructed
> 'column-wise'. For example, the previous code creates this kind of matrix:
>
> | a.x a.y a.z |
> | b.x b.y b.z |
> | c.x c.y c.z |
>
> Should the matrices be build row-wise instead? There is an advantage in
> this, as matrix rows define the coordinate axes in a 3D coordinate space.
> However, OpenGL defines the matrix memory layout as column-wise, so I guess
> it is a kind of more logical to build them column-wise from the vectors.
>
> --
> Henri 'henux' Häkkinen
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Glsdk-devel mailing list
> Gls...@li...
> https://lists.sourceforge.net/lists/listinfo/glsdk-devel
>
>

Re: [Glsdk-devel] [GLM] open questions with the matrix api

[H. H. <hen...@gm...>]

Actually, yes, you are absolutely correct. So

  glmMatSet3f (&mat, &a, &b, &c);

should construct

  | a.x b.x c.x |
  | a.y b.y c.y |
  | a.z b.z c.z |

Got it!


On Sun, Aug 24, 2008 at 8:47 PM, Branan Riley <br...@gm...> wrote:

> I believe OpenGL defines a matrix constructed from vectors like this:
> | a.x b.x c.x |
> | a.y b.y c.y |
> | a.z b.z c.z |
>
> We should do the same for consistency.
>
> Branan
>
> On Sun, Aug 24, 2008 at 9:27 AM, Henri Häkkinen <hen...@gm...>
> wrote:
> > There are some open questions in the mathlib's matrix api and I would
> like
> > to hear your opinions.
> >
> > Do the matrices need member-wise constructors? For example, do we need
> > something like this:
> >
> > GLMmat2f mat;
> > glmMatSet2f (&mat, 1.0f, 2.0f, 3.0f, 4.0f);
> >
> > I suppose the user never needs to do anything like this, instead they use
> th
> > higher level entry-point such as Identity and Rotate.
> >
> > However, there might be a need for constructing matrices from vectors.
> >
> > GLMvec3f a, b, c;
> > GLMmat3f mat;
> > glmMatSet3f (&mat, &a, &b, &c);
> >
> > At the moment, I have these entry-points and the matrices are constructed
> > 'column-wise'. For example, the previous code creates this kind of
> matrix:
> >
> > | a.x a.y a.z |
> > | b.x b.y b.z |
> > | c.x c.y c.z |
> >
> > Should the matrices be build row-wise instead? There is an advantage in
> > this, as matrix rows define the coordinate axes in a 3D coordinate space.
> > However, OpenGL defines the matrix memory layout as column-wise, so I
> guess
> > it is a kind of more logical to build them column-wise from the vectors.
> >
> > --
> > Henri 'henux' Häkkinen
> >
> >
> > -------------------------------------------------------------------------
> > This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> > Build the coolest Linux based applications with Moblin SDK & win great
> > prizes
> > Grand prize is a trip for two to an Open Source event anywhere in the
> world
> > http://moblin-contest.org/redirect.php?banner_id=100&url=/
> > _______________________________________________
> > Glsdk-devel mailing list
> > Gls...@li...
> > https://lists.sourceforge.net/lists/listinfo/glsdk-devel
> >
> >
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Glsdk-devel mailing list
> Gls...@li...
> https://lists.sourceforge.net/lists/listinfo/glsdk-devel
>



-- 
Henri 'henux' Häkkinen

Re: [Glsdk-devel] [GLM] open questions with the matrix api

[H. H. <hen...@gm...>]

Another open issues has came up:

Do you think we should allow something like this:

glmMatInverse2f (&mat, &mat);
glmMatTranspose2f (&mat, &mat);
glmVecAdd2f (&vec, &vec, &vec);

For some functions, this add some additional processing since it needs to
store temporary values of matrix members before performing an operation,
such as:

GLMmat2f *
glmMatInverse2f (GLMmat2f *out, const GLMmat2f *m)
{
  GLfloat m00, m01, m10, m11;
  GLfloat inv_det;

  assert (out);
  assert (m);

  inv_det = glmMatDeterm2f (m);

  m00 = m->m00;
  m01 = m->m01;
  m10 = m->m10;
  m11 = m->m11;

  out->m00 =   m11 * inv_det;
  out->m01 = - m01 * inv_det;
  out->m10 = - m10 * inv_det;
  out->m11 =   m00 * inv_det;

  return out;
}

We could allows this for simplicity or we could provide additional
entry-points such as:

glmMatInverseSelf2f (&mat);
glmVecAddSelf2f (&vec1, &vec2); // vec1 += vec2

// not allowed and undefined:
glmMatInverse2f (&mat, &mat);
...


My proposal is that we allow glmMatInverse2f (&mat, &mat) and live with the
additional overhead. -Self funcs may still be included for convenience (at
some later GLM versions).


On Sun, Aug 24, 2008 at 9:32 PM, Henri Häkkinen <hen...@gm...> wrote:

> Actually, yes, you are absolutely correct. So
>
>   glmMatSet3f (&mat, &a, &b, &c);
>
> should construct
>
>   | a.x b.x c.x |
>   | a.y b.y c.y |
>   | a.z b.z c.z |
>
> Got it!
>
>
>
> On Sun, Aug 24, 2008 at 8:47 PM, Branan Riley <br...@gm...> wrote:
>
>> I believe OpenGL defines a matrix constructed from vectors like this:
>> | a.x b.x c.x |
>> | a.y b.y c.y |
>> | a.z b.z c.z |
>>
>> We should do the same for consistency.
>>
>> Branan
>>
>> On Sun, Aug 24, 2008 at 9:27 AM, Henri Häkkinen <hen...@gm...>
>> wrote:
>> > There are some open questions in the mathlib's matrix api and I would
>> like
>> > to hear your opinions.
>> >
>> > Do the matrices need member-wise constructors? For example, do we need
>> > something like this:
>> >
>> > GLMmat2f mat;
>> > glmMatSet2f (&mat, 1.0f, 2.0f, 3.0f, 4.0f);
>> >
>> > I suppose the user never needs to do anything like this, instead they
>> use th
>> > higher level entry-point such as Identity and Rotate.
>> >
>> > However, there might be a need for constructing matrices from vectors.
>> >
>> > GLMvec3f a, b, c;
>> > GLMmat3f mat;
>> > glmMatSet3f (&mat, &a, &b, &c);
>> >
>> > At the moment, I have these entry-points and the matrices are
>> constructed
>> > 'column-wise'. For example, the previous code creates this kind of
>> matrix:
>> >
>> > | a.x a.y a.z |
>> > | b.x b.y b.z |
>> > | c.x c.y c.z |
>> >
>> > Should the matrices be build row-wise instead? There is an advantage in
>> > this, as matrix rows define the coordinate axes in a 3D coordinate
>> space.
>> > However, OpenGL defines the matrix memory layout as column-wise, so I
>> guess
>> > it is a kind of more logical to build them column-wise from the vectors.
>> >
>> > --
>> > Henri 'henux' Häkkinen
>> >
>> >
>> >
>> -------------------------------------------------------------------------
>> > This SF.Net email is sponsored by the Moblin Your Move Developer's
>> challenge
>> > Build the coolest Linux based applications with Moblin SDK & win great
>> > prizes
>> > Grand prize is a trip for two to an Open Source event anywhere in the
>> world
>> > http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> > _______________________________________________
>> > Glsdk-devel mailing list
>> > Gls...@li...
>> > https://lists.sourceforge.net/lists/listinfo/glsdk-devel
>> >
>> >
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win great
>> prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the
>> world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Glsdk-devel mailing list
>> Gls...@li...
>> https://lists.sourceforge.net/lists/listinfo/glsdk-devel
>>
>
>
>
> --
> Henri 'henux' Häkkinen
>
>


-- 
Henri 'henux' Häkkinen

Re: [Glsdk-devel] [GLM] open questions with the matrix api

[Jason M. <ko...@gm...>]

Henri Häkkinen wrote:
> Another open issues has came up:
>
> Do you think we should allow something like this:
>
> glmMatInverse2f (&mat, &mat);
> glmMatTranspose2f (&mat, &mat);
> glmVecAdd2f (&vec, &vec, &vec);
>
> For some functions, this add some additional processing since it needs 
> to store temporary values of matrix members before performing an 
> operation, such as:
>
> ...
>
> My proposal is that we allow glmMatInverse2f (&mat, &mat) and live 
> with the additional overhead. -Self funcs may still be included for 
> convenience (at some later GLM versions).
Agreed. It adheres to the principle of least surprise. The less-careful 
user will expect to be able to pass the same parameter, or outputs as 
inputs, and we should allow it.

Re: [Glsdk-devel] [GLM] open questions with the matrix api

[H. H. <hen...@gm...>]

Good.

I will be making the changes in the upcoming commits, and updating the test
cases for them.

I have also added some explaining comments for the matrix layouts in my last
commit:

typedef struct {
  union {
    /* Matrix layout:
       | data[0] data[2] |
       | data[1] data[3] |
    */
    GLfloat data[4];
    struct {
      /* Matrix layout:
         | m00 m01 |
         | m10 m11 |
      */
      GLfloat m00, m10, m01, m11;
    };
  };
} GLMmat2f;

All this will of course need to go to the GLM API documentation also, in
time.


On Sun, Aug 24, 2008 at 10:50 PM, Jason McKesson <ko...@gm...> wrote:

> Henri Häkkinen wrote:
> > Another open issues has came up:
> >
> > Do you think we should allow something like this:
> >
> > glmMatInverse2f (&mat, &mat);
> > glmMatTranspose2f (&mat, &mat);
> > glmVecAdd2f (&vec, &vec, &vec);
> >
> > For some functions, this add some additional processing since it needs
> > to store temporary values of matrix members before performing an
> > operation, such as:
> >
> > ...
> >
> > My proposal is that we allow glmMatInverse2f (&mat, &mat) and live
> > with the additional overhead. -Self funcs may still be included for
> > convenience (at some later GLM versions).
> Agreed. It adheres to the principle of least surprise. The less-careful
> user will expect to be able to pass the same parameter, or outputs as
> inputs, and we should allow it.
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Glsdk-devel mailing list
> Gls...@li...
> https://lists.sourceforge.net/lists/listinfo/glsdk-devel
>



-- 
Henri 'henux' Häkkinen