glsdk-devel

[Glsdk-devel] [GLm] api

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

The GLM API seems at this moment to use two sets of naming styles. Compare
these two for example:

glmVecSub2f
glmVecLength2f

The first function is using a short form for the operation ('sub' as from
'substract') while the other is using long form. Should we simplify the API
to look like this:

glmVecSub2f
glmVecLen2f

Althought on the other hand, how do we shorten such stuff as Normalize,
Transform, Identity, Inverse? This does not necessary look good:

glmVecNorm
glmVecTrans
glmMatTrans
glmMatInv
glmMatIdent

Is this even a big issue? Comments?

If we decide to keep the API as it is now, I think we should lock it in and
begin to outline the API reference for it. For later versions, I would like
to implement such stuff as colors, quaternions and maybe planes and matrix
stacks but this can wait. Bigger priority is to get the current version
working and tested for.

For Korval: I outlined some API ref in a plain text format. You may find it
in 'docs/sdk_reference/glm-apiref' in the latest revision. You may use this
as ideas for the DocBook API ref and this file needs to get removed once you
migrate it into DocBook.

-- 
Henri 'henux' Häkkinen

Re: [Glsdk-devel] [GLm] api

[Mars_999 <ma...@si...>]

I haven't looked at the lib yet, but aren't we just going to work with floats all the time? 

glmVec2Sub
glmVec3Sub
glmVec4Sub

glmVec2Add
glmVec3Add
glmVec4Add

glmVec2Mul
glmVec2Div

glmVec2Norm
glmVec2Transf
glmVec3Cross
glmVec3Dot

I like that format...
  ----- Original Message ----- 
  From: Henri Häkkinen 
  To: glsdk-devel 
  Sent: Monday, August 25, 2008 2:04 PM
  Subject: [Glsdk-devel] [GLm] api


  The GLM API seems at this moment to use two sets of naming styles. Compare these two for example:

  glmVecSub2f
  glmVecLength2f

  The first function is using a short form for the operation ('sub' as from 'substract') while the other is using long form. Should we simplify the API to look like this:

  glmVecSub2f
  glmVecLen2f

  Althought on the other hand, how do we shorten such stuff as Normalize, Transform, Identity, Inverse? This does not necessary look good:

  glmVecNorm
  glmVecTrans
  glmMatTrans
  glmMatInv
  glmMatIdent

  Is this even a big issue? Comments?

  If we decide to keep the API as it is now, I think we should lock it in and begin to outline the API reference for it. For later versions, I would like to implement such stuff as colors, quaternions and maybe planes and matrix stacks but this can wait. Bigger priority is to get the current version working and tested for.

  For Korval: I outlined some API ref in a plain text format. You may find it in 'docs/sdk_reference/glm-apiref' in the latest revision. You may use this as ideas for the DocBook API ref and this file needs to get removed once you migrate it into DocBook.

  -- 
  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] api

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

We are currently using floats, but may want to reserve the possibility of
havings doubles too. Therefore we use the -f postfix. This is also the GL
convention of doing things:

glVertex2f

and therefore we have:

glmVecSet2f

instead of:

glmVec2Set

Also, we don't have glmVecDiv or glmVecMul. Why? Because vector division or
multiplication are not defined in linear-algebra. There are two kinds of
vector products: cross and dot. These are handled by the -Cross and -Dot
entry points. Member-wise div or mul are not mathemtically defined
operations in vector calculus AFAIK.

We have now several open issues with the GLM API:

1) Should we provide -Mul and -Div for vectors?
My opinion: no, as they are not defined in mathematics and they generally
are not needed

2) Should we use short naming convention or is the current convention fine?

The current convention is, for example:

glmVecSet2f
glmVecAdd2f
glmVecLength2f
glmVecTransform2f
glmMatSet2f
glmMatIdentity2f

The proposed short convention would be, for example:

glmVecLen2f
glmVecTrans2f
glmMatIdent2f
glmMatDet2f

3) Should we drop the -f postfix, or should we keep it for future possible
double types?,

glmVecSet2f (the current API) vs. glmVecSet2 (the proposed)

My opinion: we should keep the -f, it is more OpenGL-like and we reserve the
possibility of -d

4) Should we have the dimension of the type in the end of the entry-point
(like in OpenGL) or in the middle?

glmVecSet2f (the current API) vs. glmVec2Setf (the proposed)

My opinion: glmVecSet2f, it is more OpenGL-like


Issues are open for discussion. Please comment.



On Mon, Aug 25, 2008 at 10:10 PM, Mars_999 <ma...@si...> wrote:

>  I haven't looked at the lib yet, but aren't we just going to work with
> floats all the time?
>
> glmVec2Sub
> glmVec3Sub
> glmVec4Sub
>
> glmVec2Add
> glmVec3Add
> glmVec4Add
>
> glmVec2Mul
> glmVec2Div
>
> glmVec2Norm
> glmVec2Transf
> glmVec3Cross
> glmVec3Dot
>
> I like that format...
>
> ----- Original Message -----
> *From:* Henri Häkkinen <hen...@gm...>
> *To:* glsdk-devel <gls...@li...>
> *Sent:* Monday, August 25, 2008 2:04 PM
> *Subject:* [Glsdk-devel] [GLm] api
>
> The GLM API seems at this moment to use two sets of naming styles. Compare
> these two for example:
>
> glmVecSub2f
> glmVecLength2f
>
> The first function is using a short form for the operation ('sub' as from
> 'substract') while the other is using long form. Should we simplify the API
> to look like this:
>
> glmVecSub2f
> glmVecLen2f
>
> Althought on the other hand, how do we shorten such stuff as Normalize,
> Transform, Identity, Inverse? This does not necessary look good:
>
> glmVecNorm
> glmVecTrans
> glmMatTrans
> glmMatInv
> glmMatIdent
>
> Is this even a big issue? Comments?
>
> If we decide to keep the API as it is now, I think we should lock it in and
> begin to outline the API reference for it. For later versions, I would like
> to implement such stuff as colors, quaternions and maybe planes and matrix
> stacks but this can wait. Bigger priority is to get the current version
> working and tested for.
>
> For Korval: I outlined some API ref in a plain text format. You may find it
> in 'docs/sdk_reference/glm-apiref' in the latest revision. You may use this
> as ideas for the DocBook API ref and this file needs to get removed once you
> migrate it into DocBook.
>
> --
> 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] api

[Mars_999 <ma...@si...>]

glmVecSet2f
glmVecAdd2f
glmVecLength2f
glmVecTransform2f
glmMatSet2f
glmMatIdentity2f


I vote for this.

Correct, in mathematics vectors aren't defined, but I was thinking ahead for colors or other uses, having these would be nice, but anyone who is coding graphics should understand this already?

Also don't forget to put in a glmVecScale2f? I guess we could put double in but, IIRC double was going to get dropped? And we aren't doing OpenCL or CUDA here AFAIK, so double would kind of wasteful in terms of time spent.
  ----- Original Message ----- 
  From: Henri Häkkinen 
  To: gls...@li... 
  Sent: Monday, August 25, 2008 3:17 PM
  Subject: Re: [Glsdk-devel] [GLm] api


  We are currently using floats, but may want to reserve the possibility of havings doubles too. Therefore we use the -f postfix. This is also the GL convention of doing things:

  glVertex2f

  and therefore we have:

  glmVecSet2f

  instead of:

  glmVec2Set

  Also, we don't have glmVecDiv or glmVecMul. Why? Because vector division or multiplication are not defined in linear-algebra. There are two kinds of vector products: cross and dot. These are handled by the -Cross and -Dot entry points. Member-wise div or mul are not mathemtically defined operations in vector calculus AFAIK.

  We have now several open issues with the GLM API:

  1) Should we provide -Mul and -Div for vectors?
  My opinion: no, as they are not defined in mathematics and they generally are not needed

  2) Should we use short naming convention or is the current convention fine?

  The current convention is, for example:

  glmVecSet2f
  glmVecAdd2f
  glmVecLength2f
  glmVecTransform2f
  glmMatSet2f
  glmMatIdentity2f

  The proposed short convention would be, for example:

  glmVecLen2f
  glmVecTrans2f
  glmMatIdent2f
  glmMatDet2f

  3) Should we drop the -f postfix, or should we keep it for future possible double types?,

  glmVecSet2f (the current API) vs. glmVecSet2 (the proposed)

  My opinion: we should keep the -f, it is more OpenGL-like and we reserve the possibility of -d

  4) Should we have the dimension of the type in the end of the entry-point (like in OpenGL) or in the middle?

  glmVecSet2f (the current API) vs. glmVec2Setf (the proposed)

  My opinion: glmVecSet2f, it is more OpenGL-like


  Issues are open for discussion. Please comment.




  On Mon, Aug 25, 2008 at 10:10 PM, Mars_999 <ma...@si...> wrote:

    I haven't looked at the lib yet, but aren't we just going to work with floats all the time? 

    glmVec2Sub
    glmVec3Sub
    glmVec4Sub

    glmVec2Add
    glmVec3Add
    glmVec4Add

    glmVec2Mul
    glmVec2Div

    glmVec2Norm
    glmVec2Transf
    glmVec3Cross
    glmVec3Dot

    I like that format...
      ----- Original Message ----- 
      From: Henri Häkkinen 
      To: glsdk-devel 
      Sent: Monday, August 25, 2008 2:04 PM
      Subject: [Glsdk-devel] [GLm] api


      The GLM API seems at this moment to use two sets of naming styles. Compare these two for example:

      glmVecSub2f
      glmVecLength2f

      The first function is using a short form for the operation ('sub' as from 'substract') while the other is using long form. Should we simplify the API to look like this:

      glmVecSub2f
      glmVecLen2f

      Althought on the other hand, how do we shorten such stuff as Normalize, Transform, Identity, Inverse? This does not necessary look good:

      glmVecNorm
      glmVecTrans
      glmMatTrans
      glmMatInv
      glmMatIdent

      Is this even a big issue? Comments?

      If we decide to keep the API as it is now, I think we should lock it in and begin to outline the API reference for it. For later versions, I would like to implement such stuff as colors, quaternions and maybe planes and matrix stacks but this can wait. Bigger priority is to get the current version working and tested for.

      For Korval: I outlined some API ref in a plain text format. You may find it in 'docs/sdk_reference/glm-apiref' in the latest revision. You may use this as ideas for the DocBook API ref and this file needs to get removed once you migrate it into DocBook.

      -- 
      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




------------------------------------------------------------------------------


  -------------------------------------------------------------------------
  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] api

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

Double won't be added until the hardware supports it, so there won't
be any time wasted.

I'm also OK with the longer names.

On Mon, Aug 25, 2008 at 1:44 PM, Mars_999 <ma...@si...> wrote:
> glmVecSet2f
> glmVecAdd2f
> glmVecLength2f
> glmVecTransform2f
> glmMatSet2f
> glmMatIdentity2f
>
> I vote for this.
>
> Correct, in mathematics vectors aren't defined, but I was thinking ahead for
> colors or other uses, having these would be nice, but anyone who is coding
> graphics should understand this already?
>
> Also don't forget to put in a glmVecScale2f? I guess we could put double in
> but, IIRC double was going to get dropped? And we aren't doing OpenCL or
> CUDA here AFAIK, so double would kind of wasteful in terms of time spent.
>
> ----- Original Message -----
> From: Henri Häkkinen
> To: gls...@li...
> Sent: Monday, August 25, 2008 3:17 PM
> Subject: Re: [Glsdk-devel] [GLm] api
> We are currently using floats, but may want to reserve the possibility of
> havings doubles too. Therefore we use the -f postfix. This is also the GL
> convention of doing things:
>
> glVertex2f
>
> and therefore we have:
>
> glmVecSet2f
>
> instead of:
>
> glmVec2Set
>
> Also, we don't have glmVecDiv or glmVecMul. Why? Because vector division or
> multiplication are not defined in linear-algebra. There are two kinds of
> vector products: cross and dot. These are handled by the -Cross and -Dot
> entry points. Member-wise div or mul are not mathemtically defined
> operations in vector calculus AFAIK.
>
> We have now several open issues with the GLM API:
>
> 1) Should we provide -Mul and -Div for vectors?
> My opinion: no, as they are not defined in mathematics and they generally
> are not needed
>
> 2) Should we use short naming convention or is the current convention fine?
>
> The current convention is, for example:
>
> glmVecSet2f
> glmVecAdd2f
> glmVecLength2f
> glmVecTransform2f
> glmMatSet2f
> glmMatIdentity2f
>
> The proposed short convention would be, for example:
>
> glmVecLen2f
> glmVecTrans2f
> glmMatIdent2f
> glmMatDet2f
>
> 3) Should we drop the -f postfix, or should we keep it for future possible
> double types?,
>
> glmVecSet2f (the current API) vs. glmVecSet2 (the proposed)
>
> My opinion: we should keep the -f, it is more OpenGL-like and we reserve the
> possibility of -d
>
> 4) Should we have the dimension of the type in the end of the entry-point
> (like in OpenGL) or in the middle?
>
> glmVecSet2f (the current API) vs. glmVec2Setf (the proposed)
>
> My opinion: glmVecSet2f, it is more OpenGL-like
>
>
> Issues are open for discussion. Please comment.
>
>
>
> On Mon, Aug 25, 2008 at 10:10 PM, Mars_999 <ma...@si...> wrote:
>>
>> I haven't looked at the lib yet, but aren't we just going to work with
>> floats all the time?
>>
>> glmVec2Sub
>> glmVec3Sub
>> glmVec4Sub
>>
>> glmVec2Add
>> glmVec3Add
>> glmVec4Add
>>
>> glmVec2Mul
>> glmVec2Div
>>
>> glmVec2Norm
>> glmVec2Transf
>> glmVec3Cross
>> glmVec3Dot
>>
>> I like that format...
>>
>> ----- Original Message -----
>> From: Henri Häkkinen
>> To: glsdk-devel
>> Sent: Monday, August 25, 2008 2:04 PM
>> Subject: [Glsdk-devel] [GLm] api
>> The GLM API seems at this moment to use two sets of naming styles. Compare
>> these two for example:
>>
>> glmVecSub2f
>> glmVecLength2f
>>
>> The first function is using a short form for the operation ('sub' as from
>> 'substract') while the other is using long form. Should we simplify the API
>> to look like this:
>>
>> glmVecSub2f
>> glmVecLen2f
>>
>> Althought on the other hand, how do we shorten such stuff as Normalize,
>> Transform, Identity, Inverse? This does not necessary look good:
>>
>> glmVecNorm
>> glmVecTrans
>> glmMatTrans
>> glmMatInv
>> glmMatIdent
>>
>> Is this even a big issue? Comments?
>>
>> If we decide to keep the API as it is now, I think we should lock it in
>> and begin to outline the API reference for it. For later versions, I would
>> like to implement such stuff as colors, quaternions and maybe planes and
>> matrix stacks but this can wait. Bigger priority is to get the current
>> version working and tested for.
>>
>> For Korval: I outlined some API ref in a plain text format. You may find
>> it in 'docs/sdk_reference/glm-apiref' in the latest revision. You may use
>> this as ideas for the DocBook API ref and this file needs to get removed
>> once you migrate it into DocBook.
>>
>> --
>> 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
>
> ________________________________
>
> -------------------------------------------------------------------------
> 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
>
>

Re: [Glsdk-devel] [GLm] api

[Mars_999 <ma...@si...>]

Oops I should have said Mul, and Div aren't defined for vectors. Just clearing up my posting.
  ----- Original Message ----- 
  From: Mars_999 
  To: gls...@li... 
  Sent: Monday, August 25, 2008 3:44 PM
  Subject: Re: [Glsdk-devel] [GLm] api


  glmVecSet2f
  glmVecAdd2f
  glmVecLength2f
  glmVecTransform2f
  glmMatSet2f
  glmMatIdentity2f


  I vote for this.

  Correct, in mathematics vectors aren't defined, but I was thinking ahead for colors or other uses, having these would be nice, but anyone who is coding graphics should understand this already?

  Also don't forget to put in a glmVecScale2f? I guess we could put double in but, IIRC double was going to get dropped? And we aren't doing OpenCL or CUDA here AFAIK, so double would kind of wasteful in terms of time spent.
    ----- Original Message ----- 
    From: Henri Häkkinen 
    To: gls...@li... 
    Sent: Monday, August 25, 2008 3:17 PM
    Subject: Re: [Glsdk-devel] [GLm] api


    We are currently using floats, but may want to reserve the possibility of havings doubles too. Therefore we use the -f postfix. This is also the GL convention of doing things:

    glVertex2f

    and therefore we have:

    glmVecSet2f

    instead of:

    glmVec2Set

    Also, we don't have glmVecDiv or glmVecMul. Why? Because vector division or multiplication are not defined in linear-algebra. There are two kinds of vector products: cross and dot. These are handled by the -Cross and -Dot entry points. Member-wise div or mul are not mathemtically defined operations in vector calculus AFAIK.

    We have now several open issues with the GLM API:

    1) Should we provide -Mul and -Div for vectors?
    My opinion: no, as they are not defined in mathematics and they generally are not needed

    2) Should we use short naming convention or is the current convention fine?

    The current convention is, for example:

    glmVecSet2f
    glmVecAdd2f
    glmVecLength2f
    glmVecTransform2f
    glmMatSet2f
    glmMatIdentity2f

    The proposed short convention would be, for example:

    glmVecLen2f
    glmVecTrans2f
    glmMatIdent2f
    glmMatDet2f

    3) Should we drop the -f postfix, or should we keep it for future possible double types?,

    glmVecSet2f (the current API) vs. glmVecSet2 (the proposed)

    My opinion: we should keep the -f, it is more OpenGL-like and we reserve the possibility of -d

    4) Should we have the dimension of the type in the end of the entry-point (like in OpenGL) or in the middle?

    glmVecSet2f (the current API) vs. glmVec2Setf (the proposed)

    My opinion: glmVecSet2f, it is more OpenGL-like


    Issues are open for discussion. Please comment.




    On Mon, Aug 25, 2008 at 10:10 PM, Mars_999 <ma...@si...> wrote:

      I haven't looked at the lib yet, but aren't we just going to work with floats all the time? 

      glmVec2Sub
      glmVec3Sub
      glmVec4Sub

      glmVec2Add
      glmVec3Add
      glmVec4Add

      glmVec2Mul
      glmVec2Div

      glmVec2Norm
      glmVec2Transf
      glmVec3Cross
      glmVec3Dot

      I like that format...
        ----- Original Message ----- 
        From: Henri Häkkinen 
        To: glsdk-devel 
        Sent: Monday, August 25, 2008 2:04 PM
        Subject: [Glsdk-devel] [GLm] api


        The GLM API seems at this moment to use two sets of naming styles. Compare these two for example:

        glmVecSub2f
        glmVecLength2f

        The first function is using a short form for the operation ('sub' as from 'substract') while the other is using long form. Should we simplify the API to look like this:

        glmVecSub2f
        glmVecLen2f

        Althought on the other hand, how do we shorten such stuff as Normalize, Transform, Identity, Inverse? This does not necessary look good:

        glmVecNorm
        glmVecTrans
        glmMatTrans
        glmMatInv
        glmMatIdent

        Is this even a big issue? Comments?

        If we decide to keep the API as it is now, I think we should lock it in and begin to outline the API reference for it. For later versions, I would like to implement such stuff as colors, quaternions and maybe planes and matrix stacks but this can wait. Bigger priority is to get the current version working and tested for.

        For Korval: I outlined some API ref in a plain text format. You may find it in 'docs/sdk_reference/glm-apiref' in the latest revision. You may use this as ideas for the DocBook API ref and this file needs to get removed once you migrate it into DocBook.

        -- 
        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




----------------------------------------------------------------------------


    -------------------------------------------------------------------------
    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

Re: [Glsdk-devel] [GLm] api

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

Mul and div for colors: I have the idea of implementing colors as different
types altogether:

typedef ... GLMcol3f;
typedef ... GLMcol4f;

glmColSet3f
glmColAdd3f
...

So in this respect, mul and div for vectors are redundant.

About glmVecScale: yes that is already in the current API.

About doubles: yes, doubles are not yet supported in the GL (afaik), but
they will be probably included when the hardware supports them. So we can
prepare for this and use the -f prefix. Also, for colors we might want to
have things like -ub also. So including the type postfix makes sense.

We also had an earlier short discussion in #glsdk if we should have:

glmVectorSet2f
glmMatrixSet2f
glmMatrixIdentity2f

instead of

glmVecSet2f
glmMatSet2f
...

But we decided to keep the short ones. Also this is open for discussion, as
is everything dealing with the GLM API. Comments are most welcome.


On Mon, Aug 25, 2008 at 11:53 PM, Mars_999 <ma...@si...> wrote:

>  Oops I should have said Mul, and Div aren't defined for vectors. Just
> clearing up my posting.
>
> ----- Original Message -----
> *From:* Mars_999 <ma...@si...>
> *To:* gls...@li...
> *Sent:* Monday, August 25, 2008 3:44 PM
> *Subject:* Re: [Glsdk-devel] [GLm] api
>
> glmVecSet2f
> glmVecAdd2f
> glmVecLength2f
> glmVecTransform2f
> glmMatSet2f
> glmMatIdentity2f
>
> I vote for this.
>
> Correct, in mathematics vectors aren't defined, but I was thinking ahead
> for colors or other uses, having these would be nice, but anyone who is
> coding graphics should understand this already?
>
> Also don't forget to put in a glmVecScale2f? I guess we could put double in
> but, IIRC double was going to get dropped? And we aren't doing OpenCL or
> CUDA here AFAIK, so double would kind of wasteful in terms of time spent.
>
> ----- Original Message -----
> *From:* Henri Häkkinen <hen...@gm...>
> *To:* gls...@li...
> *Sent:* Monday, August 25, 2008 3:17 PM
> *Subject:* Re: [Glsdk-devel] [GLm] api
>
> We are currently using floats, but may want to reserve the possibility of
> havings doubles too. Therefore we use the -f postfix. This is also the GL
> convention of doing things:
>
> glVertex2f
>
> and therefore we have:
>
> glmVecSet2f
>
> instead of:
>
> glmVec2Set
>
> Also, we don't have glmVecDiv or glmVecMul. Why? Because vector division or
> multiplication are not defined in linear-algebra. There are two kinds of
> vector products: cross and dot. These are handled by the -Cross and -Dot
> entry points. Member-wise div or mul are not mathemtically defined
> operations in vector calculus AFAIK.
>
> We have now several open issues with the GLM API:
>
> 1) Should we provide -Mul and -Div for vectors?
> My opinion: no, as they are not defined in mathematics and they generally
> are not needed
>
> 2) Should we use short naming convention or is the current convention fine?
>
> The current convention is, for example:
>
> glmVecSet2f
> glmVecAdd2f
> glmVecLength2f
> glmVecTransform2f
> glmMatSet2f
> glmMatIdentity2f
>
> The proposed short convention would be, for example:
>
> glmVecLen2f
> glmVecTrans2f
> glmMatIdent2f
> glmMatDet2f
>
> 3) Should we drop the -f postfix, or should we keep it for future possible
> double types?,
>
> glmVecSet2f (the current API) vs. glmVecSet2 (the proposed)
>
> My opinion: we should keep the -f, it is more OpenGL-like and we reserve
> the possibility of -d
>
> 4) Should we have the dimension of the type in the end of the entry-point
> (like in OpenGL) or in the middle?
>
> glmVecSet2f (the current API) vs. glmVec2Setf (the proposed)
>
> My opinion: glmVecSet2f, it is more OpenGL-like
>
>
> Issues are open for discussion. Please comment.
>
>
>
> On Mon, Aug 25, 2008 at 10:10 PM, Mars_999 <ma...@si...> wrote:
>
>>  I haven't looked at the lib yet, but aren't we just going to work with
>> floats all the time?
>>
>> glmVec2Sub
>> glmVec3Sub
>> glmVec4Sub
>>
>> glmVec2Add
>> glmVec3Add
>> glmVec4Add
>>
>> glmVec2Mul
>> glmVec2Div
>>
>> glmVec2Norm
>> glmVec2Transf
>> glmVec3Cross
>> glmVec3Dot
>>
>> I like that format...
>>
>>   ----- Original Message -----
>> *From:* Henri Häkkinen <hen...@gm...>
>> *To:* glsdk-devel <gls...@li...>
>> *Sent:* Monday, August 25, 2008 2:04 PM
>> *Subject:* [Glsdk-devel] [GLm] api
>>
>> The GLM API seems at this moment to use two sets of naming styles. Compare
>> these two for example:
>>
>> glmVecSub2f
>> glmVecLength2f
>>
>> The first function is using a short form for the operation ('sub' as from
>> 'substract') while the other is using long form. Should we simplify the API
>> to look like this:
>>
>> glmVecSub2f
>> glmVecLen2f
>>
>> Althought on the other hand, how do we shorten such stuff as Normalize,
>> Transform, Identity, Inverse? This does not necessary look good:
>>
>> glmVecNorm
>> glmVecTrans
>> glmMatTrans
>> glmMatInv
>> glmMatIdent
>>
>> Is this even a big issue? Comments?
>>
>> If we decide to keep the API as it is now, I think we should lock it in
>> and begin to outline the API reference for it. For later versions, I would
>> like to implement such stuff as colors, quaternions and maybe planes and
>> matrix stacks but this can wait. Bigger priority is to get the current
>> version working and tested for.
>>
>> For Korval: I outlined some API ref in a plain text format. You may find
>> it in 'docs/sdk_reference/glm-apiref' in the latest revision. You may use
>> this as ideas for the DocBook API ref and this file needs to get removed
>> once you migrate it into DocBook.
>>
>> --
>> 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
>
>  ------------------------------
>
> -------------------------------------------------------------------------
> 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
>
>
> -------------------------------------------------------------------------
> 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] api

[Mars_999 <ma...@si...>]

Good you read my mind then. And the short form is preferred IMO.
  ----- Original Message ----- 
  From: Henri Häkkinen 
  To: gls...@li... 
  Sent: Monday, August 25, 2008 4:08 PM
  Subject: Re: [Glsdk-devel] [GLm] api


  Mul and div for colors: I have the idea of implementing colors as different types altogether:

  typedef ... GLMcol3f;
  typedef ... GLMcol4f;

  glmColSet3f
  glmColAdd3f
  ...

  So in this respect, mul and div for vectors are redundant.

  About glmVecScale: yes that is already in the current API.

  About doubles: yes, doubles are not yet supported in the GL (afaik), but they will be probably included when the hardware supports them. So we can prepare for this and use the -f prefix. Also, for colors we might want to have things like -ub also. So including the type postfix makes sense.

  We also had an earlier short discussion in #glsdk if we should have:

  glmVectorSet2f
  glmMatrixSet2f
  glmMatrixIdentity2f

  instead of

  glmVecSet2f
  glmMatSet2f
  ...

  But we decided to keep the short ones. Also this is open for discussion, as is everything dealing with the GLM API. Comments are most welcome.



  On Mon, Aug 25, 2008 at 11:53 PM, Mars_999 <ma...@si...> wrote:

    Oops I should have said Mul, and Div aren't defined for vectors. Just clearing up my posting.
      ----- Original Message ----- 
      From: Mars_999 
      To: gls...@li... 
      Sent: Monday, August 25, 2008 3:44 PM
      Subject: Re: [Glsdk-devel] [GLm] api


      glmVecSet2f
      glmVecAdd2f
      glmVecLength2f
      glmVecTransform2f
      glmMatSet2f
      glmMatIdentity2f


      I vote for this.

      Correct, in mathematics vectors aren't defined, but I was thinking ahead for colors or other uses, having these would be nice, but anyone who is coding graphics should understand this already?

      Also don't forget to put in a glmVecScale2f? I guess we could put double in but, IIRC double was going to get dropped? And we aren't doing OpenCL or CUDA here AFAIK, so double would kind of wasteful in terms of time spent.
        ----- Original Message ----- 
        From: Henri Häkkinen 
        To: gls...@li... 
        Sent: Monday, August 25, 2008 3:17 PM
        Subject: Re: [Glsdk-devel] [GLm] api


        We are currently using floats, but may want to reserve the possibility of havings doubles too. Therefore we use the -f postfix. This is also the GL convention of doing things:

        glVertex2f

        and therefore we have:

        glmVecSet2f

        instead of:

        glmVec2Set

        Also, we don't have glmVecDiv or glmVecMul. Why? Because vector division or multiplication are not defined in linear-algebra. There are two kinds of vector products: cross and dot. These are handled by the -Cross and -Dot entry points. Member-wise div or mul are not mathemtically defined operations in vector calculus AFAIK.

        We have now several open issues with the GLM API:

        1) Should we provide -Mul and -Div for vectors?
        My opinion: no, as they are not defined in mathematics and they generally are not needed

        2) Should we use short naming convention or is the current convention fine?

        The current convention is, for example:

        glmVecSet2f
        glmVecAdd2f
        glmVecLength2f
        glmVecTransform2f
        glmMatSet2f
        glmMatIdentity2f

        The proposed short convention would be, for example:

        glmVecLen2f
        glmVecTrans2f
        glmMatIdent2f
        glmMatDet2f

        3) Should we drop the -f postfix, or should we keep it for future possible double types?,

        glmVecSet2f (the current API) vs. glmVecSet2 (the proposed)

        My opinion: we should keep the -f, it is more OpenGL-like and we reserve the possibility of -d

        4) Should we have the dimension of the type in the end of the entry-point (like in OpenGL) or in the middle?

        glmVecSet2f (the current API) vs. glmVec2Setf (the proposed)

        My opinion: glmVecSet2f, it is more OpenGL-like


        Issues are open for discussion. Please comment.




        On Mon, Aug 25, 2008 at 10:10 PM, Mars_999 <ma...@si...> wrote:

          I haven't looked at the lib yet, but aren't we just going to work with floats all the time? 

          glmVec2Sub
          glmVec3Sub
          glmVec4Sub

          glmVec2Add
          glmVec3Add
          glmVec4Add

          glmVec2Mul
          glmVec2Div

          glmVec2Norm
          glmVec2Transf
          glmVec3Cross
          glmVec3Dot

          I like that format...
            ----- Original Message ----- 
            From: Henri Häkkinen 
            To: glsdk-devel 
            Sent: Monday, August 25, 2008 2:04 PM
            Subject: [Glsdk-devel] [GLm] api


            The GLM API seems at this moment to use two sets of naming styles. Compare these two for example:

            glmVecSub2f
            glmVecLength2f

            The first function is using a short form for the operation ('sub' as from 'substract') while the other is using long form. Should we simplify the API to look like this:

            glmVecSub2f
            glmVecLen2f

            Althought on the other hand, how do we shorten such stuff as Normalize, Transform, Identity, Inverse? This does not necessary look good:

            glmVecNorm
            glmVecTrans
            glmMatTrans
            glmMatInv
            glmMatIdent

            Is this even a big issue? Comments?

            If we decide to keep the API as it is now, I think we should lock it in and begin to outline the API reference for it. For later versions, I would like to implement such stuff as colors, quaternions and maybe planes and matrix stacks but this can wait. Bigger priority is to get the current version working and tested for.

            For Korval: I outlined some API ref in a plain text format. You may find it in 'docs/sdk_reference/glm-apiref' in the latest revision. You may use this as ideas for the DocBook API ref and this file needs to get removed once you migrate it into DocBook.

            -- 
            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




------------------------------------------------------------------------


        -------------------------------------------------------------------------
        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


    -------------------------------------------------------------------------
    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




------------------------------------------------------------------------------


  -------------------------------------------------------------------------
  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] api

[<gl...@mo...>]

> 1) Should we provide -Mul and -Div for vectors?
Depends if this math library is graphics-related ;)
It also depends on whenever we're defining matmemathical operations or
software functions in this library.

Isn't glmMatRotateYPR3 obsolete since there are glmMatRotate[X|Y|Z]3
functions defined?

Will only Mat3 have Scale and ScaleUniform defined?

Vector's Scale function is actually equivalent to ScaleUniform function
for matrix. Should vectors have both Scale and ScaleUniform functions
defined instead? If yes, then Mul and Div become obsolete.

Should we have:
glmMatRotate3f(GLMmat3f *out, const GLMvec3f* axis, GLfloat angle);
or rather:
glmMatRotate3f(GLMmat3f *out, GLfloat angle, GLfloat x, GLfloat y, GLfloat
z);
?

Please note that these questions are not in our issue list unless Henri H.
sees them as worth considering.



> 2) Should we use short naming convention or is the current convention fine?

Full operation names are better (subjective opinion), with the exception
of "Subtract" :)



> 4) Should we have the dimension of the type in the end of the entry-point
> (like in OpenGL) or in the middle?

Both are equally fine and referring either to Vec<n> data type or function
operating on <n> components, but dimension placed at end makes for a nice
separator between operation name and data type postfix.

Re: [Glsdk-devel] [GLm] api

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

> > 1) Should we provide -Mul and -Div for vectors?
> Depends if this math library is graphics-related ;)
> It also depends on whenever we're defining matmemathical operations or
> software functions in this library.
>
This mathlib is graphics related. What do you mean 'mathematical operations
or software operations'?

Isn't glmMatRotateYPR3 obsolete since there are glmMatRotate[X|Y|Z]3
> functions defined?
>
No. RotateYPR is a convenience function, meaning that it is easier for the
user to set up a complicated rotation matrix in this way. It is also faster
to calculate a yaw-pitch-roll rotation matrix in one go than constructing
each rotation independently and then multiplying them together. The current
implementation thought does it just this way, but the function needs a
cleanup.

Will only Mat3 have Scale and ScaleUniform defined?

3D scaling matrices are natively 3x3 matrices. There could be a 4x4 version
of it and there definelty should be 2x2 version of it (this will be added).


> Vector's Scale function is actually equivalent to ScaleUniform function
> for matrix.

MatScale* creates 3x3 scaling matrices while VecScale multiplies each vector
member by a scalar. They are two different things.


> Should vectors have both Scale and ScaleUniform functions
> defined instead? If yes, then Mul and Div become obsolete.

Vectors could have ScaleUniform also for a convenience, but currently they
don't have. Vector mul and div are not part of the current API for reasons
stated in my previous posts.


> Should we have:
> glmMatRotate3f(GLMmat3f *out, const GLMvec3f* axis, GLfloat angle);
> or rather:
> glmMatRotate3f(GLMmat3f *out, GLfloat angle, GLfloat x, GLfloat y, GLfloat
> z);
> ?
> Please note that these questions are not in our issue list unless Henri H.
> sees them as worth considering.

Your points are very well worth considering. Currently the API has only
Rotate(out, axis, angle). I think it is bad idea to bloat the API needlesly
and we should choose only one of the two. The real question is which is
better. The matter is open for discussion.


> > 2) Should we use short naming convention or is the current convention
> fine?
> Full operation names are better (subjective opinion), with the exception
> of "Subtract" :)
>
Okay, I gather you support the current API effort.


> > 4) Should we have the dimension of the type in the end of the entry-point
> > (like in OpenGL) or in the middle?
>
> Both are equally fine and referring either to Vec<n> data type or function
> operating on <n> components, but dimension placed at end makes for a nice
> separator between operation name and data type postfix.
>
That is how I feel also. This is also the OpenGL convention of operations
which we would like to conform to.

My current GLM efforts revolve around stabilizing and writing test cases for
the current API. This will take time, as matrix test cases are complicated
to write. Once this is done, I will continue on adding new entry-points
(such as the above suggested 2x2 scaling matrix constructor).

-- 
Henri 'henux' Häkkinen

Re: [Glsdk-devel] [GLm] api

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

On Tue, Aug 26, 2008 at 12:39 AM, <gl...@mo...> wrote:

> > 1) Should we provide -Mul and -Div for vectors?
> Depends if this math library is graphics-related ;)
> It also depends on whenever we're defining matmemathical operations or
> software functions in this library.


This mathlib is graphics related. What do you mean 'mathematical operations
or software operations'?


>
>
> Isn't glmMatRotateYPR3 obsolete since there are glmMatRotate[X|Y|Z]3
> functions defined?


No. glmMatRotateYPR is a convenience function, meaning that it is easier for
the user to set up a complicated rotation matrix in this way. Also, it is
also faster to calculate a yaw-pitch-roll rotation matrix in one go than
constructing each rotation in separate phase and then multiplying them
together. The current implementation thought, does it just this way, but
this function needs to be cleanup and fixed in time.


Will only Mat3 have Scale and ScaleUniform defined?
>

MatScale3 and -ScalingUniform3 functions constructs a 3x3 scaling matrix. It
might be useful for the API to have equivalent 4x4 matrix constructors too,
thought. The API is not yet set in stone. My current effort includes writing
test cases for the current API, and when this is done, I will continue on
adding more functionality.


>
> Vector's Scale function is actually equivalent to ScaleUniform function
> for matrix. Should vectors have both Scale and ScaleUniform functions
> defined instead? If yes, then Mul and Div become obsolete.
>

Yes and no. The vector scale function multiplies each vector member by
scalar. Matrix scale constructors create scaling matrices. They do different
things. VecScaleUniform is an entry-point which could be included for
convenience thought, true.

Mul and div for vectors are not part of the API for reasons stated in my
previous posts (they are not defined in vector calculus).



>
> Should we have:
> glmMatRotate3f(GLMmat3f *out, const GLMvec3f* axis, GLfloat angle);
> or rather:
> glmMatRotate3f(GLMmat3f *out, GLfloat angle, GLfloat x, GLfloat y, GLfloat
> z);
> ?
>
> Please note that these questions are not in our issue list unless Henri H.
> sees them as worth considering.
>

Of course, your points are very worth of considering :)

At the moment I have only MatRotate (out, axis, angle). I think we don't
want to bloat the API any more than we actually need. Which version of the
above functions we should actually have, is a valid question indeed.
Providing them both, IMO, is redundant. This is open for discussion.



>
>
> > 2) Should we use short naming convention or is the current convention
> fine?
>
> Full operation names are better (subjective opinion), with the exception
> of "Subtract" :)
>

Okay so I gather you support the current API convention.



>
>
>
> > 4) Should we have the dimension of the type in the end of the entry-point
> > (like in OpenGL) or in the middle?
>
> Both are equally fine and referring either to Vec<n> data type or function
> operating on <n> components, but dimension placed at end makes for a nice
> separator between operation name and data type postfix.
>

That is my opinion too and that is also the OpenGL convention of operations
and we would like to conform with that.


>
>
> -------------------------------------------------------------------------
> 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] api

[<gl...@mo...>]

> What do you mean 'mathematical operations or software operations'?

In math we can graphically represent vectors as arrows pointing form
(point A to B. It's hard to imagine how we could visualize Mul operation
in such form.

In graphics library we often use vectors to represent size or other
things. Especially when comes to 2D rendering, transforming vectors by
means of Add/Mul is more common than transforming my multiplying (x, y,
1.0) vector by 3x3 matrix for the sake of both simplicity and performance.

Even in 3D space. Imagine a volume defined as a box with origin at point A
and a size of S. If point B lays within this box then C = (B - A) / S
gives texture-space coordinate for point B. An alternative would be to
define a 4x4 transformation matrix that transforms point B into texture
space. Such matrix would be defined as conjunction of glmMatTranslate and
glmMatScale.


These are the kind of examples showing that even if something is useless
in math, it's useful in programming.
Sorry for speaking in riddles the first time ;)

It's bed time for me. Cheers.

Re: [Glsdk-devel] [GLm] api

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

Okay I see what you mean by that. However I think our mathlib is intended
mainly to be used for OpenGL (a matrix based system), so mul and div feels a
bit redundant atm.

On Tue, Aug 26, 2008 at 1:20 AM, <gl...@mo...> wrote:

> > What do you mean 'mathematical operations or software operations'?
>
> In math we can graphically represent vectors as arrows pointing form
> (point A to B. It's hard to imagine how we could visualize Mul operation
> in such form.
>
> In graphics library we often use vectors to represent size or other
> things. Especially when comes to 2D rendering, transforming vectors by
> means of Add/Mul is more common than transforming my multiplying (x, y,
> 1.0) vector by 3x3 matrix for the sake of both simplicity and performance.
>
> Even in 3D space. Imagine a volume defined as a box with origin at point A
> and a size of S. If point B lays within this box then C = (B - A) / S
> gives texture-space coordinate for point B. An alternative would be to
> define a 4x4 transformation matrix that transforms point B into texture
> space. Such matrix would be defined as conjunction of glmMatTranslate and
> glmMatScale.
>
>
> These are the kind of examples showing that even if something is useless
> in math, it's useful in programming.
> Sorry for speaking in riddles the first time ;)
>
> It's bed time for me. Cheers.
>
>
> -------------------------------------------------------------------------
> 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] api

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

Okay.

I think I can say that the GLM API is more or less "set". This does not mean
that there won't be any additions or modifications to it but the general
look of it is fine with me and it has been open for discussion for some
time. So if Korval could at some point take it to his tasks to write the API
reference outline in DocBook which I could fill in with the actual docs. The
'docs/sdk_reference/glm-apiref' file may also be removed in the process.

On Tue, Aug 26, 2008 at 5:16 PM, Henri Häkkinen <hen...@gm...> wrote:

> Okay I see what you mean by that. However I think our mathlib is intended
> mainly to be used for OpenGL (a matrix based system), so mul and div feels a
> bit redundant atm.
>
>
> On Tue, Aug 26, 2008 at 1:20 AM, <gl...@mo...> wrote:
>
>> > What do you mean 'mathematical operations or software operations'?
>>
>> In math we can graphically represent vectors as arrows pointing form
>> (point A to B. It's hard to imagine how we could visualize Mul operation
>> in such form.
>>
>> In graphics library we often use vectors to represent size or other
>> things. Especially when comes to 2D rendering, transforming vectors by
>> means of Add/Mul is more common than transforming my multiplying (x, y,
>> 1.0) vector by 3x3 matrix for the sake of both simplicity and performance.
>>
>> Even in 3D space. Imagine a volume defined as a box with origin at point A
>> and a size of S. If point B lays within this box then C = (B - A) / S
>> gives texture-space coordinate for point B. An alternative would be to
>> define a 4x4 transformation matrix that transforms point B into texture
>> space. Such matrix would be defined as conjunction of glmMatTranslate and
>> glmMatScale.
>>
>>
>> These are the kind of examples showing that even if something is useless
>> in math, it's useful in programming.
>> Sorry for speaking in riddles the first time ;)
>>
>> It's bed time for me. Cheers.
>>
>>
>> -------------------------------------------------------------------------
>> 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] api

[Andrew G. <and...@gm...>]

Just glancing at GLM src and noticed in glmMatDeterm4f that assert(m) should
be assert(m_).

pudman

On Tue, Aug 26, 2008 at 10:24 AM, Henri Häkkinen <hen...@gm...> wrote:

> Okay.
>
> I think I can say that the GLM API is more or less "set". This does not
> mean that there won't be any additions or modifications to it but the
> general look of it is fine with me and it has been open for discussion for
> some time. So if Korval could at some point take it to his tasks to write
> the API reference outline in DocBook which I could fill in with the actual
> docs. The 'docs/sdk_reference/glm-apiref' file may also be removed in the
> process.
>
>
> On Tue, Aug 26, 2008 at 5:16 PM, Henri Häkkinen <hen...@gm...>wrote:
>
>> Okay I see what you mean by that. However I think our mathlib is intended
>> mainly to be used for OpenGL (a matrix based system), so mul and div feels a
>> bit redundant atm.
>>
>>
>> On Tue, Aug 26, 2008 at 1:20 AM, <gl...@mo...> wrote:
>>
>>> > What do you mean 'mathematical operations or software operations'?
>>>
>>> In math we can graphically represent vectors as arrows pointing form
>>> (point A to B. It's hard to imagine how we could visualize Mul operation
>>> in such form.
>>>
>>> In graphics library we often use vectors to represent size or other
>>> things. Especially when comes to 2D rendering, transforming vectors by
>>> means of Add/Mul is more common than transforming my multiplying (x, y,
>>> 1.0) vector by 3x3 matrix for the sake of both simplicity and
>>> performance.
>>>
>>> Even in 3D space. Imagine a volume defined as a box with origin at point
>>> A
>>> and a size of S. If point B lays within this box then C = (B - A) / S
>>> gives texture-space coordinate for point B. An alternative would be to
>>> define a 4x4 transformation matrix that transforms point B into texture
>>> space. Such matrix would be defined as conjunction of glmMatTranslate and
>>> glmMatScale.
>>>
>>>
>>> These are the kind of examples showing that even if something is useless
>>> in math, it's useful in programming.
>>> Sorry for speaking in riddles the first time ;)
>>>
>>> It's bed time for me. Cheers.
>>>
>>>
>>> -------------------------------------------------------------------------
>>> 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
>
>
> -------------------------------------------------------------------------
> 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] api

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

Thanks. That is absolutely true. I would have missed that without your post.
Will be fixed in the next commit.

On Tue, Aug 26, 2008 at 9:24 PM, Andrew Gajda <and...@gm...>wrote:

> Just glancing at GLM src and noticed in glmMatDeterm4f that assert(m)
> should be assert(m_).
>
> pudman
>
>
> On Tue, Aug 26, 2008 at 10:24 AM, Henri Häkkinen <hen...@gm...>wrote:
>
>> Okay.
>>
>> I think I can say that the GLM API is more or less "set". This does not
>> mean that there won't be any additions or modifications to it but the
>> general look of it is fine with me and it has been open for discussion for
>> some time. So if Korval could at some point take it to his tasks to write
>> the API reference outline in DocBook which I could fill in with the actual
>> docs. The 'docs/sdk_reference/glm-apiref' file may also be removed in the
>> process.
>>
>>
>> On Tue, Aug 26, 2008 at 5:16 PM, Henri Häkkinen <hen...@gm...>wrote:
>>
>>> Okay I see what you mean by that. However I think our mathlib is intended
>>> mainly to be used for OpenGL (a matrix based system), so mul and div feels a
>>> bit redundant atm.
>>>
>>>
>>> On Tue, Aug 26, 2008 at 1:20 AM, <gl...@mo...> wrote:
>>>
>>>> > What do you mean 'mathematical operations or software operations'?
>>>>
>>>> In math we can graphically represent vectors as arrows pointing form
>>>> (point A to B. It's hard to imagine how we could visualize Mul operation
>>>> in such form.
>>>>
>>>> In graphics library we often use vectors to represent size or other
>>>> things. Especially when comes to 2D rendering, transforming vectors by
>>>> means of Add/Mul is more common than transforming my multiplying (x, y,
>>>> 1.0) vector by 3x3 matrix for the sake of both simplicity and
>>>> performance.
>>>>
>>>> Even in 3D space. Imagine a volume defined as a box with origin at point
>>>> A
>>>> and a size of S. If point B lays within this box then C = (B - A) / S
>>>> gives texture-space coordinate for point B. An alternative would be to
>>>> define a 4x4 transformation matrix that transforms point B into texture
>>>> space. Such matrix would be defined as conjunction of glmMatTranslate
>>>> and
>>>> glmMatScale.
>>>>
>>>>
>>>> These are the kind of examples showing that even if something is useless
>>>> in math, it's useful in programming.
>>>> Sorry for speaking in riddles the first time ;)
>>>>
>>>> It's bed time for me. Cheers.
>>>>
>>>>
>>>>
>>>> -------------------------------------------------------------------------
>>>> 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
>>
>>
>> -------------------------------------------------------------------------
>> 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