openvrml-develop — OpenVRML developers mailing list

[Openvrml-develop] Problems introduced since 0.10.1

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

Hey all,

Last mail of the night, I promise :-)

Using the latest CVS source, a new problem is appearing that didn't occur in
0.10.1 (or 0.9.0 for that matter). Since I know there haven't been that many
checkins since the last release, I was hoping someone would remember a
change that could have introduced this problem.

The new bug occurs with ElevationGrid's and the fact that their color field
should supersede a Material node's diffuseColor. This problem can be
reproduced using the NIST conformance tests #11 and 12 of the Material node.
(direct link to #11
http://xsun.sdct.itl.nist.gov/~mkass/vts/Appearance/Material/complex_color_f
irst_texture.wrl )

Any thoughts on what change could be causing this problem or even a good
pointer as to where to start?

Thanks,
Tom

[Openvrml-develop] Possible Patch for Bug #210011 (and probably #211349)

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

Hey all,

I've been trying to track down a bug dealing with emissiveColor and
IndexedLineSet nodes. I've found a 'fix' for this bug but I'm worried there
might be side-effects to the change that I don't grok because I don't
understand the OpenGL code very well. I've gone back and retested all of the
conformance tests related to Material nodes and nothing new breaks with this
change but was hoping someone verify that what I've done is correct. I'm
attaching the unified diff for the fix to the bottom of the mail for your
consideration. Comments would be much appreciated.

Thanks,
Tom

Unified diff of changes to GL/ViewerOpenGL.cpp
----------------------------------
Index: openvrml/src/openvrml-gl/OpenVRML/GL/ViewerOpenGL.cpp
===================================================================
RCS file: /cvsroot/openvrml/openvrml-gl/src/OpenVRML/GL/ViewerOpenGL.cpp,v
retrieving revision 1.5
diff -u -r1.5 ViewerOpenGL.cpp
--- openvrml/src/openvrml-gl/OpenVRML/GL/ViewerOpenGL.cpp 2000/12/19
03:35:07 1.5
+++ openvrml/src/openvrml-gl/OpenVRML/GL/ViewerOpenGL.cpp 2001/04/04
02:54:52
@@ -2196,7 +2196,7 @@
   else
     {
       glMaterialfv(GL_FRONT_AND_BACK, GL_EMISSION, emission);
-      glColor4fv( diffuse );
+      glColor4fv( emission );
     }
 }

[Openvrml-develop] Patch for Bug 407708 "Deleting route crashs core"

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

Hey all,

Peter Eschler recently submitted a patch to fix a bug he encountered in
openvrml where lookat would core if the first route in the route list was
deleted and then followed by a call to VrmlNode::getRoutes(). I've tested
his patch and will check in the change to CVS this weekend unless someone
sees a problem with it.

Thanks,
Tom

Unified diff of changes to VrmlNode.cpp to fix Bug 407708
------------------------
Index: openvrml/src/openvrml/OpenVRML/VrmlNode.cpp
===================================================================
RCS file: /cvsroot/openvrml/openvrml-core/src/OpenVRML/VrmlNode.cpp,v
retrieving revision 1.9
diff -u -r1.9 VrmlNode.cpp
--- openvrml/src/openvrml/OpenVRML/VrmlNode.cpp 2001/02/28 03:24:31 1.9
+++ openvrml/src/openvrml/OpenVRML/VrmlNode.cpp 2001/04/04 02:38:35
@@ -328,7 +328,15 @@
    strcmp(toEventIn, r->toEventIn()) == 0 )
  {
    if (r->prev())
+          {
      r->prev()->setNext(r->next());
+          }
+          else
+          {
+            // point to new head of route list if deleting first route
+            d_routes = r->next();
+          }
+
    if (r->next())
      r->next()->setPrev(r->prev());
    delete r;

Re: [Openvrml-develop] Building for MacOS-X

[Michael L. <Mic...@hr...>]

I'm currently setting up a machine to attempt this, but haven't got as far 
as trying yet.

As a first attempt, I think it should be possible to compile the OpenVRML 
libraries without GLUT dependencies (I believe GLUT is only use for the 
Text node within OpenVRML -- probably need to hack the configure script to 
enable us to set the HAVE_GLUT flag to false if OpenGL is found and GLUT 
is not found?) and then "independently" build Lookat (or whatever) using 
Apple's GLUT to actually use the OpenVRML library.

If you're in a desperate hurry then you could install Mesa and XFree86 and 
build a X11-based version (This would be the "Darwin" version of OpenVRML 
so it would be "legitimate" to do this even if it is not an optimal 
version for Mac OS X). It would run under Darwin or Mac OS X (with X11 & 
Mesa) until a Quartz version has been sorted out.

Michael.

On Monday, April 2, 2001, at 06:26 , Oliver Strutynski wrote:

> Has anybody already successfully built OpenVRML on MacOS X? I tried today 
> but
> ran into problems running the configure script because it did not find the
> Glut libraries. OS-X has them but they are in one of the framework
> directories, so there is no libglut* file.
>
> Any ideas?
>
> Bye, Oliver

--
http://home.enitel.no/mlouka/

[Openvrml-develop] Building for MacOS-X

[Oliver S. <oli...@gm...>]

Has anybody already successfully built OpenVRML on MacOS X? I tried today but 
ran into problems running the configure script because it did not find the 
Glut libraries. OS-X has them but they are in one of the framework 
directories, so there is no libglut* file.

Any ideas?

Bye, Oliver


-- 
_____________________________________________________________________
 Oliver Strutynski                                oli...@in...

Re: [Openvrml-develop] OpenVRML user's guide/programmer's reference

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

Hi Alan,

Unfortunately I don't think there is a "programmer's reference" for
OpenVRML. The only reference really is the source code comments. If you have
specific questions that you can't find an answer to, send a mail to this
list and hopefully someone will be able to answer it for you. Sorry I can't
be of more help.

Good Luck,
Tom

----- Original Message -----
From: "Alan Liu" <li...@ix...>
To: <ope...@li...>
Sent: Monday, March 26, 2001 4:16 PM
Subject: [Openvrml-develop] OpenVRML user's guide/programmer's reference


> Folks,
>
> I'm relatively new to VRML.  I have several models extracted from the
> Visible Human in VRML format.  I'd like to use these models in an
> OpenGL/C++ program for surgical simulation.  I downloaded and installed
> openvrml.  I managed to compile and run lookat and everything seems to be
> working nicely.
>
> Unfortunately, there doesn't seem to be a programmer's reference included
> with the package.  Is there such a document available that I can refer to?
>
> Cheers,
> Al
>
>
> _______________________________________________
> Openvrml-develop mailing list
> Ope...@li...
> http://lists.sourceforge.net/lists/listinfo/openvrml-develop
>

[Openvrml-develop] OpenVRML user's guide/programmer's reference

[Alan L. <li...@ix...>]

Folks,

I'm relatively new to VRML.  I have several models extracted from the 
Visible Human in VRML format.  I'd like to use these models in an 
OpenGL/C++ program for surgical simulation.  I downloaded and installed 
openvrml.  I managed to compile and run lookat and everything seems to be 
working nicely.

Unfortunately, there doesn't seem to be a programmer's reference included 
with the package.  Is there such a document available that I can refer to?

Cheers,
Al

[Openvrml-develop] Mixing OpenVRML and OpenGL calls

[Oliver S. <oli...@gm...>]

Hi there,

I am currently working on porting an augmented reality application from 
hard-coded objects (OpenGL calls) to a more flexible way at least providing 
the ability to read in models from files and to modify them dynamically. I 
experimented with Inventor but that wasn't really a solution since it did not 
compile under MacOSX (yup, it needs to!). Now I ran across OpenVRML and it 
seems to be just what I need.

However while I will eventually port the entire application to use OpenVRML 
calls only, this might take some time and hence I would like to combine the 
old OpenGL code with OpenVRML code. Using the ViewerGlut class provided in 
the lookat example I was able to load/display VRML models and to display 
additional OpenGL coded stuff simultaneously. However I did not manage to 
transform OpenVRML output using OpenGL.

One mode of the application for example allows the user to rotate objects. 
This is done by manipulating the MODEL_VIEW Stack and displaying the objects 
using call lists. So I thought to rotate the VRML model accordingly I could 
just write

 glMatrixMode(GL_MODELVIEW);
 glPushMatrix();
 glLoadIdentity();
 glRotated(count,0,1,0);
  // iterate over calllists and process them

  // new code:
  viewer->updateDisplay(); // this basically calls the viewer::redraw method
 glPopMatrix();

This code does rotate the model drawn via OpenGL call lists but it does not 
rotate VRML model displayed in the viewer (probably because of the   
"glMatrixMode(GL_MODELVIEW); glLoadIdentity();" in ViewerOpenGL.cpp). Now I 
would like to know if there is a way to have OpenVRML use the matrizes 
defined before calling the redraw method, so that I can just redraw the model 
but keep the other transformations for a while.

Also I did not see a way to traverse the node tree for a model. Did I miss 
anything there?

I would really appreciate any help. Thank you very much.

Oliver


-- 
_____________________________________________________________________
 Oliver Strutynski                                oli...@in...

[Openvrml-develop] new Viewpoints

[Patrick R. <pr...@la...>]

Hi,

I have a problem using the OpenVrml Library: When I want to add a
Viewpoint to my SceneGraph, the keys (PgUp, PgDn) in the lookat viewer
do not work anymore:

Here's the code I added:

VrmlNodeViewpoint* newViewpoint = new VrmlNodeViewpoint(vrmlScene);

 VrmlSFString* vpstring = new VrmlSFString("newViewpoint");
 VrmlSFRotation* rotation = new VrmlSFRotation(0, 1, 0, -1.57);
 VrmlSFVec3f* position = new VrmlSFVec3f(-20, 0, 0);

 newViewpoint->setField("orientation", *rotation);
 newViewpoint->setField("position", *position);
 newViewpoint->setField("description", *vpstring);


I am sure that I forgot something, but I don't know what. Can you please
help me?


Furthermore, I am looking for a Documentation how to use openvrml, I
haven't found one yet.

Thanx a lot in advance!

Patrick

Re: [Openvrml-develop] look for VrmlAABox

[Christopher K. S. J. <cs...@qu...>]

Patrick Reuter wrote:
> 
> does anybody of you have a (draft) implementation of VrmlAABox?
> 

 What do you mean by "implementation"? Do you mean using
it for culling, or an implementation of just the AABox
class, or implementation of the frustum intersection
routines?




-- 
Christopher St. John ck...@di...
DistribuTopia http://www.distributopia.com

[Openvrml-develop] look for VrmlAABox

[Patrick R. <pr...@la...>]

Hi,

does anybody of you have a (draft) implementation of VrmlAABox?

Thanx in advance

Pat

Re: [Openvrml-develop] FreeBSD port

[Chris M. <cm...@ve...>]

Great, thanks Marc.
Chris

----- Original Message ----- 
From: "Marc van Woerkom" <mar...@sc...>
To: <ope...@li...>
Sent: Tuesday, February 27, 2001 8:47 AM
Subject: [Openvrml-develop] FreeBSD port


> Hi,
> 
> just wanted to notice you folks that I submitted a FreeBSD port skeleton 
> of release 0.9.0 some weeks ago
> 
>     http://www.freebsd.org/cgi/query-pr.cgi?pr=24161
> 
> and am in the process of submitting an update for 0.10.1 right now.
> 
> I hope it will get included in the ports collection soon.
> 
> 
> Regards,
> Marc
> 
> 
> 
> _______________________________________________
> Openvrml-develop mailing list
> Ope...@li...
> http://lists.sourceforge.net/lists/listinfo/openvrml-develop
> 

[Openvrml-develop] Re: Problems with lookat via Solaris/OpenGL

[Chris M. <cm...@ve...>]

OK, so a different library is being linked to than is being found at run
time.
From the ldd output, my guess is that the /usr/local/lib/libGL* are the
culprits. Any chance those are mesa libs, while you are linking to real
sun opengl libs in a directory that is either not in your LD_LIBRARY_PATH
or after /usr/local/lib in it?
If you can send the link lines for the openvrml libs and lookat and your
LD_LIBRARY_PATH we might be able to spot the discrepancy.

Chris

----- Original Message -----
From: "Erwin, Richard D" <Ric...@PS...>
To: <ope...@li...>
Cc: <cm...@ve...>
Sent: Tuesday, February 27, 2001 11:36 AM
Subject: Problems with lookat via Solaris/OpenGL


> Chris;
>
> I ran "./configure --enable-static --disable shared", "Gmake check" and
"gmake install".  The out put shows that no shared libraries were built.
>
>
> checking whether to build shared libraries... no
> checking whether to build static libraries... yes
>
> and...
>
> # ls -last /usr/local/lib/libo* | more
>  432 -rw-r--r--   1 nobody   nobody    211476 Feb 25 14:23
/usr/local/lib/libopenvrml-gl.a
>    2 -rwxr-xr-x   1 nobody   nobody       764 Feb 25 14:23
/usr/local/lib/libopenvrml-gl.la
> 35792 -rw-r--r--   1 nobody   nobody   18295508 Feb 25 14:22
/usr/local/lib/libopenvrml.a
>    2 -rwxr-xr-x   1 nobody   nobody       639 Feb 25 14:22
/usr/local/lib/libopenvrml.la
>
>
>
> However...
>
> # lookat ./Anchor.wrl
> ld.so.1: lookat: fatal: relocation error: file lookat: symbol
sunOglCurPrimTablePtr: referenced symbol not found
> Killed
>
> # ldd /usr/local/bin/lookat
> libXmu.so.4 => /usr/openwin/lib/libXmu.so.4
> libXi.so.5 => /usr/openwin/lib/libXi.so.5
> libSM.so.6 => /usr/openwin/lib/libSM.so.6
> libICE.so.6 => /usr/openwin/lib/libICE.so.6
> libX11.so.4 => /usr/openwin/lib/libX11.so.4
> libsocket.so.1 => /usr/lib/libsocket.so.1
> libnsl.so.1 => /usr/lib/libnsl.so.1
> libGLU.so.1 => /usr/local/lib/libGLU.so.1
> libGL.so.1 => /usr/local/lib/libGL.so.1
> libXext.so.0 => /usr/openwin/lib/libXext.so.0
> libm.so.1 => /usr/lib/libm.so.1
> libjpeg.so.62 => /usr/local/lib/libjpeg.so.62
> libpng.so.2 => /usr/local/lib/libpng.so.2
> libc.so.1 => /usr/lib/libc.so.1
> libXt.so.4 => /usr/openwin/lib/libXt.so.4
> libdl.so.1 => /usr/lib/libdl.so.1
> libmp.so.2 => /usr/lib/libmp.so.2
> libpthread.so.1 => /usr/lib/libpthread.so.1
> /usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1
> libthread.so.1 => /usr/lib/libthread.so.1
>
> I've offered to be a guinea pig for Solaris version of openvrml and CVS
libtool, to see if that's the problem.  Any other suggestions would be
welcome.
>
> Rich Erwin
> Boeing SSG - M&CT Support
> (425) 865-3414
>

[Openvrml-develop] Problems with lookat via Solaris/OpenGL

[Erwin, R. D <Ric...@PS...>]

Chris;

I ran "./configure --enable-static --disable shared", "Gmake check" and "gmake install".  The out put shows that no shared libraries were built.  


checking whether to build shared libraries... no
checking whether to build static libraries... yes

and...

# ls -last /usr/local/lib/libo* | more
 432 -rw-r--r--   1 nobody   nobody    211476 Feb 25 14:23 /usr/local/lib/libopenvrml-gl.a
   2 -rwxr-xr-x   1 nobody   nobody       764 Feb 25 14:23 /usr/local/lib/libopenvrml-gl.la
35792 -rw-r--r--   1 nobody   nobody   18295508 Feb 25 14:22 /usr/local/lib/libopenvrml.a
   2 -rwxr-xr-x   1 nobody   nobody       639 Feb 25 14:22 /usr/local/lib/libopenvrml.la



However...

# lookat ./Anchor.wrl
ld.so.1: lookat: fatal: relocation error: file lookat: symbol sunOglCurPrimTablePtr: referenced symbol not found
Killed

# ldd /usr/local/bin/lookat
	libXmu.so.4 =>	 /usr/openwin/lib/libXmu.so.4
	libXi.so.5 =>	 /usr/openwin/lib/libXi.so.5
	libSM.so.6 =>	 /usr/openwin/lib/libSM.so.6
	libICE.so.6 =>	 /usr/openwin/lib/libICE.so.6
	libX11.so.4 =>	 /usr/openwin/lib/libX11.so.4
	libsocket.so.1 =>	 /usr/lib/libsocket.so.1
	libnsl.so.1 =>	 /usr/lib/libnsl.so.1
	libGLU.so.1 =>	 /usr/local/lib/libGLU.so.1
	libGL.so.1 =>	 /usr/local/lib/libGL.so.1
	libXext.so.0 =>	 /usr/openwin/lib/libXext.so.0
	libm.so.1 =>	 /usr/lib/libm.so.1
	libjpeg.so.62 =>	 /usr/local/lib/libjpeg.so.62
	libpng.so.2 =>	 /usr/local/lib/libpng.so.2
	libc.so.1 =>	 /usr/lib/libc.so.1
	libXt.so.4 =>	 /usr/openwin/lib/libXt.so.4
	libdl.so.1 =>	 /usr/lib/libdl.so.1
	libmp.so.2 =>	 /usr/lib/libmp.so.2
	libpthread.so.1 =>	 /usr/lib/libpthread.so.1
	/usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1
	libthread.so.1 =>	 /usr/lib/libthread.so.1

I've offered to be a guinea pig for Solaris version of openvrml and CVS libtool, to see if that's the problem.  Any other suggestions would be welcome.

Rich Erwin
Boeing SSG - M&CT Support
(425) 865-3414

[Openvrml-develop] FreeBSD port

[Marc v. W. <mar...@sc...>]

Hi,

just wanted to notice you folks that I submitted a FreeBSD port skeleton 
of release 0.9.0 some weeks ago

    http://www.freebsd.org/cgi/query-pr.cgi?pr=24161

and am in the process of submitting an update for 0.10.1 right now.

I hope it will get included in the ports collection soon.


Regards,
Marc

[Openvrml-develop] CVS module name change

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

Completing the name transition for 'LibVRML97' to 'OpenVRML', our primary
CVS module has been changed from 'libvrml97' to 'openvrml'. Persons using
CVS will need to check out from scratch in order to sync up with this
change.

-- 
Braden McDaniel                 It is hard to know if nothing is /
http://endoframe.com            actually nothing
e-mail: br...@en...    And thus difficult to know if a policy /
Jabber: br...@ja...       of doing nothing is successful
                                                -- Radiohead

Re: [Openvrml-develop] VrmlNodePtr patch

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

On Wed, 7 Feb 2001, Braden McDaniel wrote:

> I've uploaded a patch to move the library from using raw VrmlNode pointers
> to VrmlNodePtr, a refcounted smart pointer:
>
> <http://sourceforge.net/patch/index.php?func=detailpatch&patch_id=103653&group_id=7151>

I've recently updated this to use std::map rather than a hash table.
Implementing a hash table that matches the STL pair associative container
interface is a non-trivial task that stands to delay this patch
substantially. Since it is an implementation detail which can be changed
later without affecting the rest of the library, I've opted to postpone
the hash table implementation.

Note that map searches only occur upon construction/destruction of
VrmlNodePtrs; VrmlNode method access still occurs in constant time.

-- 
Braden McDaniel                 It is hard to know if nothing is /
http://endoframe.com            actually nothing
e-mail: br...@en...    And thus difficult to know if a policy /
Jabber: br...@ja...       of doing nothing is successful
                                                -- Radiohead

Re: [Openvrml-develop] Problems with lookat via Solaris/OpenGL

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

On Fri, 23 Feb 2001, Chris Morley wrote:

> Try building the static libs (I think
> "configure --enable-static --disable-dynamic"
> but that's off the top of my head after not doing it for a long time...)
> I never could get the solaris or irix builds to work using dynamic linking
> after the opengl view was put into its own library.

Chris and I were discussing this problem recently. The obvious solution is
to move the GL renderer back into the main library. The only major
drawback to that is that I'd like to eventually convert the GL renderer
(and any others that get introduced) to components in some component
architecture. (I'm not sure which one yet; Bamboo looks most interesting
so far, but there are other candidates.) With respect to that intention,
moving the GL renderer back into the main library is backtracking. OTOH,
actual implementation of this is far enough off that such backtracking
isn't too big of a deal.

However, I think the 1.4 release of libtool isn't too far away, and I
think it includes some improvements in C++ support. Before moving our
sources around again, I'd really like some folks on Irix and Solaris to
try CVS libtool to see if that solves the problem. If you'd like to try
this but are unfamiliar with the tools involved, contact me and I'll do my
best to walk you through what needs to be done.

-- 
Braden McDaniel                 It is hard to know if nothing is /
http://endoframe.com            actually nothing
e-mail: br...@en...    And thus difficult to know if a policy /
Jabber: br...@ja...       of doing nothing is successful
                                                -- Radiohead

[Openvrml-develop] Problems with lookat via Solaris/OpenGL

[Erwin, R. D <Ric...@PS...>]

Chris;

Thanks for the tip.  One problem is gone, but another crops up:

From "ldd lookat" - 

# ldd -d /usr/local/bin/lookat        
        libXmu.so.4 =>   /usr/openwin/lib/libXmu.so.4
        libXi.so.5 =>    /usr/openwin/lib/libXi.so.5
        libSM.so.6 =>    /usr/openwin/lib/libSM.so.6
        libICE.so.6 =>   /usr/openwin/lib/libICE.so.6
        libX11.so.4 =>   /usr/openwin/lib/libX11.so.4
        libsocket.so.1 =>        /usr/lib/libsocket.so.1
        libnsl.so.1 =>   /usr/lib/libnsl.so.1
        libGLU.so.1 =>   /usr/local/lib/libGLU.so.1
        libGL.so.1 =>    /usr/local/lib/libGL.so.1
        libXext.so.0 =>  /usr/openwin/lib/libXext.so.0
        libopenvrml-gl.so.0 =>   /usr/local/lib/libopenvrml-gl.so.0
        libm.so.1 =>     /usr/lib/libm.so.1
        libopenvrml.so.0 =>      /usr/local/lib/libopenvrml.so.0
        libjpeg.so.62 =>         /usr/local/lib/libjpeg.so.62
        libpng.so.2 =>   /usr/local/lib/libpng.so.2
        libc.so.1 =>     /usr/lib/libc.so.1
        libXt.so.4 =>    /usr/openwin/lib/libXt.so.4
        libdl.so.1 =>    /usr/lib/libdl.so.1
        libmp.so.2 =>    /usr/lib/libmp.so.2
        libpthread.so.1 =>       /usr/lib/libpthread.so.1
        /usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1
        symbol not found: sunOglCurPrimTablePtr         (/usr/local/bin/lookat)
        libthread.so.1 =>        /usr/lib/libthread.so.1

Could the problem with /usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1 be due to patches not online for OpenGL for the Suns?  I've added /usr/platform/SUNW,Ultra-5_10/lib to LD_LIBRARY_PATH to see if it makes a difference - so far, no soap.

Thanks in Advance,
RIch Erwin
Boeing SSG - M&CT Support
(425) 865-3414

[Openvrml-develop] EAI

[Joseph S. <jo...@wi...>]

Does OpenVRML support the EAI?

Joseph

Re: [Openvrml-develop] Problems with lookat via Solaris/OpenGL

[Chris M. <cm...@ve...>]

Try building the static libs (I think
"configure --enable-static --disable-dynamic"
but that's off the top of my head after not doing it for a long time...)
I never could get the solaris or irix builds to work using dynamic linking
after the opengl view was put into its own library.

----- Original Message -----
From: "Erwin, Richard D" <Ric...@PS...>
To: <ope...@li...>
Sent: Thursday, February 22, 2001 2:49 PM
Subject: [Openvrml-develop] Problems with lookat via Solaris/OpenGL


> Folks;
>
> I'm a newbie at this, so bear with me...
>
> I'm trying to install openvrml 0.10.1 for a Sun with OpenGL and an
appropriate card for it's use.  (No Mesa libraries involved.)  The OS is
Solaris 2.6.  The compiler  used to build was gcc 2.95.2, and everything was
built with gmake.
>
> When I try to open one of the sample models with lookat (Anchor.wrl and
Click.wrl have been my typical choices), I get a segmentation fault, then a
failure.
>
> gdb gives me the following output:
>
>
> This GDB was configured as "sparc-sun-solaris2.6"...
> Core was generated by `lookat ./Anchor.wrl'.
> Program terminated with signal 11, Segmentation Fault.
> Reading symbols from /usr/openwin/lib/libXmu.so.4...done.
> Reading symbols from /usr/openwin/lib/libXi.so.5...done.
> Reading symbols from /usr/openwin/lib/libSM.so.6...done.
> Reading symbols from /usr/openwin/lib/libICE.so.6...done.
> Reading symbols from /usr/openwin/lib/libX11.so.4...done.
> Reading symbols from /usr/lib/libsocket.so.1...done.
> Reading symbols from /usr/lib/libnsl.so.1...done.
> Reading symbols from /usr/openwin/lib/libGLU.so.1...done.
> Reading symbols from /usr/openwin/lib/libGL.so.1...done.
> Reading symbols from /usr/openwin/lib/libXext.so.0...done.
> Reading symbols from /usr/local/lib/libopenvrml-gl.so.0...done.
> Reading symbols from /usr/lib/libm.so.1...done.
> Reading symbols from /usr/local/lib/libopenvrml.so.0...done.
> Reading symbols from /usr/local/lib/libjpeg.so.62...done.
> Reading symbols from /usr/local/lib/libpng.so.2...done.
> Reading symbols from /usr/lib/libc.so.1...done.
> Reading symbols from /usr/openwin/lib/libXt.so.4...done.
> Reading symbols from /usr/lib/libdl.so.1...done.
> Reading symbols from /usr/lib/libmp.so.2...done.
> Reading symbols from /usr/lib/libintl.so.1...
> warning: Lowest section in /usr/lib/libintl.so.1 is .dynamic at 0x74
> done.
> Reading symbols from /usr/openwin/lib/libdga.so.1...done.
> Reading symbols from /usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1...
> done.
> #0  VrmlNamespace::VrmlNamespace (this=0x5d108, parent=0x0)
>     at
/usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2/../../../../include/g++-3
/stl_iterator.h:264
> 264 {
>
> We make use of Sun and gnu compilers around here, so I've been trying to
be very sure I'm not mixing them up in my PATH and LD_LIBRARY_PATH setups.
>
> Any help would be much appreciated.
>
> Rich Erwin
> Boeing SSG - M&CT Support
> (425) 865-3414
>

[Openvrml-develop] Problems with lookat via Solaris/OpenGL

[Erwin, R. D <Ric...@PS...>]

Folks;

I'm a newbie at this, so bear with me...

I'm trying to install openvrml 0.10.1 for a Sun with OpenGL and an appropriate card for it's use.  (No Mesa libraries involved.)  The OS is Solaris 2.6.  The compiler  used to build was gcc 2.95.2, and everything was built with gmake.

When I try to open one of the sample models with lookat (Anchor.wrl and Click.wrl have been my typical choices), I get a segmentation fault, then a failure.

gdb gives me the following output:


This GDB was configured as "sparc-sun-solaris2.6"...
Core was generated by `lookat ./Anchor.wrl'.
Program terminated with signal 11, Segmentation Fault.
Reading symbols from /usr/openwin/lib/libXmu.so.4...done.
Reading symbols from /usr/openwin/lib/libXi.so.5...done.
Reading symbols from /usr/openwin/lib/libSM.so.6...done.
Reading symbols from /usr/openwin/lib/libICE.so.6...done.
Reading symbols from /usr/openwin/lib/libX11.so.4...done.
Reading symbols from /usr/lib/libsocket.so.1...done.
Reading symbols from /usr/lib/libnsl.so.1...done.
Reading symbols from /usr/openwin/lib/libGLU.so.1...done.
Reading symbols from /usr/openwin/lib/libGL.so.1...done.
Reading symbols from /usr/openwin/lib/libXext.so.0...done.
Reading symbols from /usr/local/lib/libopenvrml-gl.so.0...done.
Reading symbols from /usr/lib/libm.so.1...done.
Reading symbols from /usr/local/lib/libopenvrml.so.0...done.
Reading symbols from /usr/local/lib/libjpeg.so.62...done.
Reading symbols from /usr/local/lib/libpng.so.2...done.
Reading symbols from /usr/lib/libc.so.1...done.
Reading symbols from /usr/openwin/lib/libXt.so.4...done.
Reading symbols from /usr/lib/libdl.so.1...done.
Reading symbols from /usr/lib/libmp.so.2...done.
Reading symbols from /usr/lib/libintl.so.1...
warning: Lowest section in /usr/lib/libintl.so.1 is .dynamic at 0x74
done.
Reading symbols from /usr/openwin/lib/libdga.so.1...done.
Reading symbols from /usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1...
done.
#0  VrmlNamespace::VrmlNamespace (this=0x5d108, parent=0x0)
    at /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2/../../../../include/g++-3/stl_iterator.h:264
264	{

We make use of Sun and gnu compilers around here, so I've been trying to be very sure I'm not mixing them up in my PATH and LD_LIBRARY_PATH setups.

Any help would be much appreciated.

Rich Erwin
Boeing SSG - M&CT Support
(425) 865-3414

Re: [Openvrml-develop] Simple object to object collision detection in OpenVrml

[Christopher K. S. J. <cs...@qu...>]

Patrick AS Sinclair wrote:
> 
> What's the best way to do this?
> 

 Normally picking is done as a separate traversal, so
you'd need to copy the code that walks the geometry
tree, transforming the point as you go. 

 There isn't code to do that right now, since picking
is done 2d using OpenGL's native picking support.

 For an overview of how it might work, were it to be
implemented, check out the Performer or Inventor
documentation at the SGI site.

 I'd kinda like to see something along theses lines,
but nothing is set in stone:

 1) add code to the core-side so the geometry primitves
spit out triangles (meshes? strips? whatever) instead
of calling over to the opengl side. keeping the geometry
over in core side means a simpler, easier to optimize
opengl layer, it also means...

 2) using (1), you can add generic code to do view frustum
culling, since currently the culling code would need to
reproduce much of the code over in the opengl layer, for
example in order to do extrusions. (right now, extrusions
just aren't culled, which means they render slower sometimes
but doesn't cause any other harm)

 3) using (1), we can then add generic code to do ray-based
(or point-based) picking. right now, to do picking against
extrustions, you'd have to reproduce all the extrustion
rendering code yet again. unlike culling, picking has to
work for everything the first time, you can't just do the
easy bits and leave the rest for later.

 4) using (1,3), add terrain following and avatar collision
code.

 Note that 3d-point-based picking is fairly easy, but true
object-object collision detection doesn't fit very well into
the above framework, it's really a totally separate thing,
you'd probably need to glom on something like vcollide (there
are some articles about this is the various VRML conference
proceedings, if anybody is interested)

 Sorry it took so long, my life has been very, hmmm,
"interesting" lately :-)




-cks













-

[Openvrml-develop] Simple object to object collision detection in OpenVrml

[Patrick AS S. <pa...@ec...>]

Hi again,

I posted a message on this group about a month ago about object to object
collision detection. Sorry to take so long to reply but I've spent ages
trying to upgrade the system I'm using to use the latest version of
openVrml.

I can now get a VrmlNode's VrmlBVolume but these are usually centered on
the local coordinate system of the transform it is on top of, not centered
in the global coordinate system.

Root Node
  |_ DEF t1 Transform
  |       |_ DEF t2 Transform
  |       |       |_ ...
  |       |_ DEF t3 Transform
  |               |_ DEF myanchor Anchor
  |_ ...

For example, if I am interested in myanchor's VrmlBVolume center, this is
defined in the local coordinate system of t3, not of the root.

The point I want to check the object has collided with (and yes, basically
I'm trying to implement a 3d mouse pointer) is specified in terms of the
global coordinate system.

What's the best way to do this?

I guess I can try and keep track of the transforms (t1, t2, t3) to
calculate the VrmlBVolume's center in global coordinates manually and then
check for a collision.

Has this already been implemented?

I suppose I could also convert the point's position into each of the
transforms' local coordinate systems.

Or is there another way? I think if I convert the point into a VrmlFrustum
and use VrmlBVolume::isectFrustum to check for a collision. Would this
work?

I would also like to know how long it will be until any other VrmlBVolumes
are implemented (e.g. axis-align boxes, etc).

Thanks,

Patrick Sinclair
---------------------------------------
Patrick AS Sinclair wrote:
>
> I'm using the libVRML97 in my work but I need  very simple object to
> object collision detection. Basically, I want to check whether a point
> is inside certain objects in the scene, such as Anchor nodes. Is there
> an easy way to do this or do I have to calculate the bounding boxes
> etc. and check whether the point is inside them myself?
>

 Check out VrmlNode::getBVolume(), and the comments in VrmlBVolume.h (and
friends). I'm switching jobs right now, so I'm a little overloaded, but if
you've got specific questions, I can probably answer. Note that if you
want exact results, instead of just bvolumes, then you're on your own, and
possibly in for a lot of work. ray-based picking and avatar/object
collision are on the requirements list, but aren't implemented yet. Can
you elaborate on your problem/requirements? (If I had to guess, sounds
like a 3d pointing device?)

-cks

_______________________________________________   
Openvrml-develop mailing list
Ope...@li...
http://lists.sourceforge.net/lists/listinfo/openvrml-develop

Re: [Openvrml-develop] OpenVRML and SGI

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

On 14 Feb 2001, Xavier Decoret wrote:

>
> > That's downright goofy. It looks like something libtool's doing, though.
> > Are you using CVS or a distribution tarball? If you're using CVS, what
> > version of libtool is on your machine?
>
> I am not uisng CVS.  I just downloaded the tar.gz.
> However here is the version of libtool used:
>
> ./libtool --version
> ltmain.sh (GNU libtool) 1.3.4 (1.385.2.196 1999/12/07 21:47:57)

libtool gets included in the tarball dist, so in that case you're using
the same version I am.

Hmm.

My first suspicion is a bug in libtool on Irix. It looks like the latest
version of libtool is 1.3.5. You could try installing that and using the
CVS source for OpenVRML. I'd be very interested in the results.

In light of such problems as this, I'm considering getting rid of the
incremental linking steps (which I suspect are the problem area here).
They aren't buying us a whole lot; when I initially set them up, I thought
they'd save us some external symbols; but they don't.

-- 
Braden McDaniel                 It is hard to know if nothing is /
http://endoframe.com            actually nothing
e-mail: br...@en...    And thus difficult to know if a policy /
Jabber: br...@ja...       of doing nothing is successful
                                                -- Radiohead