openvrml-develop — OpenVRML developers mailing list

RE: RE: [Openvrml-develop] Using OpenVrml for a simulation

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

After some more investigation i found that the member variable d_v in 
a  VrmlMFNode object should contain a list of pointers to its sons.
This member is private so it is not accessible from client programmers.
Should i add a method to the VrmlMFNode to return its sons or is there 
another way to get access to a Node' sons?

Thanks
Luca



Ur Answer is clearing some points and is very 
helpful.
Anyway probably my first question is not well 
formulated: I should have the ability to parse 
all nodes in the Vrml scene graph , not just 
DEFined nodes.

Taking a look at this code:

VrmlMFNode * VrmlScene::readWrl(Doc2 * tryUrl, 
VrmlNamespace * ns)
{
    VrmlMFNode * result =3D 0;
    
    theSystem->debug("readWRL %s\n", tryUrl->url
());
    
    // Should verify MIME type...
    istream & istm =3D tryUrl->inputStream();
    if (istm) {
        
        Vrml97Scanner scanner(istm);
        Vrml97Parser parser(scanner);
        
        //
        // If the caller is not interested in 
PROTO defs, use a local namespace.
        //
        // Note: Can we displace the 
responsibility for this to the caller? Here
        // we instantiate a VrmlNamespace whether 
or not we need it. That could
        // be avoided with new/delete, but the 
resulting code would be awkward
        // and hard to follow. Why not instead 
have the caller pass in a
        // reference to a namespace, and let the 
caller decide whether or not a
        // new namespace should be instantiated?
        // -- Braden McDaniel 
<<EMAIL: PROTECTED>>, 30 Mar, 2000
        //
        VrmlNamespace nodeDefs;
        VrmlNamespace * rootNamespace =3D ns ? ns : 
&nodeDefs;
        
        result =3D new VrmlMFNode();
        try {
            parser.vrmlScene(*result, 
*rootNamespace, tryUrl);
        } catch (std::exception & ex) {
            cerr < ex.what() < endl;
        }
    }
    
    return result;
}

it seems to me that all the parsed scene graph is 
collected in VrmlMFNode * result so i would like 
to know how to parse the resulting tree.

I dont know if i am right since i didnt have the 
time to dig deeply in the library code ( and this 
is an hard task given the amount of code ) but to 
me this ipothesis makes sense even if probably i 
am wrong.
So put in a few word the question is:

if i run something like this:

parser.vrmlScene(*result, *rootNamespace, tryUrl);

is all the World scene graph returned in *result?
How to traverse the resulting object graph?


Greets
Luca

Re: [Fwd: RE: [Openvrml-develop] Using OpenVrml for a simulation]

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

On 03 Aug 2001 14:45:48 +0200, Peter Meier wrote:
> 
> 
> -------- Original Message --------
> Subject: RE: [Openvrml-develop] Using OpenVrml for a simulation
> Date: Wed, 1 Aug 2001 06:24:19 -0700
> From: "luca regini" <luc...@li...>
> Reply-To: "luca regini" <luc...@li...>
> To: me...@iw...
> 
> This message was sent from Geocrawler.com by "luca regini"
> <luc...@li...>

[snip]

> if i run something like this:
> 
> parser.vrmlScene(*result, *rootNamespace, tryUrl);
> 
> is all the World scene graph returned in *result?

Yes.

> How to traverse the resulting object graph?

One way is to implement VrmlNodeVisitor. Look in VrmlNamespace.cpp at
VrmlNodeCloneVisitor for an example.

Unfortunately, we don't yet have a good way for traversing the scene
graph without knowing anything about the node types. I'm planning on
adding a getChildren() method to the VrmlNode interface, which should
help with this.

Braden

[Openvrml-develop] matrix to transform

[Peter M. <me...@iw...>]

Hello,

does anybody know some code to decompose a 4x4 matrix into a vrml
transform?

Thanks,
                Peter

[Fwd: RE: [Openvrml-develop] Using OpenVrml for a simulation]

[Peter M. <me...@iw...>]

-------- Original Message --------
Subject: RE: [Openvrml-develop] Using OpenVrml for a simulation
Date: Wed, 1 Aug 2001 06:24:19 -0700
From: "luca regini" <luc...@li...>
Reply-To: "luca regini" <luc...@li...>
To: me...@iw...

This message was sent from Geocrawler.com by "luca regini"
<luc...@li...>

Ur Answer is clearing some points and is very 
helpful.
Anyway probably my first question is not well 
formulated: I should have the ability to parse 
all nodes in the Vrml scene graph , not just 
DEFined nodes.

Taking a look at this code:

VrmlMFNode * VrmlScene::readWrl(Doc2 * tryUrl, 
VrmlNamespace * ns)
{
    VrmlMFNode * result = 0;
    
    theSystem->debug("readWRL %s\n", tryUrl->url
());
    
    // Should verify MIME type...
    istream & istm = tryUrl->inputStream();
    if (istm) {
        
        Vrml97Scanner scanner(istm);
        Vrml97Parser parser(scanner);
        
        //
        // If the caller is not interested in 
PROTO defs, use a local namespace.
        //
        // Note: Can we displace the 
responsibility for this to the caller? Here
        // we instantiate a VrmlNamespace whether 
or not we need it. That could
        // be avoided with new/delete, but the 
resulting code would be awkward
        // and hard to follow. Why not instead 
have the caller pass in a
        // reference to a namespace, and let the 
caller decide whether or not a
        // new namespace should be instantiated?
        // -- Braden McDaniel 
<br...@en...>, 30 Mar, 2000
        //
        VrmlNamespace nodeDefs;
        VrmlNamespace * rootNamespace = ns ? ns : 
&nodeDefs;
        
        result = new VrmlMFNode();
        try {
            parser.vrmlScene(*result, 
*rootNamespace, tryUrl);
        } catch (std::exception & ex) {
            cerr << ex.what() << endl;
        }
    }
    
    return result;
}

it seems to me that all the parsed scene graph is 
collected in VrmlMFNode * result so i would like 
to know how to parse the resulting tree.

I dont know if i am right since i didnt have the 
time to dig deeply in the library code ( and this 
is an hard task given the amount of code ) but to 
me this ipothesis makes sense even if probably i 
am wrong.
So put in a few word the question is:

if i run something like this:

parser.vrmlScene(*result, *rootNamespace, tryUrl);

is all the World scene graph returned in *result?
How to traverse the resulting object graph?


Greets
Luca

Re: [Openvrml-develop] Re: [Openvrml-announce] ANN: OpenVRML 0.11.0

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

Last time I checked, the CW projects were up to date, no longer contained 
removed files (the 0.10.0 CW project included ScriptJDK...), and included 
new files, but I will double-check. Not sure if it compiles successfully 
though. Last time I trird, it didn't but that at least three months ago. 
The last few times I've been playing with OpenVRML have been under Mac OS 
X (not using CW), where the code compiles and builds OK, but there were 
issues with the command-line build scripts, which needed hacking.

Michael.

On Thursday, August 2, 2001, at 06:53 , Braden McDaniel wrote:

> Er... ScriptJDK.* weren't in 0.10.x either... :-/
>
> Michael, is the Mac CodeWarrior project okay? I'd like to cut 0.11.1 no
> later than the beginning of next week.

[Openvrml-develop] Re: [Openvrml-announce] ANN: OpenVRML 0.11.0

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

On 02 Aug 2001 10:06:59 +0530, S.K.Bose wrote:
> 
> 
> On 30 Jul 2001, Braden McDaniel wrote:
> 
> > OpenVRML 0.11.0 has been released.
> > 
> > OpenVRML is a C++ library for reading and displaying VRML worlds. The
> > OpenVRML distribution includes Lookat, a simple GLUT-based VRML viewer.
> > 
> > Highlights for this release:
> > 
> > * New memory manager for nodes, using a refcounted smart pointer instead
> >   of an intrusive reference count.
> > * Significant reworking of the JavaScript binding. More to come.
> > * Now (optionally) depends on the Mozilla distribution of JavaScript
> >   instead of compiling our own into the library.
> > * libpng and libjpeg are now optional dependencies.
> > * API cleanup for VrmlField classes.
> > * Consolidated node implementations into fewer files.
> > 
> 
> As "ScriptJDK" is not included (I know, it is not functional yet) in this
> distribution, there will be problem in making this OpenVRML lib under
> Win32. I fixed it in OpenVRML-0_11 branch by removing this file from
> compilation in *.dsp and Makefile.* files.

Er... ScriptJDK.* weren't in 0.10.x either... :-/

Michael, is the Mac CodeWarrior project okay? I'd like to cut 0.11.1 no
later than the beginning of next week.

> Now in this release we can have OpenVRML DLLs under Win32.

Yea! Sorry I forgot to include this bullet point in the release
announcement. Thanks for adding it to NEWS.

Braden

[Openvrml-develop] Re: [Openvrml-announce] ANN: OpenVRML 0.11.0

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

On 30 Jul 2001, Braden McDaniel wrote:

> OpenVRML 0.11.0 has been released.
> 
> OpenVRML is a C++ library for reading and displaying VRML worlds. The
> OpenVRML distribution includes Lookat, a simple GLUT-based VRML viewer.
> 
> Highlights for this release:
> 
> * New memory manager for nodes, using a refcounted smart pointer instead
>   of an intrusive reference count.
> * Significant reworking of the JavaScript binding. More to come.
> * Now (optionally) depends on the Mozilla distribution of JavaScript
>   instead of compiling our own into the library.
> * libpng and libjpeg are now optional dependencies.
> * API cleanup for VrmlField classes.
> * Consolidated node implementations into fewer files.
> 

As "ScriptJDK" is not included (I know, it is not functional yet) in this
distribution, there will be problem in making this OpenVRML lib under
Win32. I fixed it in OpenVRML-0_11 branch by removing this file from
compilation in *.dsp and Makefile.* files.

Now in this release we can have OpenVRML DLLs under Win32.

Bose

Re: [Openvrml-develop] Using OpenVrml for a simulation

[Peter M. <me...@iw...>]

Hello Luca,
I am also pretty new to the lib, but I had similar questions before.

> 1) Parse the scene graph to find geometry nodes toghether with their
> attributes to perform some basic collision detection.
>

I don't know about collision detection, but here's the code to find a node:

if ((VrmlScene->scope())->findNode("MYTR"))

myTransformNode=((m_pVrmlScene->scope())->findNode("MYTR"))->toTransform();

where MYTR is a DEF in the WRL. In this case it's a transform. In other
cases the last method
is 'toNode()'

> 2) Modify a node attributes and eventually adding and deleting
> dynamically nodes from the world so to "animate" avatars in the world.
>

check out the set field method of the nodetype you want to work with. Give
it what it wants.
In this case I pass a VrmlSFRotation to the rotation field of a transform.

VrmlSFRotation testRot(0.0, 1.0, 0.0, 0.1*m_ms); //x,y,z,rotation
  m_pTransformNode->setField("rotation",testRot);

Unfortunately I haven't tried to dynamically add and delete nodes in a
scene. It's easy with nodes
like background, but I don't know how to insert a transform at a certain
point in the scenegraph.

I hope I could help a bit,

Peter

[Openvrml-develop] Using OpenVrml for a simulation

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

I'm working on a simulation for my university and since we have already 
developed many Vrml models i would like to use OpenVrml as the main 
support library for this work.
In order to do so i have to solve the following issues:

1) Parse the scene graph to find geometry nodes toghether with their 
attributes to perform some basic collision detection.
2) Modify a node attributes and eventually adding and deleting 
dynamically nodes from the world so to "animate" avatars in the world.
3) Modify the parser structure ( and the library ) so to support more 
attributes ( to describe other properties of the object that are not 
related to visual appearance ( i.e. velocity and acceleration ) but 
that are important for my simulation )

Is there anyone that can give me some suggestion ?
Any kind of feedback would be very appreciated.
Also, since i am going to work on this project for at least 3 months 
full-time i can try, if given enough support, to write the beginning of 
an openvrml developer documentation.

Thanks in advance
Luca Regini

Re: [Openvrml-develop] [ #208849 ] Problems w/events into PROTOs

[Nigel S. <ni...@ni...>]

Braden,

Not to worry, I'm just glad to confirm that libVRML is going
forward, and hasn't become another Cosmo... :-)

Nigel

> I'm fairly sure that this *is* fixable in the current PROTO
> implementation framework, but I'd prefer to address it after this task
> is complete:
> 
> http://sourceforge.net/pm/task.php?func=detailtask&project_task_id=25969&group_id=7151&group_project_id=2579
> 
> As you can see, this is a high-priority item; the only thing ahead of it
> in my queue is conversion to use of the std::string type.
> 
> As far as a time frame for completing this work... I'll say,
> optimistically, by the end of August.

--
                     Nigel Stewart    
     Email: ni...@ni...  WWW: http://www.nigels.com
         Research Student, Software Developer.
      Just two stops down the line at Zoo Station.

[Openvrml-develop] Re: [www-vrml] ANN: OpenVRML 0.11.0

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

On 30 Jul 2001 09:07:23 -0700, clayton cottingham wrote:
> Braden McDaniel wrote:
> > 
> > OpenVRML 0.11.0 has been released.
> > 
> > OpenVRML is a C++ library for reading and displaying VRML worlds. The
> > OpenVRML distribution includes Lookat, a simple GLUT-based VRML viewer.
> > 
> > Highlights for this release:
> > 
> > * New memory manager for nodes, using a refcounted smart pointer instead
> >   of an intrusive reference count.
> > * Significant reworking of the JavaScript binding. More to come.
> > * Now (optionally) depends on the Mozilla distribution of JavaScript
> >   instead of compiling our own into the library.
> > * libpng and libjpeg are now optional dependencies.
> > * API cleanup for VrmlField classes.
> > * Consolidated node implementations into fewer files.
> > 
> > -------------------------------------------------------------------------
> > for list subscription instructions,
> > send email to www...@we... with text "info"
> 
> 
> Braden: this is wicked!
> 
> i was wondering what version of the javascript engine should be used?
> or at least is know to work
> 
> 1.5-rc3 or the 1.5rc3a?

The most recent one. (The latter.)

> i would also suggest possibly including a link to
> ftp://ftp.mozilla.org/pub/js/
> so ppl know where to down load the spidermonkey libs 
> ;)

It's in the README, under "Optional features".

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

[Openvrml-develop] Re: [www-vrml] ANN: OpenVRML 0.11.0

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

Braden McDaniel wrote:
> 
> OpenVRML 0.11.0 has been released.
> 
> OpenVRML is a C++ library for reading and displaying VRML worlds. The
> OpenVRML distribution includes Lookat, a simple GLUT-based VRML viewer.
> 
> Highlights for this release:
> 
> * New memory manager for nodes, using a refcounted smart pointer instead
>   of an intrusive reference count.
> * Significant reworking of the JavaScript binding. More to come.
> * Now (optionally) depends on the Mozilla distribution of JavaScript
>   instead of compiling our own into the library.
> * libpng and libjpeg are now optional dependencies.
> * API cleanup for VrmlField classes.
> * Consolidated node implementations into fewer files.
> 
> -------------------------------------------------------------------------
> for list subscription instructions,
> send email to www...@we... with text "info"


Braden: this is wicked!

i was wondering what version of the javascript engine should be used?
or at least is know to work

1.5-rc3 or the 1.5rc3a?

i would also suggest possibly including a link to
ftp://ftp.mozilla.org/pub/js/
so ppl know where to down load the spidermonkey libs 
;)

it took me a good ten minutes to google it up
ttfn

[Openvrml-develop] Re: ANN: OpenVRML 0.11.0

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

On 30 Jul 2001 03:00:41 -0400, Braden McDaniel wrote:
> OpenVRML 0.11.0 has been released.
> 
> OpenVRML is a C++ library for reading and displaying VRML worlds. The
> OpenVRML distribution includes Lookat, a simple GLUT-based VRML viewer.
> 
> Highlights for this release:
> 
> * New memory manager for nodes, using a refcounted smart pointer instead
>   of an intrusive reference count.
> * Significant reworking of the JavaScript binding. More to come.
> * Now (optionally) depends on the Mozilla distribution of JavaScript
>   instead of compiling our own into the library.
> * libpng and libjpeg are now optional dependencies.
> * API cleanup for VrmlField classes.
> * Consolidated node implementations into fewer files.

It occurs to me that a few people reading this might be interested to
know where to get OpenVRML:

<http://sourceforge.net/project/showfiles.php?group_id=7151>

(This is what I get for making release announcments after 3 am.)

[Openvrml-develop] OpenVRML 0.11.x

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

Per the announcement, version 0.11.0 finally managed to escape. In
anticiaption of future bugfix releases in the 0.11 line, I have already
created a 0.11 branch. The branch tag name is "OpenVRML-0_11".

*** If you are checking in changes that ought to appear in a 0.11.x
release, check them in on the OpenVRML-0_11 branch. ***

The changes will subsequently be merged into the main line of
development. Note that changes checked into the OpenVRML-0_11 branch
should be bugfixes, not new functionality or changes to public
interfaces.

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

[Openvrml-develop] ANN: OpenVRML 0.11.0

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

OpenVRML 0.11.0 has been released.

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

Highlights for this release:

* New memory manager for nodes, using a refcounted smart pointer instead
  of an intrusive reference count.
* Significant reworking of the JavaScript binding. More to come.
* Now (optionally) depends on the Mozilla distribution of JavaScript
  instead of compiling our own into the library.
* libpng and libjpeg are now optional dependencies.
* API cleanup for VrmlField classes.
* Consolidated node implementations into fewer files.

Re: [Openvrml-develop] get certain node from Scene

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

On 27 Jul 2001 18:26:10 +0200, Peter Meier wrote:
> does anybody know if there's a way to get a named transform node from a
> scene in order to manipulate part of the scene? Otherwise, what would be
> a decent hack?

    scene.scope()->findNode(nodeId);

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

[Openvrml-develop] get certain node from Scene

[Peter M. <me...@iw...>]

Hello,

does anybody know if there's a way to get a named transform node from a
scene in order to manipulate part of the scene? Otherwise, what would be
a decent hack?

Thanks in advance,
                                    Peter

Re: [Openvrml-develop] [ #208849 ] Problems w/events into PROTOs

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

On 25 Jul 2001 15:18:38 +0100, Jamie Walch wrote:
> > Looking around for a solid VRML browsing platform for Linux,
> > we've been experimenting with libVRML lookat.  Generally,
> > things are fine - but it seems we're hitting one of the
> > bugs on the list: Problems w/events into PROTOs
> >
> > Since we want our students to do H-anim work, typically
> > using PROTO's - this is a bit of a show-stopper.
> > Could someone comment on the status of this bug,
> > whether it's easily fixed, or related to some deep
> > design issue that is not so likely to be resolved in
> > a hurry.
> 
> This may or may not be the same problem, but I've been having difficulties
> with some PROTOs whereby the parser tells me a particular field does not
> exist when it clearly does. In these cases I find that DEFining the
> offending node gets the file through the parser and everything works fine.
> http://www-lce.eng.cam.ac.uk/~jpw20/Door.wrl demonstrates the problem; most
> (if not all) of the DEFs are not needed, but without them, although the file
> still renders correctly, events are not routed correctly (so that, for
> example, it's not possible to have a open door using this PROTO without the
> DEFs).

Hrm... Very interesting. Thanks!

(But those errors are from the PROTO implementation, not the parser. :-)

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

Re: [Openvrml-develop] [ #208849 ] Problems w/events into PROTOs

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

On 25 Jul 2001 23:35:38 +1000, Nigel Stewart wrote:
> 
> Hi all,
> 
> Looking around for a solid VRML browsing platform for Linux,
> we've been experimenting with libVRML lookat.  Generally,
> things are fine - but it seems we're hitting one of the
> bugs on the list: Problems w/events into PROTOs
> 
> Since we want our students to do H-anim work, typically
> using PROTO's - this is a bit of a show-stopper.
> Could someone comment on the status of this bug,
> whether it's easily fixed, or related to some deep
> design issue that is not so likely to be resolved in
> a hurry.

Much of what I'm doing with the library these days involves improving
"deep design issues." Unfortunately, this work is a bit slow-going.

I'm fairly sure that this *is* fixable in the current PROTO
implementation framework, but I'd prefer to address it after this task
is complete:

http://sourceforge.net/pm/task.php?func=detailtask&project_task_id=25969&group_id=7151&group_project_id=2579

As you can see, this is a high-priority item; the only thing ahead of it
in my queue is conversion to use of the std::string type.

As far as a time frame for completing this work... I'll say,
optimistically, by the end of August.

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

Re: [Openvrml-develop] [ #208849 ] Problems w/events into PROTOs

[Jamie W. <jp...@ca...>]

> Looking around for a solid VRML browsing platform for Linux,
> we've been experimenting with libVRML lookat.  Generally,
> things are fine - but it seems we're hitting one of the
> bugs on the list: Problems w/events into PROTOs
>
> Since we want our students to do H-anim work, typically
> using PROTO's - this is a bit of a show-stopper.
> Could someone comment on the status of this bug,
> whether it's easily fixed, or related to some deep
> design issue that is not so likely to be resolved in
> a hurry.

This may or may not be the same problem, but I've been having difficulties
with some PROTOs whereby the parser tells me a particular field does not
exist when it clearly does. In these cases I find that DEFining the
offending node gets the file through the parser and everything works fine.
http://www-lce.eng.cam.ac.uk/~jpw20/Door.wrl demonstrates the problem; most
(if not all) of the DEFs are not needed, but without them, although the file
still renders correctly, events are not routed correctly (so that, for
example, it's not possible to have a open door using this PROTO without the
DEFs).

Hope this helps,

Jamie Walch

---
LCE, Cambridge University Engineering Department
Email: jp...@ca...,      Tel: (01223) 766513

"I love my work. I could sit looking at it all day."

[Openvrml-develop] [ #208849 ] Problems w/events into PROTOs

[Nigel S. <ni...@ni...>]

Hi all,

Looking around for a solid VRML browsing platform for Linux,
we've been experimenting with libVRML lookat.  Generally,
things are fine - but it seems we're hitting one of the
bugs on the list: Problems w/events into PROTOs

Since we want our students to do H-anim work, typically
using PROTO's - this is a bit of a show-stopper.
Could someone comment on the status of this bug,
whether it's easily fixed, or related to some deep
design issue that is not so likely to be resolved in
a hurry.

PS:  We're using the latest source tgz, not a cvs image,
at the moment.

Nigel Stewart

--
                     Nigel Stewart    
     Email: ni...@ni...  WWW: http://www.nigels.com
         Research Student, Software Developer.
      Just two stops down the line at Zoo Station.

Re: [Openvrml-develop] CVS openvrml/lookat compile problem--

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

On Mon, 2 Jul 2001, Gerall Kahla wrote:

> Dudes (and any Ladies listening)--
>
>   While trying to build the 'lookat' binary, my linker isn't finding
>   gluTessBeginPolygon / gluTessEndPolygon /
>   gluBeginContour / gluEndContour in the libopenvrml-gl.so that gets
>   built in openvrml/src/openvrml-gl/OpenVRML/GL/.libs
>
> This is a problem with Mesa-3.4.2?

FWIW, I'm using 3.4 here and not seeing this.

>  Or is this a glut problem?

These are GLU functions, not glut. So I think not. Do make sure you have
the GLU library installed. (This is a standard part of Mesa.)

>  I'm
> not familiar enough with the libs in question to tell...  This is on
> an openvrml CVS checkout that happened last night.  Did I just check
> this out at the wrong time?

The stuff in CVS compiles for me. I'm using Red Hat 7.1.

I'm not sure what to tell you but to try the usual stuff: make sure your
build tools are up-to-date; make sure you can compile other code that uses
these methods; see if the problem crops up in static as well as shared
libs.

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

Re: [Openvrml-develop] CVS openvrml/lookat compile problem--

[Gerall K. <ge...@ch...>]

"Tom Flynn" <tf...@us...> writes:

> I get a very similar problem to this at runtime with one of the conformance
> tests (can't remember which one, but will find out). Have these functions
> been deprecated somewhere along the way in Mesa?

Wow!  Someone else who's seeing these errors, but at runtime?!?  Does
the compile of lookat generate any interesting warnings?

> I can at least get lookat
> to compile on my system but I do get runtime issues similar to this.
> (suspect I have some old Mesa header files/libs somewhere on my system.)

Yeah, I need to look for the old "stale headers" problem on my system,
too.  Mesa / Glut is the only library I've upgraded from a stock
install, and with my luck I didn't get all the old install cleaned
up.  I'll let you know if this turns up something...

Best regards--

-- 
Gerall Kahla -- the Celestial Mechanic
<URI:http://chromebob.com>                homepage
<URI:http://chromebob.com/public-key.asc> GnuPG public key

Re: [Openvrml-develop] CVS openvrml/lookat compile problem--

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

I get a very similar problem to this at runtime with one of the conformance
tests (can't remember which one, but will find out). Have these functions
been deprecated somewhere along the way in Mesa? I can at least get lookat
to compile on my system but I do get runtime issues similar to this.
(suspect I have some old Mesa header files/libs somewhere on my system.)

Tom

----- Original Message -----
From: "Gerall Kahla" <ge...@ch...>
To: <ope...@li...>
Sent: Monday, July 02, 2001 7:10 PM
Subject: [Openvrml-develop] CVS openvrml/lookat compile problem--


> Dudes (and any Ladies listening)--
>
>   While trying to build the 'lookat' binary, my linker isn't finding
>   gluTessBeginPolygon / gluTessEndPolygon /
>   gluBeginContour / gluEndContour in the libopenvrml-gl.so that gets
>   built in openvrml/src/openvrml-gl/OpenVRML/GL/.libs
>
> This is a problem with Mesa-3.4.2?  Or is this a glut problem?  I'm
> not familiar enough with the libs in question to tell...  This is on
> an openvrml CVS checkout that happened last night.  Did I just check
> this out at the wrong time?
>
>   Thanks for any feedback--
>
> --
> Gerall Kahla -- the Celestial Mechanic
> <URI:http://chromebob.com>                homepage
> <URI:http://chromebob.com/public-key.asc> GnuPG public key
>
>
> _______________________________________________
> Openvrml-develop mailing list
> Ope...@li...
> http://lists.sourceforge.net/lists/listinfo/openvrml-develop
>

[Openvrml-develop] CVS openvrml/lookat compile problem--

[Gerall K. <ge...@ch...>]

Dudes (and any Ladies listening)--

  While trying to build the 'lookat' binary, my linker isn't finding
  gluTessBeginPolygon / gluTessEndPolygon / 
  gluBeginContour / gluEndContour in the libopenvrml-gl.so that gets
  built in openvrml/src/openvrml-gl/OpenVRML/GL/.libs

This is a problem with Mesa-3.4.2?  Or is this a glut problem?  I'm
not familiar enough with the libs in question to tell...  This is on
an openvrml CVS checkout that happened last night.  Did I just check
this out at the wrong time?

  Thanks for any feedback--

-- 
Gerall Kahla -- the Celestial Mechanic
<URI:http://chromebob.com>                homepage
<URI:http://chromebob.com/public-key.asc> GnuPG public key