openvrml-develop — OpenVRML developers mailing list

[openvrml-develop] Navigation Patch

[<luc...@li...>]

Substituting the implementation of rot in ViewerOpengl.cpp with the 
following one:

///////////////////////////////////////////////////////////////////////
void
ViewerOpenGL::rot(float x, float y, float z, float a)
{

float rot_quat[4];
	float vec[3];
	
	
	vec[0]=3Dx;
	vec[1]=3Dy;
	vec[2]=3Dz;

	// normalizing vector

	int i;
    float module;

    module =3D (vec[0]*vec[0] + vec[1]*vec[1]+vec[2]*vec[2] );
	module=3Dsqrt(module);
    for (i =3D 0; i < 3; i++) vec[i] /=3D module;

	// computing quaternion
	
	float q=3Dsin(a*0.01/2);
	rot_quat[0]=3D vec[0]*q;
	rot_quat[1]=3D vec[1]*q;
	rot_quat[2]=3D vec[2]*q;
	rot_quat[3]=3Dcos(a*0.01/2);

	add_quats(rot_quat,d_curquat,d_curquat);

	d_rotationChanged=3Dtrue;

	wsPostRedraw();

}
//////////////////////////////////////////////////////////////////////


will solve issue number 1. as described in the bug report regarding 
Navigation submitted by Greg Roelofs.
I can work to improve the navigation interface.
It would be useful if i can get in touch with Greg or with someone else 
to discuss possible improvements.

Luca

Re: [openvrml-develop] Link error in 0.11.2

[Tom F. <tf...@us...>]

Hey James,

This problem has come up for others before
(http://www.geocrawler.com/archives/3/6420/2001/7/0/6091728/) and I think
the solution was to look through your system for old GL headers and libs and
to toss them.

If it helps, I'm running the default RH 7.1 installation and am not
currently seeing this issue...

Later,
Tom

----- Original Message -----
From: "James Smith" <ja...@va...>
To: <ope...@li...>
Sent: Monday, October 22, 2001 7:07 AM
Subject: [openvrml-develop] Link error in 0.11.2

Hi all,

Having made the leap to running linux almost full time now, I'm trying
to build OpenVRML 0.11.2, but I get linker errors, and was just
wondering if anyone had come across this before, or if it was something
really obvious:

../../src/openvrml-gl/OpenVRML/GL/.libs/libopenvrml-gl.so: undefined
reference to `gluTessBeginPolygon'
../../src/openvrml-gl/OpenVRML/GL/.libs/libopenvrml-gl.so: undefined
reference to `gluTessEndContour'
../../src/openvrml-gl/OpenVRML/GL/.libs/libopenvrml-gl.so: undefined
reference to `gluTessBeginContour'
../../src/openvrml-gl/OpenVRML/GL/.libs/libopenvrml-gl.so: undefined
reference to `gluTessEndPolygon'

I think these are GLUT errors, but I have Mesa-devel 3.4-13, and Mesa
3.4-13, so I'm not quite sure what could be wrong...

Any suggestions greatly appreciated.

cheers,
--
James Smith - Vapour Technology - ja...@va...
www: http://www.vapourtech.com/          ICQ: 53372434
PGP: B42F 9ACD D166 018C 57F8 8698 098E FAA2 C03B C9ED
======================================================
"There's no explaining the things that might happen;
 there's now a new home for technology in fashion."
        - The Clint Boon Experience
======================================================

[openvrml-develop] What are default magnitudes for Translation and Rotation

[John R. <ric...@sp...>]

Hello,

The ViewerOpenGL class has 2 method for moving the viewpoint. One is rot
and the other is step.

What is the magnitude of the default unit rotation and the default unit
translation?

In other words, each step is x meters. Each rotation is by y degrees. What
is x and y?

Where in the code is the default magnitude calculated?

John F. Richardson

[openvrml-develop] Link error in 0.11.2

[James S. <ja...@va...>]

Hi all,

Having made the leap to running linux almost full time now, I'm trying
to build OpenVRML 0.11.2, but I get linker errors, and was just
wondering if anyone had come across this before, or if it was something
really obvious:

../../src/openvrml-gl/OpenVRML/GL/.libs/libopenvrml-gl.so: undefined
reference to `gluTessBeginPolygon'
../../src/openvrml-gl/OpenVRML/GL/.libs/libopenvrml-gl.so: undefined
reference to `gluTessEndContour'
../../src/openvrml-gl/OpenVRML/GL/.libs/libopenvrml-gl.so: undefined
reference to `gluTessBeginContour'
../../src/openvrml-gl/OpenVRML/GL/.libs/libopenvrml-gl.so: undefined
reference to `gluTessEndPolygon'

I think these are GLUT errors, but I have Mesa-devel 3.4-13, and Mesa
3.4-13, so I'm not quite sure what could be wrong...

Any suggestions greatly appreciated.

cheers,
--=20
James Smith - Vapour Technology - ja...@va...
www: http://www.vapourtech.com/          ICQ: 53372434
PGP: B42F 9ACD D166 018C 57F8 8698 098E FAA2 C03B C9ED
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D
"There's no explaining the things that might happen;
 there's now a new home for technology in fashion."
        - The Clint Boon Experience
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D

Re: [openvrml-develop] prob compiling openvrml 0.11.2

[clayton <dr...@sm...>]

Braden McDaniel wrote:

>On Sat, 2001-10-20 at 13:41, Clayton Cottingham aka drfrog wrote:
>
>>hey here is where it breaks iun configure
>>
>>what is this auto_ptr and what version of c++ has it?
>>
>
>auto_ptr is a simple smart pointer that transfers ownership of its
>resource on assignment. It is part of the standard library in ISO C++98.
>
>>checking if C++ compiler has auto_ptr... no
>>configure: error: auto_ptr not found
>>
>>
>>also wondering if gtklookat has to be recompiled
>>my guess is yes
>>but im looking for offiial answer
>>
>
>If you have a GtkLookat version compiled against 0.11.x, it should still
>work with 0.11.2; API changes are denoted by a change to the "minor"
>version number (the middle number).
>

cool to know !
i grew up with MS
what can i say!
their version never meant much!
i guess it was habit forming


>
>>[drfrog@nomad drfrog]$ uname -a
>>Linux nomad.localdomain 2.2.18 #2 Tue Apr 17 22:55:04 PDT 2001 i686 unknown
>>
>>[drfrog@nomad drfrog]$ gcc -v
>>Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux/2.95.3/specs
>>gcc version 2.95.3 19991030 (prerelease)
>>
>
>It's been a while since I used gcc 2.95, but I thought it had a
>functional auto_ptr. I'd first try using the actual 2.95.3 release
>rather than the prerelease you apparently have. If that doesn't work,
>you can try gcc3.
>
>I'm using Red Hat's massively patched gcc 2.96 here; and I think newer
>Mandrake releases (8.x?) include this compiler, too.
>
hmmm
well i guess this brings up
the ideal of how far backwards
compatibile openvrml should go

but basically yes.
 i thought it might be a gcc version thing myself

so i tried to install mandrake 8.0 with no luck
sigh.

Re: [openvrml-develop] prob compiling openvrml 0.11.2

[Braden M. <br...@en...>]

On Sat, 2001-10-20 at 13:41, Clayton Cottingham aka drfrog wrote:
> hey here is where it breaks iun configure
> 
> what is this auto_ptr and what version of c++ has it?

auto_ptr is a simple smart pointer that transfers ownership of its
resource on assignment. It is part of the standard library in ISO C++98.

> checking if C++ compiler has auto_ptr... no
> configure: error: auto_ptr not found
> 
> 
> also wondering if gtklookat has to be recompiled
> my guess is yes
> but im looking for offiial answer

If you have a GtkLookat version compiled against 0.11.x, it should still
work with 0.11.2; API changes are denoted by a change to the "minor"
version number (the middle number).

> [drfrog@nomad drfrog]$ uname -a
> Linux nomad.localdomain 2.2.18 #2 Tue Apr 17 22:55:04 PDT 2001 i686 unknown
> 
> [drfrog@nomad drfrog]$ gcc -v
> Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux/2.95.3/specs
> gcc version 2.95.3 19991030 (prerelease)

It's been a while since I used gcc 2.95, but I thought it had a
functional auto_ptr. I'd first try using the actual 2.95.3 release
rather than the prerelease you apparently have. If that doesn't work,
you can try gcc3.

I'm using Red Hat's massively patched gcc 2.96 here; and I think newer
Mandrake releases (8.x?) include this compiler, too.

-- 
Braden McDaniel                           e-mail: <br...@en...>
<http://endoframe.com>                    Jabber: <br...@ja...>

[openvrml-develop] prob compiling openvrml 0.11.2

[Clayton C. a. d. <dr...@sm...>]

hey here is where it breaks iun configure

what is this auto_ptr and what version of c++ has it?



checking if C++ compiler has auto_ptr... no
configure: error: auto_ptr not found


also wondering if gtklookat has to be recompiled
my guess is yes
but im looking for offiial answer

[drfrog@nomad drfrog]$ uname -a
Linux nomad.localdomain 2.2.18 #2 Tue Apr 17 22:55:04 PDT 2001 i686 unknown

[drfrog@nomad drfrog]$ gcc -v
Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux/2.95.3/specs
gcc version 2.95.3 19991030 (prerelease)

Re: [openvrml-develop] Re: Vrml viewer for linux & windows

[S.K.Bose <bo...@pa...>]

On Thu, 18 Oct 2001, Torsten Wiebesiek wrote:

> Hello again,
> I once again have a problem. I just tried to install the binary release
> of the win32 lookat, but I can't find the js32.dll that is mentioned in
> the INSTALL.TXT. It says that is's on 
> ftp://openvrml.sf.net/pub/openvrml/win32_required_libs.zip but unfortunatly
> I am not able to find it. Can I get it from somewhere else.

Get it from  <http://openvrml.org/dist/>

Thanks,

Bose

[openvrml-develop] ANN: OpenVRML 0.11.2

[Braden M. <br...@en...>]

OpenVRML is a cross-platform C++ library for reading, writing, and
displaying VRML97 worlds. The OpenVRML distribution includes Lookat, a
simple GLUT-based VRML viewer.

OpenVRML 0.11.2 is a minor bugfix release.

OpenVRML can be found at <http://openvrml.org>

What's new in 0.11.2:

- Fixed some minor regressions since 0.10.1.

- `configure' now works for `--without-mozjs'.

Re: [openvrml-develop] Vrml viewer for linux & windows

[Braden M. <br...@en...>]

On Thu, 2001-10-18 at 10:20, Torsten Wiebesiek wrote:
> Hello Gerall!
> 
> > > The different flavours of lookat are vrml-viewers based on openvrml.
> > > Last weekend I compiled openvrml (0.11.1). This was no problem at
> > > all. Then I tried to compile gtklookat (0.9.0) and got the following
> > > error message below.
> > >
> > > Can anyone tell me how to solve this problem or maybe point me to
> > > another vrml viewer for both platforms?
> > 
> > The current CVS version of gtklookat will allow you to compile.  The
> > API for OpenVRML is changing right now, and the portions you noticed
> > getting error messages rely on the old interface...
> > 
> >   I'll put a new version of gtklookat up in tar.gz format by this
> >   weekend to fix this.
> > 
> > Thanks for your patience, time, and attention--  I hope you enjoy
> > using OpenVRML and all the 'lookats...
> 
> That's great! Thank you very much.

Good news, indeed! Thanks, Gerall!

-- 
Braden McDaniel                           e-mail: <br...@en...>
<http://endoframe.com>                    Jabber: <br...@ja...>

[openvrml-develop] Re: Vrml viewer for linux & windows

[Torsten W. <wie...@tn...>]

Hello again,

> I am looking for a vrml viewer for both linux and windows. Recently,
> I found your openvrml project. As far as I can see openvrml is a
> crossplatform library which provides vrml facilities.

I once again have a problem. I just tried to install the binary release
of the win32 lookat, but I can't find the js32.dll that is mentioned in
the INSTALL.TXT. It says that is's on 
ftp://openvrml.sf.net/pub/openvrml/win32_required_libs.zip but unfortunatly
I am not able to find it. Can I get it from somewhere else. I wasn't able
to find a precompiled version on www.mozilla.org and I don't very much like
the idea of downloading compiling the complete mozilla monster.

Torsten

Re: [openvrml-develop] Vrml viewer for linux & windows

[Torsten W. <wie...@tn...>]

Hello Gerall!

> > The different flavours of lookat are vrml-viewers based on openvrml.
> > Last weekend I compiled openvrml (0.11.1). This was no problem at
> > all. Then I tried to compile gtklookat (0.9.0) and got the following
> > error message below.
> >
> > Can anyone tell me how to solve this problem or maybe point me to
> > another vrml viewer for both platforms?
> 
> The current CVS version of gtklookat will allow you to compile.  The
> API for OpenVRML is changing right now, and the portions you noticed
> getting error messages rely on the old interface...
> 
>   I'll put a new version of gtklookat up in tar.gz format by this
>   weekend to fix this.
> 
> Thanks for your patience, time, and attention--  I hope you enjoy
> using OpenVRML and all the 'lookats...

That's great! Thank you very much.

Torsten

Re: [openvrml-develop] Vrml viewer for linux & windows

[Braden M. <br...@en...>]

On Thu, 2001-10-18 at 07:16, Torsten Wiebesiek wrote:
> Hello,
> 
> I am looking for a vrml viewer for both linux and windows. Recently, 
> I found your openvrml project. As far as I can see openvrml is a
> crossplatform library which provides vrml facilities.
> 
> The different flavours of lookat are vrml-viewers based on openvrml.
> Last weekend I compiled openvrml (0.11.1). This was no problem at
> all. Then I tried to compile gtklookat (0.9.0) and got the following
> error message below.
> 
> Can anyone tell me how to solve this problem or maybe point me to
> another vrml viewer for both platforms?

Unfortunately, I think the only one of the *lookat viewers that's being
actively maintained is Win32Lookat.

You should be able to compile gtklookat against OpenVRML 0.9. Lookat,
which comes with the OpenVRML distribution, is a simple GLUT-based
viewer that should work on both Linux and Windows. But it is not as
sophisticated as either Win32Lookat or gtklookat.

-- 
Braden McDaniel                           e-mail: <br...@en...>
<http://endoframe.com>                    Jabber: <br...@ja...>

[openvrml-develop] Vrml viewer for linux & windows

[Torsten W. <wie...@tn...>]

Hello,

I am looking for a vrml viewer for both linux and windows. Recently, 
I found your openvrml project. As far as I can see openvrml is a
crossplatform library which provides vrml facilities.

The different flavours of lookat are vrml-viewers based on openvrml.
Last weekend I compiled openvrml (0.11.1). This was no problem at
all. Then I tried to compile gtklookat (0.9.0) and got the following
error message below.

Can anyone tell me how to solve this problem or maybe point me to
another vrml viewer for both platforms?

Thanks,

  Torsten



Making all in src
make[1]: Entering directory `/phys/widar/home/wiebesie/vrml/openvrml/gtklookat-0.9.0/src'
c++ -DPACKAGE=\"gtklookat\" -DVERSION=\"0.9.0\"  -I. -I.      -fpermissive -I/home/wiebesie/local/include -I/prog/gtk/1.2/lib/glib/include -I/prog/gtk/1.2/include -I/usr/X11R6/include
-I/home/wiebesie/local/include -I/prog/mesa/include -c gtklookat.cpp
gtklookat.cpp: In function `void view_structure_recursive(VrmlNodeGroup *, GtkWidget *, NodeInfo *)':
gtklookat.cpp:253: no matching function for call to `VrmlNodeGroup::size ()'
gtklookat.cpp:257: no matching function for call to `VrmlNodeGroup::child (int &)'
gtklookat.cpp:258: no matching function for call to `VrmlNodeGroup::child (int &)'
gtklookat.cpp:262: no matching function for call to `VrmlNodeGroup::child (int &)'
gtklookat.cpp:279: no matching function for call to `VrmlNodeGroup::child (int &)'
gtklookat.cpp: At top level:
gtklookat.cpp:506: warning: ANSI C++ prohibits conversion from `(void *, unsigned int, GtkWidget *)' to `(...)'
gtklookat.cpp:506: warning: ANSI C++ prohibits conversion from `(void *, unsigned int, GtkWidget *)' to `(...)'
gtklookat.cpp:506: warning: ANSI C++ prohibits conversion from `(void *, unsigned int, GtkWidget *)' to `(...)'
gtklookat.cpp:506: warning: ANSI C++ prohibits conversion from `(void *, unsigned int, GtkWidget *)' to `(...)'
gtklookat.cpp:506: warning: ANSI C++ prohibits conversion from `(void *, unsigned int, GtkWidget *)' to `(...)'
gtklookat.cpp:506: warning: ANSI C++ prohibits conversion from `(void *, unsigned int, GtkWidget *)' to `(...)'
gtklookat.cpp:506: warning: ANSI C++ prohibits conversion from `(void *, unsigned int, GtkWidget *)' to `(...)'
gtklookat.cpp:506: warning: ANSI C++ prohibits conversion from `(void *, unsigned int, GtkWidget *)' to `(...)'
gtklookat.cpp:506: warning: ANSI C++ prohibits conversion from `(void *, unsigned int, GtkWidget *)' to `(...)'
make[1]: *** [gtklookat.o] Error 1
make[1]: Leaving directory `/home/wiebesiek/vrml/openvrml/gtklookat-0.9.0/src'
make: *** [all-recursive] Error 1

Re: [openvrml-develop] getPosition()

[Javier T. <jt...@ud...>]

17/10/2001 21:35:55, "S.K.Bose" <bo...@pa...> wrote:

  Hello,

>>   What is Viewer::getPosition() supposed to return?
>>=20
>It supposed to return changed viewer position w.r.t  **local coordinate
>system**.

  Well, as I have posted before (in the list and in the bug tracker) ,it=20
doesn't work.=20

  I tried to fix the bug, but I was unable to understand what is this
method doing and why does it call gluUnproject using the translation
part of the modelview matrix as window coordinates to obtain world
coordinates. Perhaps my maths background is not too strong :)

  Anyway, I think I have fixed the problem reimplementing the method.
I take the modelview matrix, calculate its inverse and multiply with
vector (0,0,0,1). This way I obtain the position of the camera in the
local coordinate system, and it seems to work quite good.


  Regards,

  Javier Taibo  <jt...@ud...>
  Visualization for Engineering Architecture and Urban Design Group
  VideaLAB - University of Coru=F1a
  http://videalab.udc.es

Re: [openvrml-develop] getPosition()

[S.K.Bose <bo...@pa...>]

On Wed, 17 Oct 2001, Javier Taibo wrote:

> 
>   Hello folks,
> 
>   I have an easy question
> 
>   What is Viewer::getPosition() supposed to return?
> 
It supposed to return changed viewer position w.r.t  **local coordinate
system**.

Thanks,

Bose

Re: [openvrml-develop] Re: VrmlMatrix

[Sylvain C. <syl...@to...>]

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

[openvrml-develop] getPosition()

[Javier T. <jt...@ud...>]

  Hello folks,

  I have an easy question

  What is Viewer::getPosition() supposed to return?


  Thanks in advance,


  Javier Taibo  <jt...@ud...>
  Visualization for Engineering Architecture and Urban Design Group
  VideaLAB - University of Coru=F1a
  http://videalab.udc.es

Re: [openvrml-develop] configure and mozjs

[Braden M. <br...@en...>]

On Tue, 2001-10-16 at 14:48, Michael Case wrote:
> configure line 6237 should be:
> 
>     if test "X$with_mozjs" = "Xno"; then
> 
> and not
> 
>     if test "X$with_mozjs" == "Xno"; then

This has been reported and fixed in CVS.

-- 
Braden McDaniel                           e-mail: <br...@en...>
<http://endoframe.com>                    Jabber: <br...@ja...>

[openvrml-develop] configure and mozjs

[Michael C. <me...@uc...>]

Hi,

I'm not an expert on script/configure/make but...  I could not get into
source forge to post this.

configure line 6237 should be:

    if test "X$with_mozjs" = "Xno"; then

and not

    if test "X$with_mozjs" == "Xno"; then

-- 

Michael E. Case
UC Davis
ca...@uc...
(530) 754-7226

[openvrml-develop] Displaying more than one VrmlViewer on the same window

[<luc...@li...>]

I managed to do it:

the trick is to save a safe DC and RC for the current window and then 
adding the following to the window drawing routine:

if (m_pViewer)
	{
		::wglMakeCurrent(m_hDC,m_hRC);
		m_pViewer->redraw();
		
	}.

While writing this code i have seen thing that seems a bug: if i pass 
to the vrmlscene constructor a wrong filename i dont get any message 
error and the vrml world is displayed as empty.

Luca

[openvrml-develop] GNU autotools

[Braden M. <br...@en...>]

Both autoconf and automake have relatively new releases that have been
out in the world for a little while now--2.52 and 1.5, respectively.
Libtool also has a rather recent release (1.4) that I've already used to
build our last few release tarballs.

For our 0.12 release, I'd like to require autoconf 2.52. It has many
improvements over the 2.13 release. Leveraging some of improvements will
break compatibility with 2.13. Not leveraging them will result in a
number of warnings that complain about use of deprecated features. (It
is evident from this as well as the tone of many comments in the
autoconf documentation that the autoconf authors are eager for users to
leave the legacy of 2.13 behind.)

If requiring the newer autotools releases is going to be a problem for
anyone, speak up.

-- 
Braden McDaniel                           e-mail: <br...@en...>
<http://endoframe.com>                    Jabber: <br...@ja...>

[openvrml-develop] New documentation: patch instructions & coding standards

[Braden M. <br...@en...>]

I've posted a couple of new documents to our SourceForge documentation
pages. The first is a long overdue introduction to patch generation:

    <http://sourceforge.net/docman/display_doc.php?docid=7254&group_id=7151>

The second is a first iteration of a coding standards document. This is
intended primarily as a starting point for discussion on the matter.

    <http://sourceforge.net/docman/display_doc.php?docid=7253&group_id=7151>

Of course, comments and suggestions regarding both documents are
welcome.

-- 
Braden McDaniel                           e-mail: <br...@en...>
<http://endoframe.com>                    Jabber: <br...@ja...>

Re: [openvrml-develop] Re: VrmlMatrix

[S.K.Bose <bo...@pa...>]

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

Re: [openvrml-develop] Re: VrmlMatrix

[Braden M. <br...@en...>]

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