glsdk-devel

[Glsdk-devel] Commentary on the math library

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

So, I've taken a little time and looked at the current version of the 
math library. It seems to be coming along quite well, but I do have some 
suggestions for improvement.

- We should have a series of Vec4 functions that treat their inputs as 
normalized quaternions. Basically quaternion multiplication, quaternion 
inverse, and a function to convert quaternions into rotation matrices. 
Enough to use quaternions. Oh, and a function to convert angle/axis into 
a quaternion (and one to go back?). I don't think we need a full-fledged 
quaternion type, as a 4-vector of floats is a 4-vector of floats; it's 
all in how you use it.

- Rename the parameters in the lerp functions. I have always had a 
problem with lerp functions in terms of figuring out which parameter I 
would get with an alpha of 0 and which I would get with an alpha of 1. 
So the idea is to have the lerp parameter names themselves specify which 
way it works. IE: "glmVecLerp3f (GLMvec3f *out, const GLMvec3f **v0*, 
const GLMvec3f **v1*, GLfloat s);" It is much more apparent than if 
s==0.0f, you'll get v0, since it has a 0 in the name. Same goes with v1.

- The names of many of the matrix functions do not intuitively describe 
their results. Take the function "GLMmat3f *glmMatRotateX3f (GLMmat3f 
*out, GLfloat angle);" This can do one of two things. It can overwrite 
the contents of "out" with a rotation matrix about the X axis, or it can 
/multiply/ the contents of out by that matrix. The latter would be the 
typical OpenGL style, but the former is what most math libraries would 
do. However, what about "GLMmat3f *glmMatTranslate3f (GLMmat3f *out, 
GLfloat x, GLfloat y);"? This is a function where it would make some 
sense for it to not overwrite the full contents of "out" (though an 
argument can be made that it should). Or at least, one would expect 
there to be a version of Translate3f that will only change the 2 
positional coordinates of a transformation matrix.

Honestly, I'm not sure what to do about it, or if we should do anything 
at all. If all of the functions have one specific kind of behavior 
(overwrite, say), then at least the library is consistent. It just feels 
weird to me to have a function like "glmMatTranslate3f" that completely 
overwrites the matrix rather than just setting certain fields.

This is more something that bugs me than something I think is wrong.

- All of those Mat3 functions for generating transformation matrices? We 
should have Mat4 versions as well. Since Mat3's cannot easily be 
converted into Mat4's, and Mat4's are full 3D transformation matrices, 
it makes sense to provide full coverage in generating transformation 
matrices at the Mat4 level.

- BTW, is the math library going to provide a matrix stack, or is that 
something for a higher-level library?

Re: [Glsdk-devel] Commentary on the math library

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

For point #3, a solution may be to create two versions of many of the matrix
functions:

*GLMmat3f *glmMatTranslate3f (GLMmat3f *out, GLfloat x, GLfloat y);
GLMmat3f *glmMatTranslate3f (GLMmat3f *out, GLMmat3f *in, GLfloat x, GLfloat
y);*

The first one creates a translation matrix (overwrites *out) and the second
one multiplies *in by a rotation matrix and saves the result in *out.  It
isn't technically necessary as you can still do:

*glmMatMult3f( &myMatrix, glmMatTranslate( &tmp, x, y ) );*

The only disadvantage is the usage of a tmp variable.

As for the matrix stack, it almost seems like it needs a separate library
because it maintains state which GLM doesn't do (so far).  I was wondering,
are there any issues with creating our own version of GLU?  The GLU spec was
written against GL1.1.  Seems like it's time to rewrite it.  Otherwise we
have to come up with another library name that means GL utility library, or
GL matrix stack library (GLMS?).  It is our own SDK so, as long as we don't
use the official GLU library, I don't think there's any reason not to create
our own.

pudman

Re: [Glsdk-devel] Commentary on the math library

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

> For point #3, a solution may be to create two versions of many of the
> matrix
> functions:
>
> *GLMmat3f *glmMatTranslate3f (GLMmat3f *out, GLfloat x, GLfloat y);
> GLMmat3f *glmMatTranslate3f (GLMmat3f *out, GLMmat3f *in, GLfloat x,
> GLfloat
> y);*

I don't think we're doing any function overriding :)

*IF* we're going to have both, then my proposal would be:
1.
glmMatTranslate - creates matrix
glmMulMatTranslate - translates (multiplies by translation matrix)

2.
glmMatOfTranslation | glmMatTranslation (confusing) | glmTranslationMat
Last one is nice, but in conflict with our current naming convention.

glmMatTranslate - translates matrix


I thought glm<type><action> naming convention is nice. Now I have my
doubts :P - glmTranslateMat and glmTranslationMat seem pretty distinct,
while having "Mat" at beginning requires some gymnastics later.



> As for the matrix stack, it almost seems like it needs a separate library

Perspective, LookAt, etc. functions should be in GLU (and they are), since
they're related to graphics.

Matrix stack is not related to graphics actually. We have similar stack in
FPU, but FPU needed it because it was separate from CPU. With OpenGL we
have similar case (it can't access matrices stored in system memory - it
has it's own storage).

Actually, for SDK we don't really need matrix stack :) Just think of it -
each function in the program has it's own local variables (so local
matrices, too). If we could design our examples in a way that matrix stack
matches function stack... :)
Yeah, I know - I'm a heretic ;)

I didn't give it any serious thought - tus idea just popped up a moment
ago. Perhaps it's a good design pattern, perhaps it's not.

Re: [Glsdk-devel] Commentary on the math library

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

A matrix stack would require re-implementing many of the matrix
functions to work on the stack variable, rather than an arbitrary
matrix. Not difficult, but still a bit of a pain

Branan

On Thu, Aug 28, 2008 at 9:08 AM,  <gl...@mo...> wrote:
>> For point #3, a solution may be to create two versions of many of the
>> matrix
>> functions:
>>
>> *GLMmat3f *glmMatTranslate3f (GLMmat3f *out, GLfloat x, GLfloat y);
>> GLMmat3f *glmMatTranslate3f (GLMmat3f *out, GLMmat3f *in, GLfloat x,
>> GLfloat
>> y);*
>
> I don't think we're doing any function overriding :)
>
> *IF* we're going to have both, then my proposal would be:
> 1.
> glmMatTranslate - creates matrix
> glmMulMatTranslate - translates (multiplies by translation matrix)
>
> 2.
> glmMatOfTranslation | glmMatTranslation (confusing) | glmTranslationMat
> Last one is nice, but in conflict with our current naming convention.
>
> glmMatTranslate - translates matrix
>
>
> I thought glm<type><action> naming convention is nice. Now I have my
> doubts :P - glmTranslateMat and glmTranslationMat seem pretty distinct,
> while having "Mat" at beginning requires some gymnastics later.
>
>
>
>> As for the matrix stack, it almost seems like it needs a separate library
>
> Perspective, LookAt, etc. functions should be in GLU (and they are), since
> they're related to graphics.
>
> Matrix stack is not related to graphics actually. We have similar stack in
> FPU, but FPU needed it because it was separate from CPU. With OpenGL we
> have similar case (it can't access matrices stored in system memory - it
> has it's own storage).
>
> Actually, for SDK we don't really need matrix stack :) Just think of it -
> each function in the program has it's own local variables (so local
> matrices, too). If we could design our examples in a way that matrix stack
> matches function stack... :)
> Yeah, I know - I'm a heretic ;)
>
> I didn't give it any serious thought - tus idea just popped up a moment
> ago. Perhaps it's a good design pattern, perhaps it's not.
>
>
> -------------------------------------------------------------------------
> 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] Commentary on the math library

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

On Thu, Aug 28, 2008 at 12:32 PM, Jason McKesson <ko...@gm...> wrote:

> - We should have a series of Vec4 functions that treat their inputs as
> normalized quaternions. Basically quaternion multiplication, quaternion
> inverse, and a function to convert quaternions into rotation matrices.
> Enough to use quaternions. Oh, and a function to convert angle/axis into a
> quaternion (and one to go back?). I don't think we need a full-fledged
> quaternion type, as a 4-vector of floats is a 4-vector of floats; it's all
> in how you use it.
>

I think we should implement full featured GLMquatf type.


> - Rename the parameters in the lerp functions. I have always had a problem
> with lerp functions in terms of figuring out which parameter I would get
> with an alpha of 0 and which I would get with an alpha of 1. So the idea is
> to have the lerp parameter names themselves specify which way it works. IE:
> "glmVecLerp3f (GLMvec3f *out, const GLMvec3f **v0*, const GLMvec3f **v1*,
> GLfloat s);" It is much more apparent than if s==0.0f, you'll get v0, since
> it has a 0 in the name. Same goes with v1.
>

Fine, this is a valid point. I will be renaming all argument names into v0,
v1 and m0, m1 for consistency at some point.



> - The names of many of the matrix functions do not intuitively describe
> their results. Take the function "GLMmat3f *glmMatRotateX3f (GLMmat3f *out,
> GLfloat angle);" This can do one of two things. It can overwrite the
> contents of "out" with a rotation matrix about the X axis, or it can *
> multiply* the contents of out by that matrix. The latter would be the
> typical OpenGL style, but the former is what most math libraries would do.
> However, what about "GLMmat3f *glmMatTranslate3f (GLMmat3f *out, GLfloat x,
> GLfloat y);"? This is a function where it would make some sense for it to
> not overwrite the full contents of "out" (though an argument can be made
> that it should). Or at least, one would expect there to be a version of
> Translate3f that will only change the 2 positional coordinates of a
> transformation matrix.
>
> Honestly, I'm not sure what to do about it, or if we should do anything at
> all. If all of the functions have one specific kind of behavior (overwrite,
> say), then at least the library is consistent. It just feels weird to me to
> have a function like "glmMatTranslate3f" that completely overwrites the
> matrix rather than just setting certain fields.
>

This matter needs to be considered. We should also write the API references.


> - All of those Mat3 functions for generating transformation matrices? We
> should have Mat4 versions as well. Since Mat3's cannot easily be converted
> into Mat4's, and Mat4's are full 3D transformation matrices, it makes sense
> to provide full coverage in generating transformation matrices at the Mat4
> level.
>

I think we should provide an entry-point for creating 4x4 matrices from 3x3
matrix and a 3D vector as the last vertical column:

glmMatCompose (&out, &rotation, &translation);

or something similar.


> - BTW, is the math library going to provide a matrix stack, or is that
> something for a higher-level library?
>

No idea at this point yet.


>
> -------------------------------------------------------------------------
> 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] Commentary on the math library

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

Maybe it's been a while since I've done pure C (like with my function
overloading example) but can someone tell me what the advantage might to
doing:
*someGLMfunc( GLMvec3f *out, blah, blah )
{
   GLMvef3 tmp;
   ...
   tmp.x = something;
**   tmp.y = something;
**   tmp.z = something;

   *out = tmp;

   return out;
}*

Why not just assign *out directly?

On Thu, Aug 28, 2008 at 12:52 PM, Henri Häkkinen <hen...@gm...> wrote:

> On Thu, Aug 28, 2008 at 12:32 PM, Jason McKesson <ko...@gm...>wrote:
>
>> - We should have a series of Vec4 functions that treat their inputs as
>> normalized quaternions. Basically quaternion multiplication, quaternion
>> inverse, and a function to convert quaternions into rotation matrices.
>> Enough to use quaternions. Oh, and a function to convert angle/axis into a
>> quaternion (and one to go back?). I don't think we need a full-fledged
>> quaternion type, as a 4-vector of floats is a 4-vector of floats; it's all
>> in how you use it.
>>
>
> I think we should implement full featured GLMquatf type.
>
>
>> - Rename the parameters in the lerp functions. I have always had a problem
>> with lerp functions in terms of figuring out which parameter I would get
>> with an alpha of 0 and which I would get with an alpha of 1. So the idea is
>> to have the lerp parameter names themselves specify which way it works. IE:
>> "glmVecLerp3f (GLMvec3f *out, const GLMvec3f **v0*, const GLMvec3f **v1*,
>> GLfloat s);" It is much more apparent than if s==0.0f, you'll get v0, since
>> it has a 0 in the name. Same goes with v1.
>>
>
> Fine, this is a valid point. I will be renaming all argument names into v0,
> v1 and m0, m1 for consistency at some point.
>
>
>
>> - The names of many of the matrix functions do not intuitively describe
>> their results. Take the function "GLMmat3f *glmMatRotateX3f (GLMmat3f *out,
>> GLfloat angle);" This can do one of two things. It can overwrite the
>> contents of "out" with a rotation matrix about the X axis, or it can *
>> multiply* the contents of out by that matrix. The latter would be the
>> typical OpenGL style, but the former is what most math libraries would do.
>> However, what about "GLMmat3f *glmMatTranslate3f (GLMmat3f *out, GLfloat x,
>> GLfloat y);"? This is a function where it would make some sense for it to
>> not overwrite the full contents of "out" (though an argument can be made
>> that it should). Or at least, one would expect there to be a version of
>> Translate3f that will only change the 2 positional coordinates of a
>> transformation matrix.
>>
>> Honestly, I'm not sure what to do about it, or if we should do anything at
>> all. If all of the functions have one specific kind of behavior (overwrite,
>> say), then at least the library is consistent. It just feels weird to me to
>> have a function like "glmMatTranslate3f" that completely overwrites the
>> matrix rather than just setting certain fields.
>>
>
> This matter needs to be considered. We should also write the API
> references.
>
>
>> - All of those Mat3 functions for generating transformation matrices? We
>> should have Mat4 versions as well. Since Mat3's cannot easily be converted
>> into Mat4's, and Mat4's are full 3D transformation matrices, it makes sense
>> to provide full coverage in generating transformation matrices at the Mat4
>> level.
>>
>
> I think we should provide an entry-point for creating 4x4 matrices from 3x3
> matrix and a 3D vector as the last vertical column:
>
> glmMatCompose (&out, &rotation, &translation);
>
> or something similar.
>
>
>> - BTW, is the math library going to provide a matrix stack, or is that
>> something for a higher-level library?
>>
>
> No idea at this point yet.
>
>
>>
>> -------------------------------------------------------------------------
>> 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] Commentary on the math library

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

On Thu, Aug 28, 2008 at 12:35 PM, Andrew Gajda <and...@gm...> wrote:
> Maybe it's been a while since I've done pure C (like with my function
> overloading example) but can someone tell me what the advantage might to
> doing:
> someGLMfunc( GLMvec3f *out, blah, blah )
> {
>    GLMvef3 tmp;
>    ...
>    tmp.x = something;
>    tmp.y = something;
>    tmp.z = something;
>
>    *out = tmp;
>
>    return out;
> }
>
> Why not just assign *out directly?

Because "out" may be equal to "blah":

someFunc(GLMvec3f *out, GLMvec3f *in1, GLMvec3f *in2);

GLMvec3f first, second;
someFunc(&first, &first, &second);

Re: [Glsdk-devel] Commentary on the math library

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

On Thu, Aug 28, 2008 at 9:52 AM, Henri Häkkinen <hen...@gm...> wrote:
> On Thu, Aug 28, 2008 at 12:32 PM, Jason McKesson <ko...@gm...> wrote:
>>
>> - We should have a series of Vec4 functions that treat their inputs as
>> normalized quaternions. Basically quaternion multiplication, quaternion
>> inverse, and a function to convert quaternions into rotation matrices.
>> Enough to use quaternions. Oh, and a function to convert angle/axis into a
>> quaternion (and one to go back?). I don't think we need a full-fledged
>> quaternion type, as a 4-vector of floats is a 4-vector of floats; it's all
>> in how you use it.
>
> I think we should implement full featured GLMquatf type.

You can if you want, but we'll have to support every operation that
Vec4's support on them. So if we have a "UniformVec4f" function for
setting uniforms, we would need a separate "UniformQuatf" function for
setting quaternions. It seems wasteful, especially if we're going to
use Vec4f's for things like colors.

>
>>
>> - All of those Mat3 functions for generating transformation matrices? We
>> should have Mat4 versions as well. Since Mat3's cannot easily be converted
>> into Mat4's, and Mat4's are full 3D transformation matrices, it makes sense
>> to provide full coverage in generating transformation matrices at the Mat4
>> level.
>
> I think we should provide an entry-point for creating 4x4 matrices from 3x3
> matrix and a 3D vector as the last vertical column:
>
> glmMatCompose (&out, &rotation, &translation);
>
> or something similar.

The problem there is that you have to create a mat3x3 just to create
the mat4x4 that you actually want. That seems wasteful and not
entirely obvious to the user.

More importantly, what about the other 3 floats in "out" that are not
being set by this?

I know it's a pain to add another version of all of those functions
(I've done it), but it really is the most obvious, simplest solution.

Re: [Glsdk-devel] Commentary on the math library

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

> The probleI wim there is that you have to create a mat3x3 just to create
> the mat4x4 that you actually want. That seems wasteful and not
> entirely obvious to the user.
>
> More importantly, what about the other 3 floats in "out" that are not
> being set by this?
>
> I know it's a pain to add another version of all of those functions
> (I've done it), but it really is the most obvious, simplest solution.
>

Yes. I think you are right. I will add the entry-points for creating 4x4
rotations etc.* at some point!*

Right now, I really would like to start writing the API ref.


>
> -------------------------------------------------------------------------
> 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] Commentary on the math library

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

On Thu, Aug 28, 2008 at 10:35 PM, Andrew Gajda <and...@gm...>wrote:

> Maybe it's been a while since I've done pure C (like with my function
> overloading example) but can someone tell me what the advantage might to
> doing:
> *someGLMfunc( GLMvec3f *out, blah, blah )
> {
>    GLMvef3 tmp;
>    ...
>    tmp.x = something;
> **   tmp.y = something;
> **   tmp.z = something;
>
>    *out = tmp;
>
>    return out;
> }*
>
> Why not just assign *out directly?
>

Consider for example what happens when the user calls like this:

glmMatMul2f (&mat, &mat, &mat);

Writing the result into a temporary value and then finally overwriting the
*out avoids the complications that would arise. And we decided to allow
(&mat, &mat, &mat) rather than marking it as "undefined behaviour".


>
>
> On Thu, Aug 28, 2008 at 12:52 PM, Henri Häkkinen <hen...@gm...>wrote:
>
>> On Thu, Aug 28, 2008 at 12:32 PM, Jason McKesson <ko...@gm...>wrote:
>>
>>> - We should have a series of Vec4 functions that treat their inputs as
>>> normalized quaternions. Basically quaternion multiplication, quaternion
>>> inverse, and a function to convert quaternions into rotation matrices.
>>> Enough to use quaternions. Oh, and a function to convert angle/axis into a
>>> quaternion (and one to go back?). I don't think we need a full-fledged
>>> quaternion type, as a 4-vector of floats is a 4-vector of floats; it's all
>>> in how you use it.
>>>
>>
>> I think we should implement full featured GLMquatf type.
>>
>>
>>> - Rename the parameters in the lerp functions. I have always had a
>>> problem with lerp functions in terms of figuring out which parameter I would
>>> get with an alpha of 0 and which I would get with an alpha of 1. So the idea
>>> is to have the lerp parameter names themselves specify which way it works.
>>> IE: "glmVecLerp3f (GLMvec3f *out, const GLMvec3f **v0*, const GLMvec3f *
>>> *v1*, GLfloat s);" It is much more apparent than if s==0.0f, you'll get
>>> v0, since it has a 0 in the name. Same goes with v1.
>>>
>>
>> Fine, this is a valid point. I will be renaming all argument names into
>> v0, v1 and m0, m1 for consistency at some point.
>>
>>
>>
>>> - The names of many of the matrix functions do not intuitively describe
>>> their results. Take the function "GLMmat3f *glmMatRotateX3f (GLMmat3f *out,
>>> GLfloat angle);" This can do one of two things. It can overwrite the
>>> contents of "out" with a rotation matrix about the X axis, or it can *
>>> multiply* the contents of out by that matrix. The latter would be the
>>> typical OpenGL style, but the former is what most math libraries would do.
>>> However, what about "GLMmat3f *glmMatTranslate3f (GLMmat3f *out, GLfloat x,
>>> GLfloat y);"? This is a function where it would make some sense for it to
>>> not overwrite the full contents of "out" (though an argument can be made
>>> that it should). Or at least, one would expect there to be a version of
>>> Translate3f that will only change the 2 positional coordinates of a
>>> transformation matrix.
>>>
>>> Honestly, I'm not sure what to do about it, or if we should do anything
>>> at all. If all of the functions have one specific kind of behavior
>>> (overwrite, say), then at least the library is consistent. It just feels
>>> weird to me to have a function like "glmMatTranslate3f" that completely
>>> overwrites the matrix rather than just setting certain fields.
>>>
>>
>> This matter needs to be considered. We should also write the API
>> references.
>>
>>
>>> - All of those Mat3 functions for generating transformation matrices? We
>>> should have Mat4 versions as well. Since Mat3's cannot easily be converted
>>> into Mat4's, and Mat4's are full 3D transformation matrices, it makes sense
>>> to provide full coverage in generating transformation matrices at the Mat4
>>> level.
>>>
>>
>> I think we should provide an entry-point for creating 4x4 matrices from
>> 3x3 matrix and a 3D vector as the last vertical column:
>>
>> glmMatCompose (&out, &rotation, &translation);
>>
>> or something similar.
>>
>>
>>> - BTW, is the math library going to provide a matrix stack, or is that
>>> something for a higher-level library?
>>>
>>
>> No idea at this point yet.
>>
>>
>>>
>>> -------------------------------------------------------------------------
>>> 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
>
>


-- 
Henri 'henux' Häkkinen

Re: [Glsdk-devel] Commentary on the math library

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

In creation functions that's safe.

In any functions that take a *in matrix, you have possible
memory-aliasing isues with pointers

Branan

On Thu, Aug 28, 2008 at 1:01 PM, Henri Häkkinen <hen...@gm...> wrote:
>
> On Thu, Aug 28, 2008 at 10:35 PM, Andrew Gajda <and...@gm...>
> wrote:
>>
>> Maybe it's been a while since I've done pure C (like with my function
>> overloading example) but can someone tell me what the advantage might to
>> doing:
>> someGLMfunc( GLMvec3f *out, blah, blah )
>> {
>>    GLMvef3 tmp;
>>    ...
>>    tmp.x = something;
>>    tmp.y = something;
>>    tmp.z = something;
>>
>>    *out = tmp;
>>
>>    return out;
>> }
>>
>> Why not just assign *out directly?
>
> Consider for example what happens when the user calls like this:
>
> glmMatMul2f (&mat, &mat, &mat);
>
> Writing the result into a temporary value and then finally overwriting the
> *out avoids the complications that would arise. And we decided to allow
> (&mat, &mat, &mat) rather than marking it as "undefined behaviour".
>
>>
>> On Thu, Aug 28, 2008 at 12:52 PM, Henri Häkkinen <hen...@gm...>
>> wrote:
>>>
>>> On Thu, Aug 28, 2008 at 12:32 PM, Jason McKesson <ko...@gm...>
>>> wrote:
>>>>
>>>> - We should have a series of Vec4 functions that treat their inputs as
>>>> normalized quaternions. Basically quaternion multiplication, quaternion
>>>> inverse, and a function to convert quaternions into rotation matrices.
>>>> Enough to use quaternions. Oh, and a function to convert angle/axis into a
>>>> quaternion (and one to go back?). I don't think we need a full-fledged
>>>> quaternion type, as a 4-vector of floats is a 4-vector of floats; it's all
>>>> in how you use it.
>>>
>>> I think we should implement full featured GLMquatf type.
>>>
>>>>
>>>> - Rename the parameters in the lerp functions. I have always had a
>>>> problem with lerp functions in terms of figuring out which parameter I would
>>>> get with an alpha of 0 and which I would get with an alpha of 1. So the idea
>>>> is to have the lerp parameter names themselves specify which way it works.
>>>> IE: "glmVecLerp3f (GLMvec3f *out, const GLMvec3f *v0, const GLMvec3f *v1,
>>>> GLfloat s);" It is much more apparent than if s==0.0f, you'll get v0, since
>>>> it has a 0 in the name. Same goes with v1.
>>>
>>> Fine, this is a valid point. I will be renaming all argument names into
>>> v0, v1 and m0, m1 for consistency at some point.
>>>
>>>
>>>>
>>>> - The names of many of the matrix functions do not intuitively describe
>>>> their results. Take the function "GLMmat3f *glmMatRotateX3f (GLMmat3f *out,
>>>> GLfloat angle);" This can do one of two things. It can overwrite the
>>>> contents of "out" with a rotation matrix about the X axis, or it can
>>>> multiply the contents of out by that matrix. The latter would be the typical
>>>> OpenGL style, but the former is what most math libraries would do. However,
>>>> what about "GLMmat3f *glmMatTranslate3f (GLMmat3f *out, GLfloat x, GLfloat
>>>> y);"? This is a function where it would make some sense for it to not
>>>> overwrite the full contents of "out" (though an argument can be made that it
>>>> should). Or at least, one would expect there to be a version of Translate3f
>>>> that will only change the 2 positional coordinates of a transformation
>>>> matrix.
>>>>
>>>> Honestly, I'm not sure what to do about it, or if we should do anything
>>>> at all. If all of the functions have one specific kind of behavior
>>>> (overwrite, say), then at least the library is consistent. It just feels
>>>> weird to me to have a function like "glmMatTranslate3f" that completely
>>>> overwrites the matrix rather than just setting certain fields.
>>>
>>> This matter needs to be considered. We should also write the API
>>> references.
>>>
>>>>
>>>> - All of those Mat3 functions for generating transformation matrices? We
>>>> should have Mat4 versions as well. Since Mat3's cannot easily be converted
>>>> into Mat4's, and Mat4's are full 3D transformation matrices, it makes sense
>>>> to provide full coverage in generating transformation matrices at the Mat4
>>>> level.
>>>
>>> I think we should provide an entry-point for creating 4x4 matrices from
>>> 3x3 matrix and a 3D vector as the last vertical column:
>>>
>>> glmMatCompose (&out, &rotation, &translation);
>>>
>>> or something similar.
>>>
>>>>
>>>> - BTW, is the math library going to provide a matrix stack, or is that
>>>> something for a higher-level library?
>>>
>>> No idea at this point yet.
>>>
>>>>
>>>>
>>>> -------------------------------------------------------------------------
>>>> 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
>>
>
>
>
> --
> 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] Commentary on the math library

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

Gotcha.  Thanks.

On Thu, Aug 28, 2008 at 4:04 PM, Branan Riley <br...@gm...> wrote:

> In creation functions that's safe.
>
> In any functions that take a *in matrix, you have possible
> memory-aliasing isues with pointers
>
> Branan
>
> On Thu, Aug 28, 2008 at 1:01 PM, Henri Häkkinen <hen...@gm...>
> wrote:
> >
> > On Thu, Aug 28, 2008 at 10:35 PM, Andrew Gajda <and...@gm...>
> > wrote:
> >>
> >> Maybe it's been a while since I've done pure C (like with my function
> >> overloading example) but can someone tell me what the advantage might to
> >> doing:
> >> someGLMfunc( GLMvec3f *out, blah, blah )
> >> {
> >>    GLMvef3 tmp;
> >>    ...
> >>    tmp.x = something;
> >>    tmp.y = something;
> >>    tmp.z = something;
> >>
> >>    *out = tmp;
> >>
> >>    return out;
> >> }
> >>
> >> Why not just assign *out directly?
> >
> > Consider for example what happens when the user calls like this:
> >
> > glmMatMul2f (&mat, &mat, &mat);
> >
> > Writing the result into a temporary value and then finally overwriting
> the
> > *out avoids the complications that would arise. And we decided to allow
> > (&mat, &mat, &mat) rather than marking it as "undefined behaviour".
> >
> >>
> >> On Thu, Aug 28, 2008 at 12:52 PM, Henri Häkkinen <hen...@gm...>
> >> wrote:
> >>>
> >>> On Thu, Aug 28, 2008 at 12:32 PM, Jason McKesson <ko...@gm...>
> >>> wrote:
> >>>>
> >>>> - We should have a series of Vec4 functions that treat their inputs as
> >>>> normalized quaternions. Basically quaternion multiplication,
> quaternion
> >>>> inverse, and a function to convert quaternions into rotation matrices.
> >>>> Enough to use quaternions. Oh, and a function to convert angle/axis
> into a
> >>>> quaternion (and one to go back?). I don't think we need a full-fledged
> >>>> quaternion type, as a 4-vector of floats is a 4-vector of floats; it's
> all
> >>>> in how you use it.
> >>>
> >>> I think we should implement full featured GLMquatf type.
> >>>
> >>>>
> >>>> - Rename the parameters in the lerp functions. I have always had a
> >>>> problem with lerp functions in terms of figuring out which parameter I
> would
> >>>> get with an alpha of 0 and which I would get with an alpha of 1. So
> the idea
> >>>> is to have the lerp parameter names themselves specify which way it
> works.
> >>>> IE: "glmVecLerp3f (GLMvec3f *out, const GLMvec3f *v0, const GLMvec3f
> *v1,
> >>>> GLfloat s);" It is much more apparent than if s==0.0f, you'll get v0,
> since
> >>>> it has a 0 in the name. Same goes with v1.
> >>>
> >>> Fine, this is a valid point. I will be renaming all argument names into
> >>> v0, v1 and m0, m1 for consistency at some point.
> >>>
> >>>
> >>>>
> >>>> - The names of many of the matrix functions do not intuitively
> describe
> >>>> their results. Take the function "GLMmat3f *glmMatRotateX3f (GLMmat3f
> *out,
> >>>> GLfloat angle);" This can do one of two things. It can overwrite the
> >>>> contents of "out" with a rotation matrix about the X axis, or it can
> >>>> multiply the contents of out by that matrix. The latter would be the
> typical
> >>>> OpenGL style, but the former is what most math libraries would do.
> However,
> >>>> what about "GLMmat3f *glmMatTranslate3f (GLMmat3f *out, GLfloat x,
> GLfloat
> >>>> y);"? This is a function where it would make some sense for it to not
> >>>> overwrite the full contents of "out" (though an argument can be made
> that it
> >>>> should). Or at least, one would expect there to be a version of
> Translate3f
> >>>> that will only change the 2 positional coordinates of a transformation
> >>>> matrix.
> >>>>
> >>>> Honestly, I'm not sure what to do about it, or if we should do
> anything
> >>>> at all. If all of the functions have one specific kind of behavior
> >>>> (overwrite, say), then at least the library is consistent. It just
> feels
> >>>> weird to me to have a function like "glmMatTranslate3f" that
> completely
> >>>> overwrites the matrix rather than just setting certain fields.
> >>>
> >>> This matter needs to be considered. We should also write the API
> >>> references.
> >>>
> >>>>
> >>>> - All of those Mat3 functions for generating transformation matrices?
> We
> >>>> should have Mat4 versions as well. Since Mat3's cannot easily be
> converted
> >>>> into Mat4's, and Mat4's are full 3D transformation matrices, it makes
> sense
> >>>> to provide full coverage in generating transformation matrices at the
> Mat4
> >>>> level.
> >>>
> >>> I think we should provide an entry-point for creating 4x4 matrices from
> >>> 3x3 matrix and a 3D vector as the last vertical column:
> >>>
> >>> glmMatCompose (&out, &rotation, &translation);
> >>>
> >>> or something similar.
> >>>
> >>>>
> >>>> - BTW, is the math library going to provide a matrix stack, or is that
> >>>> something for a higher-level library?
> >>>
> >>> No idea at this point yet.
> >>>
> >>>>
> >>>>
> >>>>
> -------------------------------------------------------------------------
> >>>> 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
> >>
> >
> >
> >
> > --
> > 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
>