Menu
▾
▴
openvrml-develop
|
From: Braden M. <br...@en...> - 2001-10-10 19:21:39
|
[Starting a new thread since this has nothing to do with Peter Meier's
problem.]
On Tue, 2001-10-09 at 16:47, S.K.Bose wrote:
> In the process of adding VrmlMatrix class (having 4X4 elements in
> row-major order), I had some discussion with Braden about interface
> issues. I am having opinion to have overloading operators "*" and "*=" to
> do multiplication of two matrices. I know multiplication of two matrices
> is not commutative (A*B != B*A). But if I write "A*B" --- it means I want
> to do multiplication from "left to right" (B is post multiplied with A)
> not from "right to left". Is there any scope of ambiguity exist by having
> such operators in VrmlMatrix class?
In general, class interfaces should not provide multiple means of doing
the exact same thing. The methods MMleft() and MMright() provide the
necessary functionality; and I prefer this approach as it is consistent
with the ECMAScript VrmlMatrix definition. (In general, I think we
should match method names with the ECMAScript definition, where our
VrmlMatrix does the same thing.)
Some other issues:
* The constructor that takes a float[4][4] should be made
explicit. I don't think automatic conversions from that type
are desirable.
* By the same token, I think the cast operators to float* and
Matrix& should be dropped. Someone who wants a pointer to the
first element can get it easily enough using
float * f = &myVrmlMatrix[0];
* operator[] should return a float (&)[4]. This maintains static
type checking of the array size.
* Rather than have the static method identity(), why not just
have the default constructor create an identity matrix?
--
Braden McDaniel e-mail: <br...@en...>
<http://endoframe.com> Jabber: <br...@ja...>
|
|
From: Braden M. <br...@en...> - 2001-10-11 04:41:27
|
On Wed, 2001-10-10 at 15:21, Braden McDaniel wrote:
> * By the same token, I think the cast operators to float* and
> Matrix& should be dropped. Someone who wants a pointer to the
> first element can get it easily enough using
> float * f = &myVrmlMatrix[0];
Er, that should be:
float * f = &myVrmlMatrix[0][0];
--
Braden McDaniel e-mail: <br...@en...>
<http://endoframe.com> Jabber: <br...@ja...>
|
|
From: S.K.Bose <bo...@pa...> - 2001-10-12 05:25:01
|
On 10 Oct 2001, Braden McDaniel wrote: > > In general, class interfaces should not provide multiple means of doing > the exact same thing. The methods MMleft() and MMright() provide the > necessary functionality; and I prefer this approach as it is consistent > with the ECMAScript VrmlMatrix definition. Technically I am not convinced after all it is C++ lib. In VrmlSFVec3f we have the methods getX(), getY() and getZ() but still we have the operator [] Why? Because this is more convenient and conventional notation. We are more *familiar* and *comfortable* with this notation from our school days through textbook. > * Rather than have the static method identity(), why not just > have the default constructor create an identity matrix? > Probably you are right. I was more concerned about performance. Bose |
|
From: Braden M. <br...@en...> - 2001-10-12 07:51:23
|
On Thu, 2001-10-11 at 14:34, S.K.Bose wrote:
>
>
> On 10 Oct 2001, Braden McDaniel wrote:
>
> >
> > In general, class interfaces should not provide multiple means of doing
> > the exact same thing. The methods MMleft() and MMright() provide the
> > necessary functionality; and I prefer this approach as it is consistent
> > with the ECMAScript VrmlMatrix definition.
>
> Technically I am not convinced after all it is C++ lib.
>
> In VrmlSFVec3f we have the methods getX(), getY() and getZ() but still we
> have the operator [] Why? Because this is more convenient and conventional
> notation. We are more *familiar* and *comfortable* with this notation from
> our school days through textbook.
Those methods do access the same values, but the different means of
access are important. operator[] lets me get the color using an integer
argument, which is necessary when iterating. But getX() and the like are
more expressive when the context applies only to a single element of the
vector. It's true that we could live with *only* operator[] for access
(or some similar method that takes an index argument), but I think that
getX(), etc., provide a valuable distinction where that distinction is
important. In code that cares only about the z-component, I think
"v.getZ()" is more obvious than "v[2]". I don't think that operator* for
multiplication of VrmlMatrix adds clarity in the same way.
For someone who hasn't seen the header to VrmlMatrix, I think the
function of "m.multRight(n)" would be completely clear. A reader can
look at "m * n" and be *pretty* sure about what it does, but not
completely (IMO). Consider that many C++ programmers are appropriately
wary when they see an overloaded operator in an unfamiliar context
(familiar contexts for overloaded operators would be STL iterators,
smart pointers, iostreams, ...).
> > * Rather than have the static method identity(), why not just
> > have the default constructor create an identity matrix?
> >
> Probably you are right. I was more concerned about performance.
While operations on matrices will be performance critical, I don't think
matrix creation is likely to be a bottleneck.
***
I was just reading your ChangeLog comments, and you say
* A New Class VrmlMatrix is implemented. Here the format
is same as OpenGL standard. So this matrix can be used
transparently as OpenGL matrix.
OpenGL matrices are column-major, whereas VrmlMatrix is row-major. I'd
like to keep VrmlMatrix row-major, but that difference should be kept in
mind when feeding them to OpenGL.
--
Braden McDaniel e-mail: <br...@en...>
<http://endoframe.com> Jabber: <br...@ja...>
|
|
From: S.K.Bose <bo...@pa...> - 2001-10-12 09:08:59
|
On 12 Oct 2001, Braden McDaniel wrote: > I was just reading your ChangeLog comments, and you say > > * A New Class VrmlMatrix is implemented. Here the format > is same as OpenGL standard. So this matrix can be used > transparently as OpenGL matrix. > > OpenGL matrices are column-major, whereas VrmlMatrix is row-major. I'd > like to keep VrmlMatrix row-major, but that difference should be kept in > mind when feeding them to OpenGL. > You're right of course. I mean to say here the rotation, translation, scaling, .....all settings are according to OpenGL format. Bose |
|
From: Sylvain C. <syl...@to...> - 2001-10-18 03:20:29
|
While at matrix transform, could it be possible to implement the VRMLMatrix in a way that it will be "open" to a reimplementation of the VRML1.0 MatrixTransform - access to *all* of the 16 values? I intend to create a VRML97 like implemetation of this matrix, all field should be dynamicaly accessible. I know that it could lead to implemetation problems (but not sure of which - non-invertible transform?, impossible space?) and thats why it have been dropped from VRML97; cryptic, complicated to implement and barely used. Actually, on the pc, I only know of VRMLView that can display those transforms correctly, all the others either ignore or cant display objects transformed with projection parameters included in the matrix. Worse, some toolkit even have them illegal (java3D). One option will be to link Ellipsis to OpenInventor and add that extra MatrixTransform as a new VRML97 syntax like node with eventIn's/out's. The other option will be having you guys leave open the matrix (not enforcing affine only transform as in java3D) at least at the very low level so someone could implement back a fully functionnal matrix transform. I hope this can be feasible with openvrml. Sylvain Carette VRML designer-composer "S.K.Bose" wrote: > On 12 Oct 2001, Braden McDaniel wrote: > > > I was just reading your ChangeLog comments, and you say > > > > * A New Class VrmlMatrix is implemented. Here the format > > is same as OpenGL standard. So this matrix can be used > > transparently as OpenGL matrix. > > > > OpenGL matrices are column-major, whereas VrmlMatrix is row-major. I'd > > like to keep VrmlMatrix row-major, but that difference should be kept in > > mind when feeding them to OpenGL. > > > > You're right of course. > > I mean to say here the rotation, translation, scaling, .....all settings > are according to OpenGL format. > > Bose > > _______________________________________________ > openvrml-develop mailing list > ope...@li... > https://lists.sourceforge.net/lists/listinfo/openvrml-develop |
Thanks for helping keep SourceForge clean.
X