ggt-devel — Development discussion list

[ggt-devel] [ ggt-Feature Requests-562028 ] More quaternion generators

[<no...@so...>]

Feature Requests item #562028, was opened at 2002-05-29 14:46
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=437250&aid=562028&group_id=43735

Category: None
Group: None
>Status: Pending
>Resolution: Fixed
Priority: 5
Submitted By: Justin Hare (jahare)
>Assigned to: Allen Bierbaum (allenb)
Summary: More quaternion generators

Initial Comment:
Would like to be able to make a quaternion directly
from a matrix and also from Euler angles.

Examples:

gmtl::Quatf myquat;
myquat = gmtl::makeRot<gmtl::Quatf>( my_matrix );

myquat = gmtl::makeRot<gmtl::Quatf>( x, y, z, gmtl::XYZ );

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

>Comment By: Kevin Meinert (subatomic)
Date: 2002-06-13 20:06

Message:
Logged In: YES 
user_id=49859

this works now.  see the generic makeRot that is templated
on srctype and return type, and basically calls setRot with
them.

if setRot is defined (which it is for quat/matrix, and
quat/axisangle, and quat/euler) then makeRot will
automatically use those... :)

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=437250&aid=562028&group_id=43735

[ggt-devel] [Task #55418] Make GMTL_VERSION non-octal.

[<no...@so...>]

Task #55418 has been updated. 

Project: Generic Graphics Toolkit
Subproject: GMTL
Summary: Make GMTL_VERSION non-octal.
Complete: 0%
Status: Open
Authority  : nonchocoboy
Assigned to: nonchocoboy

Description: Once GMTL gets versioned to 1.x.x, stop doing the zero left fill of the major version so that GMTL_VERSION is no longer defined as an octal number.

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/pm/task.php?func=detailtask&project_task_id=55418&group_id=43735&group_project_id=16299

[ggt-devel] [Task #55364] Add Version Info

[<no...@so...>]

Task #55364 has been updated. 

Project: Generic Graphics Toolkit
Subproject: GMTL
Summary: Add Version Info
Complete: 100%
Status: Closed
Authority  : nonchocoboy
Assigned to: nonchocoboy

Description: We need some way to provide versioning information to developers. Implementation options include the way Boost does it with one macro or how Vapor does it with 3 macros.

Follow-Ups:

-------------------------------------------------------
Date: 2002-06-03 19:13
By: nonchocoboy

Comment:
Version.h added with the following members:
- GMTL_VERSION defined as <major><minor><patch> with each part having exactly 3 digits.
- const char* gmtl::version is set to the string "<major><minor><patch>" with each part having anywhere from 1 to 3 digits.

So if GMTL is at version 1.10.299, you would effectively have ...
#define GMTL_VERSION 001010299
const char* gmtl::version = "1.10.299"


-------------------------------------------------------
Date: 2002-06-03 15:42
By: nonchocoboy

Comment:
Correction:
Boost defines a version string that that requires math operations on it to get the version parts. Vapor defines a version string as major.minor.micro.

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/pm/task.php?func=detailtask&project_task_id=55364&group_id=43735&group_project_id=16299

[ggt-devel] [Task #55364] Add Version Info

[<no...@so...>]

Task #55364 has been updated. 

Project: Generic Graphics Toolkit
Subproject: GMTL
Summary: Add Version Info
Complete: 0%
Status: Open
Authority  : nonchocoboy
Assigned to: nonchocoboy

Description: We need some way to provide versioning information to developers. Implementation options include the way Boost does it with one macro or how Vapor does it with 3 macros.

Follow-Ups:

-------------------------------------------------------
Date: 2002-06-03 15:42
By: nonchocoboy

Comment:
Correction:
Boost defines a version string that that requires math operations on it to get the version parts. Vapor defines a version string as major.minor.micro.

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/pm/task.php?func=detailtask&project_task_id=55364&group_id=43735&group_project_id=16299

[ggt-devel] [Task #55364] Add Version Info

[<no...@so...>]

Task #55364 has been updated. 

Project: Generic Graphics Toolkit
Subproject: GMTL
Summary: Add Version Info
Complete: 0%
Status: Open
Authority  : nonchocoboy
Assigned to: nonchocoboy

Description: We need some way to provide versioning information to developers. Implementation options include the way Boost does it with one macro or how Vapor does it with 3 macros.

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/pm/task.php?func=detailtask&project_task_id=55364&group_id=43735&group_project_id=16299

Re: [ggt-devel] meeting notes GMTL

[Kevin M. <ke...@vr...>]

how is a point one?  it is geometry.  but you do math on geometry..
so you do math on color too...  light/color is very mathematical...

the only reason not to, is if we wanted a geom extension lib to gmtl, then 
we'd put color texture, light, material, etc  in there....

which would be very logical extension...

kevin

On Fri, 31 May 2002, Ben Scott wrote:

> How is color a math construct? I understand that it would be easily 
> implemented as a natural extension to VecBase, but I'm not sure it would 
> rightly belong with the rest of GMTL. Am I missing some deep connection?
> 
> cheers,
> -----
> Ben Scott
> Research Assistant VRAC
> bs...@ia...
> 
> 
> On Fri, 31 May 2002, Kevin Meinert wrote:
> 
> > 
> > to summarize our meeting, we have a few tasks in gmtl to do:
> > 
> > Definately:
> > - replace all gets with sets
> > - write one templated get that uses set.
> >   get mirrors set, does not return out the back.
> > - rename all convert to set
> > 
> > Maybe:
> > - new types:
> >   o EulerParam (rad, x, y, z)
> >   o EulerAngle( p0, p1, p2 ) stores the Rotation order within
> > - rewrite all sets and makes to only take two params.
> > 
> > the reason for maybe is that some funcs will always need to take more than 
> > two...  for example, generate a ray from a point and a vec, generate a 
> > matrix or quat (rotation) from two vecs, generate a line seg from two 
> > points, etc....
> > 
> > I still think EulerParam and EulerAngle might be nice to have, it would 
> > allow a nice neet set function for each to matrix or quat...
> > 
> > 
> > 
> > completly different topic.
> > not now, but in the future I'd like to see color class.  I could add that 
> > easily, I have HSV/RGB code in my old lib i could port.  Color would 
> > probably be a VecBase so you could do all the operations like +- etc...
> > 
> > 
> > 
> 

-- 
*--*---*---*----*-----*------*------*-----*----*---*---*--*
Kevin Meinert                         /_/                  
http://www.vrac.iastate.edu/~kevn               \        / 
Virtual Reality Applications Center            \/  __    \/
Howe Hall, Iowa State University, Ames Iowa        \__     
                                            \_\            

Re: [ggt-devel] meeting notes GMTL

[Ben S. <bs...@vr...>]

How is color a math construct? I understand that it would be easily 
implemented as a natural extension to VecBase, but I'm not sure it would 
rightly belong with the rest of GMTL. Am I missing some deep connection?

cheers,
-----
Ben Scott
Research Assistant VRAC
bs...@ia...


On Fri, 31 May 2002, Kevin Meinert wrote:

> 
> to summarize our meeting, we have a few tasks in gmtl to do:
> 
> Definately:
> - replace all gets with sets
> - write one templated get that uses set.
>   get mirrors set, does not return out the back.
> - rename all convert to set
> 
> Maybe:
> - new types:
>   o EulerParam (rad, x, y, z)
>   o EulerAngle( p0, p1, p2 ) stores the Rotation order within
> - rewrite all sets and makes to only take two params.
> 
> the reason for maybe is that some funcs will always need to take more than 
> two...  for example, generate a ray from a point and a vec, generate a 
> matrix or quat (rotation) from two vecs, generate a line seg from two 
> points, etc....
> 
> I still think EulerParam and EulerAngle might be nice to have, it would 
> allow a nice neet set function for each to matrix or quat...
> 
> 
> 
> completly different topic.
> not now, but in the future I'd like to see color class.  I could add that 
> easily, I have HSV/RGB code in my old lib i could port.  Color would 
> probably be a VecBase so you could do all the operations like +- etc...
> 
> 
> 

[ggt-devel] meeting notes GMTL

[Kevin M. <ke...@vr...>]

to summarize our meeting, we have a few tasks in gmtl to do:

Definately:
- replace all gets with sets
- write one templated get that uses set.
  get mirrors set, does not return out the back.
- rename all convert to set

Maybe:
- new types:
  o EulerParam (rad, x, y, z)
  o EulerAngle( p0, p1, p2 ) stores the Rotation order within
- rewrite all sets and makes to only take two params.

the reason for maybe is that some funcs will always need to take more than 
two...  for example, generate a ray from a point and a vec, generate a 
matrix or quat (rotation) from two vecs, generate a line seg from two 
points, etc....

I still think EulerParam and EulerAngle might be nice to have, it would 
allow a nice neet set function for each to matrix or quat...



completly different topic.
not now, but in the future I'd like to see color class.  I could add that 
easily, I have HSV/RGB code in my old lib i could port.  Color would 
probably be a VecBase so you could do all the operations like +- etc...


-- 
*--*---*---*----*-----*------*------*-----*----*---*---*--*
Kevin Meinert                         /_/                  
http://www.vrac.iastate.edu/~kevn               \        / 
Virtual Reality Applications Center            \/  __    \/
Howe Hall, Iowa State University, Ames Iowa        \__     
                                            \_\            

Re: [ggt-devel] another potential usability issue from naming

[Kevin M. <ke...@vr...>]

> 
> And I'm suggesting that we don't make that requirement. I'm saying that 
> anything that's manipulating a property on an object should be set/get. 

good idea for usability, bad idea for maintainance/implementation.  that 
is why we chose not to do it that way, because we'd be maintaining all 
these duplicate make and get functions... :(

it also keeps all function template stuff in the make functions.  keeps 
the interface consistant.

the only solution to what you're wanting (i think) is to kill off all the 
make functions, and rename them to get...   Do we want that?

> ie.
> 
> Matrix4ff mat;
> Vec3f v;
> setTrans(mat, v);
> v = getTrans(mat);
> getTrans(mat, v);
> 
> I would prefer using "get" to having to use "make" for the middle 
> function since this is a common idiom that I and I hope (could be wrong 
> though) most OO programmers are familiar with. I guess I don't see why we 
> should create our own idiom just because we happen to be doing OO in C 
> rather than C++. To me, the language doesn't matter when it comes to 
> naming.
> 
> > 
> > since you wanted it out the back as temporary, then it is make.  I can't 
> > remember what the original issue is anymore.  Does this clear it up?
> 
> I understand how GMTL is currently implemented. Completely clear on that! 
> I realize that currently if i want something out the back of a function I 
> have to use a "make" function. My issue is that I don't feel that this is 
> a good naming convention for the reasons listed before and am trying to 
> show you guys as to why. 

so you want get/set, with no make funcs?  is there a good time at all to 
name something make?

> All I seem to get back from you is a description 
> of how it is currently implemented and that I should use that. Perhaps you 
> could give me a reason as to why it should be implemented that way.

i have.  it is constructor based.  this is why it is implemented that way.  
make is the name we chose to represent a copy constructor.  I've said it 
many times.

you (i think) are proposing to call the copy constructor "get"...

> 
> > 
> > just write a set( vec, mat ) and a set (mat, vec), and you'll be golden.
> > if you need a constructor, use "make"...  
> > 
> > The only way to have constructors in C, or the only way to decouple 
> > constructors from C++ objects is to have "make" functions.  Is it the 
> > naming you don't like?  I don't see the problem I guess...
> 
> We're not really doing C. We're doing C++ and we DO have constructors. In 
> no way does a "make" function decouple the constructor from the object.

it does IMHO...  we've decoupled constructors, and that is the philosophy 
behind the make functions. 

> 
> > 
> > kevin
> > 
> > 
> > _______________________________________________________________
> > 
> > Don't miss the 2002 Sprint PCS Application Developer's Conference
> > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
> > 
> > _______________________________________________
> > ggt-devel mailing list
> > ggt...@li...
> > https://lists.sourceforge.net/lists/listinfo/ggt-devel
> > 
> 
> cheers, 
> -----
> Ben Scott
> Research Assistant VRAC
> bs...@ia...
> 

-- 
*--*---*---*----*-----*------*------*-----*----*---*---*--*
Kevin Meinert                         /_/                  
http://www.vrac.iastate.edu/~kevn               \        / 
Virtual Reality Applications Center            \/  __    \/
Howe Hall, Iowa State University, Ames Iowa        \__     
                                            \_\            

Re: [ggt-devel] another potential usability issue from naming

[Ben S. <bs...@vr...>]

On Thu, 30 May 2002, Kevin Meinert wrote:

> > 
> > Not a book, but experience. When an object has a property, do you write a 
> > set/make method pair to manipulate it or a set/get pair? What does the 
> > industry standard tell you? What does any UML tool use while reverse 
> > engineering a diagram from the code to determine an object's properties?
> > 
> 
> might need a get for retrieval.  but we know all gets are actually sets... 
> :)

But only as a (sometimes nasty) side-effect.

> 
> and we also know the gets and sets don't return out the back (just because 
> of how we chose to implement - object oriented C).

And I'm suggesting that we don't make that requirement. I'm saying that 
anything that's manipulating a property on an object should be set/get. 
ie.

Matrix4ff mat;
Vec3f v;
setTrans(mat, v);
v = getTrans(mat);
getTrans(mat, v);

I would prefer using "get" to having to use "make" for the middle 
function since this is a common idiom that I and I hope (could be wrong 
though) most OO programmers are familiar with. I guess I don't see why we 
should create our own idiom just because we happen to be doing OO in C 
rather than C++. To me, the language doesn't matter when it comes to 
naming.

> 
> since you wanted it out the back as temporary, then it is make.  I can't 
> remember what the original issue is anymore.  Does this clear it up?

I understand how GMTL is currently implemented. Completely clear on that! 
I realize that currently if i want something out the back of a function I 
have to use a "make" function. My issue is that I don't feel that this is 
a good naming convention for the reasons listed before and am trying to 
show you guys as to why. All I seem to get back from you is a description 
of how it is currently implemented and that I should use that. Perhaps you 
could give me a reason as to why it should be implemented that way.

> 
> just write a set( vec, mat ) and a set (mat, vec), and you'll be golden.
> if you need a constructor, use "make"...  
> 
> The only way to have constructors in C, or the only way to decouple 
> constructors from C++ objects is to have "make" functions.  Is it the 
> naming you don't like?  I don't see the problem I guess...

We're not really doing C. We're doing C++ and we DO have constructors. In 
no way does a "make" function decouple the constructor from the object.

> 
> kevin
> 
> 
> _______________________________________________________________
> 
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
> 
> _______________________________________________
> ggt-devel mailing list
> ggt...@li...
> https://lists.sourceforge.net/lists/listinfo/ggt-devel
> 

cheers, 
-----
Ben Scott
Research Assistant VRAC
bs...@ia...

Re: [ggt-devel] another potential usability issue from naming

[Kevin M. <ke...@vr...>]

> 
> Not a book, but experience. When an object has a property, do you write a 
> set/make method pair to manipulate it or a set/get pair? What does the 
> industry standard tell you? What does any UML tool use while reverse 
> engineering a diagram from the code to determine an object's properties?
> 

might need a get for retrieval.  but we know all gets are actually sets... 
:)

and we also know the gets and sets don't return out the back (just because 
of how we chose to implement - object oriented C).

since you wanted it out the back as temporary, then it is make.  I can't 
remember what the original issue is anymore.  Does this clear it up?

just write a set( vec, mat ) and a set (mat, vec), and you'll be golden.
if you need a constructor, use "make"...  

The only way to have constructors in C, or the only way to decouple 
constructors from C++ objects is to have "make" functions.  Is it the 
naming you don't like?  I don't see the problem I guess...

kevin

Re: [ggt-devel] another potential usability issue from naming

[Ben S. <bs...@vr...>]

On Thu, 30 May 2002, Kevin Meinert wrote:

> > I think that the translational aspect of a matrix is A PROPERTY OF THAT 
> > MATRIX. 
> 
> maybe this is your problem?  :)  actually it is a property, but how does 
> this matter?  You're using that property of the matrix to initialize a 
> newly created item returned by the "make" function.  right?

It matters because I don't create properties of other objects, I ask 
for/retrieve them. Ignore what a "make" function is in GMTL and think 
about it. Do you really want to create a new translation vector or 
retrieve information about the matrix you have?

> 
> > That property is generally considered as being the fourth column 
> > vector that makes up that matrix. Thus when I wish to retrieve the 
> > translation of a matrix I don't consider it creational, because IT ALREADY
> > EXISTS as a part of the matrix.
> 
> it is creational.  2 tip offs to the fact:
> - a clone operation is creation.  

Agreed.

> - the other tip off is that we're returning a temporary.  
>   by definition, that is creational.

But only as a consequence that the data structure required to pass on that 
information requires a Vec as a vessel for the data. I would say that 
creating a temporary object does make make a function creational since the 
intent is not to create the object and keep it around but to retrieve some 
data from an object which requires a temporary to transfer the data 
required by the language's syntax.

> 
> > Now, consider this; we happened to implement our matrix as 16 floating 
> > point values. Thus to get the translation of a matrix, we must create a 
> > temporary vector to store those values in. What if instead we implemented 
> > the matrix as 4 column vectors? Then retrieving the translation from the 
> > matrix is no longer causes the construction of a new vector since just a 
> > reference to the fourth column vector would be returned. In that case, the 
> > function IS NOT CREATIONAL.
> 
> but we dont implement it that way... and yes it would still be creational 
> (it is a clone, copy constructor, etc...)...

EXACTLY! We call it makeXX because the syntax shows that we are returning 
a temporary rather than noticing that the semantics of the function 
dictate that it is really returning a distinct property of the object.

> 
> > See, I think that the naming conventions used in GMTL are based on 
> > syntactic reasons rather than semantic reasons that may cause some 
> > interesting learning and usability problems since it goes against common 
> > Object Oriented design idioms.
> 
> I don't agree...  what book have you been reading?

Not a book, but experience. When an object has a property, do you write a 
set/make method pair to manipulate it or a set/get pair? What does the 
industry standard tell you? What does any UML tool use while reverse 
engineering a diagram from the code to determine an object's properties?

[snip]

cheers,
-----
Ben Scott
Research Assistant VRAC
bs...@ia...

Re: [ggt-devel] another potential usability issue from naming

[Ben S. <bs...@vr...>]

I guess I'm not making my arguments clear (a common problem with me). :(

I think that the translational aspect of a matrix is A PROPERTY OF THAT 
MATRIX. That property is generally considered as being the fourth column 
vector that makes up that matrix. Thus when I wish to retrieve the 
translation of a matrix I don't consider it creational, because IT ALREADY
EXISTS as a part of the matrix.

Now, consider this; we happened to implement our matrix as 16 floating 
point values. Thus to get the translation of a matrix, we must create a 
temporary vector to store those values in. What if instead we implemented 
the matrix as 4 column vectors? Then retrieving the translation from the 
matrix is no longer causes the construction of a new vector since just a 
reference to the fourth column vector would be returned. In that case, the 
function IS NOT CREATIONAL.

See, I think that the naming conventions used in GMTL are based on 
syntactic reasons rather than semantic reasons that may cause some 
interesting learning and usability problems since it goes against common 
Object Oriented design idioms.

cheers,
-----
Ben Scott
Research Assistant VRAC
bs...@ia...


On Wed, 29 May 2002, Allen Bierbaum wrote:

> Unless I am missing something, I would say they are both creational. 
> Both methods create a temporary object that is returned by value.  The
> only real difference is that in one the thing going in (vec) is smaller
> then the thing coming out (Matrix) while the other method takes
> something larger in and spits out something smaller.  In every other way
> the semantics are the same from what I can tell.
> 
> Is there something I am missing?
> 
> -Allen
> 
> Ben Scott wrote:
> > 
> > The semantics are different because makeTrans<Matrix>(Vec) is purely
> > creational whereas makeTrans<Vec>(Matrix) is a retrieval function.
> > makeTrans<Vec>(Matrix) is creational only as a byproduct of the fact that
> > the data it needs to return must be in vector form.
> > 
> > -----
> > Ben Scott
> > Research Assistant VRAC
> > bs...@ia...
> > 
> > On Wed, 29 May 2002, Kevin Meinert wrote:
> > 
> > >
> > > the semantics of all make functions are that they take input data, and
> > > create something.
> > >
> > > the beauty of it is that you can insert arbitrary data (usually as long as
> > > we implement the funcs)
> > >
> > > > Matrix makeTrans<Matrix>(Vec)
> > > > Vec makeTrans<Vec>(Matrix)
> > >
> > > and even
> > > Matrix makeTrans<Matrix>(Matrix)
> > >
> > > are all ways to get data types from others.  I guess I don't see how this
> > > breaks any semantics.  The make functions are still object oriented in the
> > > sense that they are factories, or constructors of objects.
> > >
> > > as soon as you understand this point, they should be usable.
> > >
> > > does that clear it up?
> > >
> > >
> > > kevin
> > >
> > >
> > > _______________________________________________________________
> > >
> > > Don't miss the 2002 Sprint PCS Application Developer's Conference
> > > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
> > >
> > > _______________________________________________
> > > ggt-devel mailing list
> > > ggt...@li...
> > > https://lists.sourceforge.net/lists/listinfo/ggt-devel
> > >
> > 
> > _______________________________________________________________
> > 
> > Don't miss the 2002 Sprint PCS Application Developer's Conference
> > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
> > 
> > _______________________________________________
> > ggt-devel mailing list
> > ggt...@li...
> > https://lists.sourceforge.net/lists/listinfo/ggt-devel
> 
> -- Allen Bierbaum                         al...@vr...
> -- PhD Candidate             txtmsg - 515...@us...
> -- VR Juggler Team                       http://www.vrjuggler.org
> -- Virtual Reality Applications Lab   http://www.vrac.iastate.edu
> 
> _______________________________________________________________
> 
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
> 
> _______________________________________________
> ggt-devel mailing list
> ggt...@li...
> https://lists.sourceforge.net/lists/listinfo/ggt-devel
> 

Re: [ggt-devel] another potential usability issue from naming

[Allen B. <al...@vr...>]

Unless I am missing something, I would say they are both creational. 
Both methods create a temporary object that is returned by value.  The
only real difference is that in one the thing going in (vec) is smaller
then the thing coming out (Matrix) while the other method takes
something larger in and spits out something smaller.  In every other way
the semantics are the same from what I can tell.

Is there something I am missing?

-Allen

Ben Scott wrote:
> 
> The semantics are different because makeTrans<Matrix>(Vec) is purely
> creational whereas makeTrans<Vec>(Matrix) is a retrieval function.
> makeTrans<Vec>(Matrix) is creational only as a byproduct of the fact that
> the data it needs to return must be in vector form.
> 
> -----
> Ben Scott
> Research Assistant VRAC
> bs...@ia...
> 
> On Wed, 29 May 2002, Kevin Meinert wrote:
> 
> >
> > the semantics of all make functions are that they take input data, and
> > create something.
> >
> > the beauty of it is that you can insert arbitrary data (usually as long as
> > we implement the funcs)
> >
> > > Matrix makeTrans<Matrix>(Vec)
> > > Vec makeTrans<Vec>(Matrix)
> >
> > and even
> > Matrix makeTrans<Matrix>(Matrix)
> >
> > are all ways to get data types from others.  I guess I don't see how this
> > breaks any semantics.  The make functions are still object oriented in the
> > sense that they are factories, or constructors of objects.
> >
> > as soon as you understand this point, they should be usable.
> >
> > does that clear it up?
> >
> >
> > kevin
> >
> >
> > _______________________________________________________________
> >
> > Don't miss the 2002 Sprint PCS Application Developer's Conference
> > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
> >
> > _______________________________________________
> > ggt-devel mailing list
> > ggt...@li...
> > https://lists.sourceforge.net/lists/listinfo/ggt-devel
> >
> 
> _______________________________________________________________
> 
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
> 
> _______________________________________________
> ggt-devel mailing list
> ggt...@li...
> https://lists.sourceforge.net/lists/listinfo/ggt-devel

-- Allen Bierbaum                         al...@vr...
-- PhD Candidate             txtmsg - 515...@us...
-- VR Juggler Team                       http://www.vrjuggler.org
-- Virtual Reality Applications Lab   http://www.vrac.iastate.edu

Re: [ggt-devel] another potential usability issue from naming

[Kevin M. <ke...@vr...>]

I don't agree.  they are both creational.  each takes data as input to
seed that creation.

*--*---*---*----*-----*------*------*-----*----*---*---*--*
Kevin Meinert                         /_/
http://www.vrac.iastate.edu/~kevn               \        /
Virtual Reality Applications Center            \/  __    \/
Howe Hall, Iowa State University, Ames Iowa        \__
                                            \_\

On Wed, 29 May 2002, Ben Scott wrote:

> The semantics are different because makeTrans<Matrix>(Vec) is purely
> creational whereas makeTrans<Vec>(Matrix) is a retrieval function.
> makeTrans<Vec>(Matrix) is creational only as a byproduct of the fact that
> the data it needs to return must be in vector form.
>
> -----
> Ben Scott
> Research Assistant VRAC
> bs...@ia...
>
> On Wed, 29 May 2002, Kevin Meinert wrote:
>
> >
> > the semantics of all make functions are that they take input data, and
> > create something.
> >
> > the beauty of it is that you can insert arbitrary data (usually as long as
> > we implement the funcs)
> >
> > > Matrix makeTrans<Matrix>(Vec)
> > > Vec makeTrans<Vec>(Matrix)
> >
> > and even
> > Matrix makeTrans<Matrix>(Matrix)
> >
> > are all ways to get data types from others.  I guess I don't see how this
> > breaks any semantics.  The make functions are still object oriented in the
> > sense that they are factories, or constructors of objects.
> >
> > as soon as you understand this point, they should be usable.
> >
> > does that clear it up?
> >
> >
> > kevin
> >
> >
> > _______________________________________________________________
> >
> > Don't miss the 2002 Sprint PCS Application Developer's Conference
> > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
> >
> > _______________________________________________
> > ggt-devel mailing list
> > ggt...@li...
> > https://lists.sourceforge.net/lists/listinfo/ggt-devel
> >
>

Re: [ggt-devel] another potential usability issue from naming

[Ben S. <bs...@vr...>]

The semantics are different because makeTrans<Matrix>(Vec) is purely
creational whereas makeTrans<Vec>(Matrix) is a retrieval function.
makeTrans<Vec>(Matrix) is creational only as a byproduct of the fact that
the data it needs to return must be in vector form.

-----
Ben Scott
Research Assistant VRAC
bs...@ia...

On Wed, 29 May 2002, Kevin Meinert wrote:

>
> the semantics of all make functions are that they take input data, and
> create something.
>
> the beauty of it is that you can insert arbitrary data (usually as long as
> we implement the funcs)
>
> > Matrix makeTrans<Matrix>(Vec)
> > Vec makeTrans<Vec>(Matrix)
>
> and even
> Matrix makeTrans<Matrix>(Matrix)
>
> are all ways to get data types from others.  I guess I don't see how this
> breaks any semantics.  The make functions are still object oriented in the
> sense that they are factories, or constructors of objects.
>
> as soon as you understand this point, they should be usable.
>
> does that clear it up?
>
>
> kevin
>
>
> _______________________________________________________________
>
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
>
> _______________________________________________
> ggt-devel mailing list
> ggt...@li...
> https://lists.sourceforge.net/lists/listinfo/ggt-devel
>

Re: [ggt-devel] another potential usability issue from naming

[Allen B. <al...@vr...>]

Ben Scott wrote:
> 
> Soon makeTrans will be overloaded to support 2 functions with different
> semantics. The first,

What is different about the semantics.  The function does the same thing
"makes a translation <thing>", it just work on different parameters.

-Allen
 
> Matrix makeTrans<Matrix>(Vec)
> 
> will create a new matrix containing the translation transformation
> described by the given Vec. The second,
> 
> Vec makeTrans<Vec>(Matrix)
> 
> will create a new vector describing the translation transformation
> embedded in the given Matrix.
> 
> To me, functions with the same name but having different semantics goes
> against the grain for standard object oriented training and experience and
> will make usability much more difficult. Especially thinking of the
> upcoming transition of VRAC personnel to using VRJuggler 1.1 and GMTL, I
> believe issues like this will cause the greatest problems.
> 
> Kevin, I know you might feel like I'm rehashing our discussion earlier,
> but this particular situation is different than our discussions about the
> difference between getTrans and makeTrans.
> 
> I would love to hear your thoughts on my comments.
> 
> cheers,
> -----
> Ben Scott
> Research Assistant VRAC
> bs...@ia...
> 
> _______________________________________________________________
> 
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
> 
> _______________________________________________
> ggt-devel mailing list
> ggt...@li...
> https://lists.sourceforge.net/lists/listinfo/ggt-devel

-- Allen Bierbaum                          al...@vr... --
-- PhD Candidate              txtmsg - 515...@us... --
-- VR Juggler Team                        http://www.vrjuggler.org --
-- Virtual Reality Applications Lab    http://www.vrac.iastate.edu --
-- Iowa State University                    http://www.iastate.edu --

Re: [ggt-devel] another potential usability issue from naming

[Kevin M. <ke...@vr...>]

the semantics of all make functions are that they take input data, and 
create something.

the beauty of it is that you can insert arbitrary data (usually as long as 
we implement the funcs)

> Matrix makeTrans<Matrix>(Vec)
> Vec makeTrans<Vec>(Matrix)

and even 
Matrix makeTrans<Matrix>(Matrix)

are all ways to get data types from others.  I guess I don't see how this 
breaks any semantics.  The make functions are still object oriented in the 
sense that they are factories, or constructors of objects.

as soon as you understand this point, they should be usable.

does that clear it up?


kevin

[ggt-devel] another potential usability issue from naming

[Ben S. <bs...@vr...>]

Soon makeTrans will be overloaded to support 2 functions with different 
semantics. The first,

Matrix makeTrans<Matrix>(Vec)

will create a new matrix containing the translation transformation 
described by the given Vec. The second,

Vec makeTrans<Vec>(Matrix)

will create a new vector describing the translation transformation 
embedded in the given Matrix.

To me, functions with the same name but having different semantics goes 
against the grain for standard object oriented training and experience and 
will make usability much more difficult. Especially thinking of the 
upcoming transition of VRAC personnel to using VRJuggler 1.1 and GMTL, I 
believe issues like this will cause the greatest problems.

Kevin, I know you might feel like I'm rehashing our discussion earlier, 
but this particular situation is different than our discussions about the 
difference between getTrans and makeTrans.

I would love to hear your thoughts on my comments.

cheers,
-----
Ben Scott
Research Assistant VRAC
bs...@ia...

[ggt-devel] [ ggt-Feature Requests-562038 ] getTrans that returns a vec

[<no...@so...>]

Feature Requests item #562038, was opened at 2002-05-29 14:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=437250&aid=562038&group_id=43735

Category: None
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Ben Scott (nonchocoboy)
Assigned to: Ben Scott (nonchocoboy)
Summary: getTrans that returns a vec

Initial Comment:
A getTrans for a matrix that returns a new vec rather
than having to pass in a temporary would be convenient.

Matrix44f myMatrix;
Vec3f blah = getTrans(myMatrix);

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

>Comment By: Ben Scott (nonchocoboy)
Date: 2002-05-29 15:33

Message:
Logged In: YES 
user_id=173947

This already exists as makeTrans.

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

Comment By: Allen Bierbaum (allenb)
Date: 2002-05-29 14:52

Message:
Logged In: YES 
user_id=4961

This would be a makeTrans then, not a getTrans.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=437250&aid=562038&group_id=43735

[ggt-devel] [ ggt-Feature Requests-562038 ] getTrans that returns a vec

[<no...@so...>]

Feature Requests item #562038, was opened at 2002-05-29 14:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=437250&aid=562038&group_id=43735

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ben Scott (nonchocoboy)
Assigned to: Ben Scott (nonchocoboy)
Summary: getTrans that returns a vec

Initial Comment:
A getTrans for a matrix that returns a new vec rather
than having to pass in a temporary would be convenient.

Matrix44f myMatrix;
Vec3f blah = getTrans(myMatrix);

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

>Comment By: Allen Bierbaum (allenb)
Date: 2002-05-29 14:52

Message:
Logged In: YES 
user_id=4961

This would be a makeTrans then, not a getTrans.

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=437250&aid=562038&group_id=43735

[ggt-devel] [ ggt-Feature Requests-562038 ] getTrans that returns a vec

[<no...@so...>]

Feature Requests item #562038, was opened at 2002-05-29 14:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=437250&aid=562038&group_id=43735

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ben Scott (nonchocoboy)
>Assigned to: Ben Scott (nonchocoboy)
Summary: getTrans that returns a vec

Initial Comment:
A getTrans for a matrix that returns a new vec rather
than having to pass in a temporary would be convenient.

Matrix44f myMatrix;
Vec3f blah = getTrans(myMatrix);

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=437250&aid=562038&group_id=43735

[ggt-devel] [ ggt-Feature Requests-562038 ] getTrans that returns a vec

[<no...@so...>]

Feature Requests item #562038, was opened at 2002-05-29 14:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=437250&aid=562038&group_id=43735

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ben Scott (nonchocoboy)
Assigned to: Nobody/Anonymous (nobody)
Summary: getTrans that returns a vec

Initial Comment:
A getTrans for a matrix that returns a new vec rather
than having to pass in a temporary would be convenient.

Matrix44f myMatrix;
Vec3f blah = getTrans(myMatrix);

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

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=437250&aid=562038&group_id=43735

[ggt-devel] [Task #54015] add makeInvert that takes a matrix

[<no...@so...>]

Task #54015 has been updated. 

Project: Generic Graphics Toolkit
Subproject: GMTL
Summary: add makeInvert that takes a matrix
Complete: 100%
Status: Closed
Authority  : nonchocoboy
Assigned to: nonchocoboy

Description: We need an invert function that only takes a source matrix and returns the result out the back rather than having to create a new matrix and passing it in as the dest matrix as we currently do. This will probably require the use of Type2Type to generalize.

Follow-Ups:

-------------------------------------------------------
Date: 2002-05-20 13:55
By: nonchocoboy

Comment:
Implemented as makeInverse in gmtl/Generate.h

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/pm/task.php?func=detailtask&project_task_id=54015&group_id=43735&group_project_id=16299

[ggt-devel] [Task #54016] VecBase weirdness

[<no...@so...>]

Task #54016 has been updated. 

Project: Generic Graphics Toolkit
Subproject: GMTL
Summary: VecBase weirdness
Complete: 0%
Status: Open
Authority  : subatomic
Assigned to: subatomic, nonchocoboy, allenb

Description: 
when doing 

Point + Vec

it returns a VecBase

Passing this VecBase for example to Plane::distance  gives a compiler error, because it doesn't know about VecBase

do we want to do anything to fix this?  
Point + Vec always returns a point. so vecbase might not be quite right anyway.

also..
Vec + Point is probably invalid (can't offset by a point, it isn't an offset).

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/pm/task.php?func=detailtask&project_task_id=54016&group_id=43735&group_project_id=16299