From: Andrew G. <and...@gm...> - 2008-08-28 20:11:04
|
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 > |