openvrml-develop — OpenVRML developers mailing list

Re: [openvrml-develop] Re: VrmlMatrix

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

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

Re: [openvrml-develop] Project settings for openvrml linking...

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

On Thu, 11 Oct 2001, -colin sprague- wrote:

> Guepa!
> 
> I have downloaded and am attempting to compile openvrml 0.11.1 and have 
> encountered the following linking error using Visual C++:
> 
> Linking...
>    Creating library Debug/openvrml.lib and object Debug/openvrml.exp
> zlib.lib(gzio.obj) : error LNK2001: unresolved external symbol _errno
> 

Go through "How to build other libraries" in the file
openvrml\ide-projects\Windows\VisualC6\Install or download compiled
version "win32_required_libs.zip" from <http://openvrml.org/dist>

Thanks,

Bose

[openvrml-develop] Project settings for openvrml linking...

[-colin sprague- <col...@ho...>]

Guepa!

I have downloaded and am attempting to compile openvrml 0.11.1 and have 
encountered the following linking error using Visual C++:

Linking...
   Creating library Debug/openvrml.lib and object Debug/openvrml.exp
zlib.lib(gzio.obj) : error LNK2001: unresolved external symbol _errno

What project settings are recommended so that it will link correctly?

Thanks for any response,

-colin-


_________________________________________________________________
Descargue GRATUITAMENTE MSN Explorer en http://explorer.msn.es/intl.asp

[openvrml-develop] More than One Viewer per application

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

Is it possible to use more than one viewer in each application, where 
each viewer renders the same vrmlscene but from different viewpoints.

Are there any difficul issues arising?

Greets
Luca

Re: [openvrml-develop] Re: VrmlMatrix

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

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

[openvrml-develop] Re: VrmlMatrix

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

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

Re: [openvrml-develop] VrmlMatrix Class

[Christopher K. S. J. <ck...@di...>]

"S.K.Bose" wrote:
> 
> 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).
> 

 C++ has a lot of crap features, but overloaded
operators are the absolute worst.

[openvrml-develop] VrmlMatrix Class

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

Hi all,

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?

Bose 

Re: [openvrml-develop] set multifield?

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

> "string" is an MFString, so you need to use a VrmlMFString when setting
> it.
> Braden McDaniel                           e-mail: <br...@en...>

Hi again,

thanks for the reply, I fixed that, but it still doesn't work. Here's my
new, ugly code
(I admit I am not very good when it comes to const char * const* datatypes):

const char* valuefield[10];
const char lala[]="hello";
const char lala2[]="hello2";
valuefield[0]=lala;
valuefield[1]=lala2;
VrmlMFString fld(2, valuefield);

//this test works: fld seems to be OK and I can retrieve hello and hello2
const char*const * valuetestfield;
valuetestfield=fld.get();

//but this doesn't move anything...
m_pVRMLNode->setField(strfield, fld);

Any hints are, as always, very welcome. I am working with version 0.10.1 on
Windows.

Peter

Re: [openvrml-develop] set multifield?

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

On Wed, 2001-10-03 at 16:17, Peter Meier wrote:
> Hello,
> 
> I am setting SF with the function setField and it work's great. But I
> could not get any of the multifields to work. Especially the string
> field of the Text node. Any hints?
> 
> here's my call:
> 
> CString strfield(field);
> CString strvalue(value);
> 
> VrmlSFString fld(strvalue);
> m_pVRMLNode->setField(strfield, fld);

"string" is an MFString, so you need to use a VrmlMFString when setting
it.

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

[openvrml-develop] set multifield?

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

Hello,

I am setting SF with the function setField and it work's great. But I
could not get any of the multifields to work. Especially the string
field of the Text node. Any hints?

here's my call:

CString strfield(field);
CString strvalue(value);

VrmlSFString fld(strvalue);
m_pVRMLNode->setField(strfield, fld);


Thanks in advance,    Peter

Re: [openvrml-develop] Proximity sensor problem

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

On Fri, 28 Sep 2001, Javier Taibo wrote:

> 
>   Hello all,
> 
>   I am using OpenVRML 0.11.1 and I have detected a problem with the proximity sensors.
> Sometimes the camera seems to go in and out of the sensor while it is completely inside.
> The "inside" condition in the VrmlNodeProximitySensor::render method is computed
> with the position of the camera obtained with a call to ViewerOpenGL::getPosition()
> 
>   What I have observed is that the getPosition() method computes the position of the
> camera from the OpenGL matrices calling gluUnproject()
> 
>   The weird thing here is that while the position of the camera doesn't move, it only
> rotates, the values of x, y and z returned by getPosition are different! Also, this values
> are different from the position of the camera I establish in my program.
> 
>   Has anybody noticed this?  What could be the problem?

I have noticed in getOrientation() but not in getPosition(). For
getOrientation() I have fixed it. Please can you put this bug in
<http://sourceforge.net/tracker/?atid=107151&group_id=7151&func=browse>

Thanks,

Bose

Re: [openvrml-develop] request for comments : aperlmoduleforopenvrml

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

Braden McDaniel wrote:
> 
> On Fri, 2001-09-28 at 16:51, clayton cottingham wrote:
> > now i just have to try to
> > figure out the calls to VRML97Parser...
> 
> As I have said, Vrml97Parser is not part of the public API. It should be
> sufficient for your purposes just to construct a VrmlScene.
> 

ok 
i wasnt sure if public was 
in a strict programming sense 
or just that you meant not 
used much by people

i will continue getting 
my VRMLScene call to work 

hopefully i'll have something
by monday








> --
> Braden McDaniel                           e-mail: <br...@en...>
> <http://endoframe.com>                    Jabber: <br...@ja...>
> 
> _______________________________________________
> openvrml-develop mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openvrml-develop

Re: [openvrml-develop] request for comments : a perlmoduleforopenvrml

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

On Fri, 2001-09-28 at 16:51, clayton cottingham wrote:
> now i just have to try to 
> figure out the calls to VRML97Parser...

As I have said, Vrml97Parser is not part of the public API. It should be
sufficient for your purposes just to construct a VrmlScene.

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

Re: [openvrml-develop] request for comments : a perlmoduleforopenvrml

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

Braden McDaniel wrote:
> 
> On Fri, 2001-09-28 at 15:41, clayton cottingham wrote:
> > could you
> > let me know if there is a way
> > {in C++} to access/send a file/stream
> > to the VRML97Parser functions
> > and get an answer back to its validity/parsability as a vrml doc?
> 
> Yes. If you don't get any error output, it should have succeeded.
> 

ok

> If you're asking whether the calling context will get any indication of
> whether or not the parse completely succeeded, the answer is, "Probably
> not." ANTLR's error handling uses exceptions. Our use of this error
> handling could be tuned quite a bit more than it is now. Ideally no
> exception should ever propagate up to the top level, but I can't rule
> this out right now. It's not something you should depend on.
> 

hmmm.

ok i get it

now i just have to try to 
figure out the calls to VRML97Parser...





> --
> Braden McDaniel                           e-mail: <br...@en...>
> <http://endoframe.com>                    Jabber: <br...@ja...>
> 
> _______________________________________________
> openvrml-develop mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openvrml-develop

Re: [openvrml-develop] request for comments : a perl moduleforopenvrml

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

On Fri, 2001-09-28 at 15:41, clayton cottingham wrote:
> could you
> let me know if there is a way
> {in C++} to access/send a file/stream 
> to the VRML97Parser functions
> and get an answer back to its validity/parsability as a vrml doc?

Yes. If you don't get any error output, it should have succeeded.

If you're asking whether the calling context will get any indication of
whether or not the parse completely succeeded, the answer is, "Probably
not." ANTLR's error handling uses exceptions. Our use of this error
handling could be tuned quite a bit more than it is now. Ideally no
exception should ever propagate up to the top level, but I can't rule
this out right now. It's not something you should depend on.

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

Re: [openvrml-develop] request for comments : a perl moduleforopenvrml

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

Braden McDaniel wrote:
> 
> On Fri, 2001-09-28 at 01:35, Clayton Cottingham aka drfrog wrote:
> >
> > this is true xml and vrml parsing are way different
> >  but i should be able to give designers
> > a way to test their code against openvrml for syntax errors without
> > nessicarily having openvrml running on their machine
> > -or for testing aganst diff versions!
> > -or maybe for running/autmoating against nist tests for instance?
> 
> Well, as I've said, OpenVRML just emits its errors to stderr. A CGI
> script should be able to intercept this and put it on a Web page.
> 
> Since the NIST tests tend to require visual inspection, I don't think
> they can be automated.
> 

yup but if the work invlolved could be reduced 
everyone would be happy



> > cool basically at this point if i could get yay
> > or error line X
> > or illegall node / field yadda
> > id be happy!
> 
> You have that in the stderr output. Except that there is currently a bug
> with our line number reporting.
> 

i looked over the antlr stuff
i have to say thats getting way ahead of myself!!

could you
let me know if there is a way
{in C++} to access/send a file/stream 
to the VRML97Parser functions
and get an answer back to its validity/parsability as a vrml doc?

basically a thumbs up or down 
situation for now would be cool enough
for now from my perspective



i cant recall , did i answer this?:
   OpenVRML already parses and validates its input. What kind of
   application are you envisioning?


basically i want to provide 
wrapper so ppl can test 
validity against openvrml
from a server script!







> --
> Braden McDaniel                           e-mail: <br...@en...>
> <http://endoframe.com>                    Jabber: <br...@ja...>
> 
> _______________________________________________
> openvrml-develop mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openvrml-develop

Re: [openvrml-develop] request for comments : a perl module foropenvrml

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

On Fri, 2001-09-28 at 01:35, Clayton Cottingham aka drfrog wrote:
> 
> this is true xml and vrml parsing are way different
>  but i should be able to give designers
> a way to test their code against openvrml for syntax errors without
> nessicarily having openvrml running on their machine
> -or for testing aganst diff versions!
> -or maybe for running/autmoating against nist tests for instance?

Well, as I've said, OpenVRML just emits its errors to stderr. A CGI
script should be able to intercept this and put it on a Web page.

Since the NIST tests tend to require visual inspection, I don't think
they can be automated.

> cool basically at this point if i could get yay
> or error line X 
> or illegall node / field yadda
> id be happy!

You have that in the stderr output. Except that there is currently a bug
with our line number reporting.

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

Re: [openvrml-develop] request for comments : a perl module for openvrml

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

Hello,

>I don't know what XCMD or XTRA are.

think of them as API's for accessing C or C++ from an Xtalk type language.
Examples of Xtalk languages are SuperTalk (SuperCard), MetaTalk (MetaCard),
Lingo (Director), HyperCard (Apple) and AppleScript (Apple). XCMDS's are
used in HyperCard and SuperTalk and possibly others. Xtra's are for
Director.

By the way, every now and then I'll talk about VI's and CIN's. These are
related to the programming language (G) used by Labview. G is a parallel
dataflow language that is graphical in nature. VI's are the actual code in
graphical form. CIN's are the XCMD equivalents of Labview.

John F. Richardson

[openvrml-develop] Proximity sensor problem

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

  Hello all,

  I am using OpenVRML 0.11.1 and I have detected a problem with the proxi=
mity sensors.
Sometimes the camera seems to go in and out of the sensor while it is com=
pletely inside.
The "inside" condition in the VrmlNodeProximitySensor::render method is c=
omputed
with the position of the camera obtained with a call to ViewerOpenGL::get=
Position()

  What I have observed is that the getPosition() method computes the posi=
tion of the
camera from the OpenGL matrices calling gluUnproject()

  The weird thing here is that while the position of the camera doesn't m=
ove, it only
rotates, the values of x, y and z returned by getPosition are different! =
Also, this values
are different from the position of the camera I establish in my program.

  Has anybody noticed this?  What could be the problem?

  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] request for comments : a perl module foropenvrml

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

Time Co-Ordinate 27 Sep 2001 23:47:20 -0400, The Organism labeled Braden
McDaniel said:

> On Thu, 2001-09-27 at 22:41, clayton wrote:
>  > i think my model here was Matt Sergeant's 
>  > {of axkit fame amongst others}
>  > XML::LibXML and XML::LibXSLT
>  > http://search.cpan.org
>  > 
>  > were made using perl's xs to wrap
>  > around xmlsoft.org's
>  >  libxml and libxslt
>  
>  XML parsers have significantly different obligations from VRML parsers.
>  XML is a metalanguage. An XML parser functions as a substrate for
>  higher-level parsing. Thus the typical yield from an XML parser is
>  something akin to a syntax tree. Most applications would want a VRML
>  parser to yield a scene graph.
>  

this is true xml and vrml parsing are way different
 but i should be able to give designers
a way to test their code against openvrml for syntax errors without
nessicarily having openvrml running on their machine
-or for testing aganst diff versions!
-or maybe for running/autmoating against nist tests for instance?



>  [tangent time...]
>  
>  In general, VRML scene graphs do not directly map to a serialized form.
>  However, the ability to serialize scene graphs has been an important
>  feature in OpenVRML. I think it is important that we keep this; but let
>  me tell you, it makes managing scopes a *bitch*.
>  
>  Imagine a vrmlstring with a PROTO inside it. A script calls
>  createVrmlFromString(), and sends the resulting MFNode to a Group in the
>  scene. Now, the VRML97 spec sez that the vrmlstring's scope is unique.
>  So where do we hang the PROTO definition in the serialized output?
>  

yikes !
thats a whoop@-^ size of 
giant can o worms!

>  Ultimately I decided that the world's scope should sprout a new node
>  type in response to this kind of action. But this isn't so
>  straightforward either. What if the world's scope already has a
>  conflicting type? The conflict must be resolved by arbitrarily changing
>  the name of the new type. What it comes down to is that there's no way
>  to behave in a fashion that's likely to be predictable to users 100% of
>  the time.
>  
>  > what i need to know is how to call the parsing and validating routines/sub/functions/...
>  >  without calling the display routines 
>  > then i could call those
>  > methods directly and use those 
>  > infos to generate a report of some sort
>  > 
>  > {mostly straight out for now}
>  
>  That would be the Vrml97Parser class. This is code generated by ANTLR.
>  It is not part of the public API. These methods are used to construct a
>  scene graph, not a syntax tree.
>  
>  If it's a syntax tree you want, your best bet is to simply use
>  OpenVRML's ANTLR grammar as a starting point. Look at Vrml97Parser.g and
>  the ANTLR documentation. ANTLR has support for Abstract Syntax Trees,
>  but we do not use this in OpenVRML. Of course, the ANTLR grammar could
>  be extended in that direction for your application.
>  

cool basically at this point if i could get yay
or error line X 
or illegall node / field yadda
id be happy!


>  > btw an easy c wrapper might be to use perl as a middle man!
>  
>  I rather doubt that.
>  


after your explain i doubt its as easy as i thought !

Re: [openvrml-develop] request for comments : a perl module for openvrml

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

On Thu, 2001-09-27 at 22:41, clayton wrote:
> i think my model here was Matt Sergeant's 
> {of axkit fame amongst others}
> XML::LibXML and XML::LibXSLT
> http://search.cpan.org
> 
> were made using perl's xs to wrap
> around xmlsoft.org's
>  libxml and libxslt

XML parsers have significantly different obligations from VRML parsers.
XML is a metalanguage. An XML parser functions as a substrate for
higher-level parsing. Thus the typical yield from an XML parser is
something akin to a syntax tree. Most applications would want a VRML
parser to yield a scene graph.

[tangent time...]

In general, VRML scene graphs do not directly map to a serialized form.
However, the ability to serialize scene graphs has been an important
feature in OpenVRML. I think it is important that we keep this; but let
me tell you, it makes managing scopes a *bitch*.

Imagine a vrmlstring with a PROTO inside it. A script calls
createVrmlFromString(), and sends the resulting MFNode to a Group in the
scene. Now, the VRML97 spec sez that the vrmlstring's scope is unique.
So where do we hang the PROTO definition in the serialized output?

Ultimately I decided that the world's scope should sprout a new node
type in response to this kind of action. But this isn't so
straightforward either. What if the world's scope already has a
conflicting type? The conflict must be resolved by arbitrarily changing
the name of the new type. What it comes down to is that there's no way
to behave in a fashion that's likely to be predictable to users 100% of
the time.

> what i need to know is how to call the parsing and validating routines/sub/functions/...
>  without calling the display routines 
> then i could call those
> methods directly and use those 
> infos to generate a report of some sort
> 
> {mostly straight out for now}

That would be the Vrml97Parser class. This is code generated by ANTLR.
It is not part of the public API. These methods are used to construct a
scene graph, not a syntax tree.

If it's a syntax tree you want, your best bet is to simply use
OpenVRML's ANTLR grammar as a starting point. Look at Vrml97Parser.g and
the ANTLR documentation. ANTLR has support for Abstract Syntax Trees,
but we do not use this in OpenVRML. Of course, the ANTLR grammar could
be extended in that direction for your application.

> btw an easy c wrapper might be to use perl as a middle man!

I rather doubt that.

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

Re: [openvrml-develop] request for comments : a perl module for openvrml

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

hello:

snipping to conserve b/w

>
>I don't know what XCMD or XTRA are.
>

afaik:
director objects?

>
>If you want to be able to write a Perl/Python/Whatever script that will
>itself be intimately involved in the parse, OpenVRML is the wrong tool
>for the job. OpenVRML's parser is intended to function like a black box:
>you hand it a stream, and it does it's best to load it, spewing errors
>if appropriate. There are no hooks where an arbitrary application can
>tie into the parsing process. That just isn't a very useful thing to do
>for parsing VRML. It would introduce complexity into the parse and kill
>performance. If you want a C++ VRML parser, what OpenVRML offers is an
>ANTLR grammar that you modify with your own actions.
>
i think my model here was Matt Sergeant's 
{of axkit fame amongst others}
XML::LibXML and XML::LibXSLT
http://search.cpan.org

were made using perl's xs to wrap
around xmlsoft.org's
 libxml and libxslt

i put those modules to good use by being able to do this:
http://drfrog.fdns.net/perl/parsex3d.pl

what braden is right. openvrml is a blackbox!
i want to provide the ability to parse and validate online.
not ever display although in the distant future maybe an ability to produce an image

so both JSAI and EAI are not what i need!
AFAIK

i need the ability to wrap to the parser and validate routines

the good news?

i had fifteen minutes left on my day
and i managed to get to a point where 
my code was telling me i wasnt feeding it a stream
{i was using the VRMLScene(arg1,arg2) thang...}
tres cool , i didnt think i would get that far in less than 48 hours

i dont know a stich of c++ {or c} so this was pretty neato to me
[openvrml 0.10.0]

what i need to know is how to call the parsing and validating routines/sub/functions/...
 without calling the display routines 
then i could call those
methods directly and use those 
infos to generate a report of some sort

{mostly straight out for now}


btw an easy c wrapper might be to use perl as a middle man!

http://www.perl.com/pub/q/resources
look for c and perl

>>In a couple of weeks I'll have a large number of test models for OpenVRML
>>0.10.1.
>>
>>The good news is that OpenVRML 0.10.1 did as good as Cortona in displaying
>>several relatively complex architectural models.
>>
thats way cool !
exact same hardware?

>It's clear at this point that 0.11 has quite a number of regressions
>with respect to 0.10 :-(. We'll fix 'em.
>
i cant wait to roll an rpm!

ttfn

Re: [openvrml-develop] request for comments : a perl module for openvrml

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

On Thu, 2001-09-27 at 13:55, John Richardson wrote:
> Hello,
> 
> >OpenVRML does not presently provide a C interface; just C++. It is
> >possible to write a C wrapper around the C++ interface, but it doesn't
> >make a lot of sense to pursue that until our API has solidified more.
> >
> >Even then, providing a C interface is quite a bit of work for something
> >I'm not sure would be widely used. There are two reasons to have a C
> >interface:
> >        * to use the library from C applications.
> >        * to use the library from applications written in scripting
> >          languages that know how to talk to C libraries.
> >
> >It's my feeling that there aren't too many folks using C who want to use
> >OpenVRML. I think most of our users and prospective users using this
> >kind of a programming language are using C++.
> 
> If you were to use the library in a XCMD or XTRA on the Mac you would have
> to use C. On the Macintosh you just set the Codewarrior flag to use the C++
> compiler. Then put extern "C" in the header files. So, in  a sense it is a
> non issue, at least on the macintosh under OS 9.

'extern "C"' only makes sense for things that are C constructs, like
functions, typedefs, and POD types. Creating a C interface for OpenVRML
would involve providing function and POD-type wrappers around the
classes in the interface. The task is straightforward, but it's a lot of
work.

The good news is that after the rearchitecture, our API will be smaller
(mainly since the different classes for each individual node type will
nolonger be part of the API).

I don't know what XCMD or XTRA are.

> >As to the second point, I do think it would be very nice to be able to
> >use OpenVRML from scripting languages. However, I think most scripting
> >language users will expect a relatively high-level interface, like the
> >EAI. And that is exactly what I would ultimately like to provide. I
> >still think it is a sound plan to use CORBA for this interface. We just
> >need more infrastructure in place before active work on this becomes
> >practical.
> 
> I use the SuperTalk language to control the Mac vrml viewer. So I either
> use Apple Events which are supported by SuperTalk or I would use EAI. One
> other way would be to use an XCMD.
> 
> Note that just having stable script node and EAI and Java support is not
> enough. You need some methods that allow the viewer to access the script
> node so that GUI's can directly utilize the functionality of the script
> node and Java / EAI. It is after all, a library that would be used by
> GUI's. So where is the API for the implementation?

I think the kind of communication you're talking about falls outside the
domain of the Browser Script Interface or the EAI. These interfaces
facilitate communication between programming languages and the VRML
world. You seem to be talking about communicating between different
execution contexts. These mechanisms should be provided by the
programming language and its libraries.

> >> mostly for using to parse and validate vrml
> >>
> >> a heady task im sure
> >> &
> >> im really not sure what i need to know
> >
> >OpenVRML already parses and validates its input. What kind of
> >application are you envisioning?
> >
> 
> Well, the obvious problem is content creation tools. Some tools just pump
> out bad VRML 97 but some just pump out senseless VRML 97. I have had
> Cortona (Mac) and OpenVRML choke on exported VRML from Design Workshop
> 1.8.5 and Amapi 6.  I can also get Cortona (Mac) and Blaxxun (PC) to choke
> on Ray Dream Studio export unless touched up by Spazz3D. Amorphium 1 and
> Inspire (Lightwave lite) export usually work in Blaxxun on a PC or under
> VPC 4. The programmers for those systems obviously think that their export
> is great or at least spec compliant.
> 
> So, if you get a black screen or an error message whose fault is it?
> Actually, the parser would need to give DETAILED error messages and
> identify the exact node it choked on. Then the problem with the export
> could be reported back to the Modeling and animation corporations like
> Newtek or TGS or Discreet.....

I think we are Pretty Good about error reporting now in OpenVRML. We
could be Better.

If you want to be able to write a Perl/Python/Whatever script that will
itself be intimately involved in the parse, OpenVRML is the wrong tool
for the job. OpenVRML's parser is intended to function like a black box:
you hand it a stream, and it does it's best to load it, spewing errors
if appropriate. There are no hooks where an arbitrary application can
tie into the parsing process. That just isn't a very useful thing to do
for parsing VRML. It would introduce complexity into the parse and kill
performance. If you want a C++ VRML parser, what OpenVRML offers is an
ANTLR grammar that you modify with your own actions.

> In a couple of weeks I'll have a large number of test models for OpenVRML
> 0.10.1.
> 
> The good news is that OpenVRML 0.10.1 did as good as Cortona in displaying
> several relatively complex architectural models.

It's clear at this point that 0.11 has quite a number of regressions
with respect to 0.10 :-(. We'll fix 'em.

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

Re: [openvrml-develop] request for comments : a perl module for openvrml

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

On Wed, 2001-09-26 at 16:10, clayton cottingham wrote:
> heya:
> 
> with the new messages
> about progress updates ive 
> had a hint of inspiration
> and i want to try something new with perl
> 
> if all goes well it should be beneficial for all
> 
> 
> i noticed matt s of axkit fame made those nifty perl modules
> for wrapping around the libxml c libs XML::LibXML
> 
> when braden mentioned:
>    Once these changes are in place, fully generic traversals of the
> scene
>    graph will be possible.
> 
> i got excited and thought maybe i should try my hand at hooking up
> some perl modules to the c libs of openvrml

OpenVRML does not presently provide a C interface; just C++. It is
possible to write a C wrapper around the C++ interface, but it doesn't
make a lot of sense to pursue that until our API has solidified more.

Even then, providing a C interface is quite a bit of work for something
I'm not sure would be widely used. There are two reasons to have a C
interface:
        * to use the library from C applications.
        * to use the library from applications written in scripting
          languages that know how to talk to C libraries.

It's my feeling that there aren't too many folks using C who want to use
OpenVRML. I think most of our users and prospective users using this
kind of a programming language are using C++.

As to the second point, I do think it would be very nice to be able to
use OpenVRML from scripting languages. However, I think most scripting
language users will expect a relatively high-level interface, like the
EAI. And that is exactly what I would ultimately like to provide. I
still think it is a sound plan to use CORBA for this interface. We just
need more infrastructure in place before active work on this becomes
practical.

> mostly for using to parse and validate vrml
> 
> a heady task im sure
> &
> im really not sure what i need to know

OpenVRML already parses and validates its input. What kind of
application are you envisioning?

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