Menu
▾
▴
openvrml-develop
|
From: clayton c. <dr...@sm...> - 2001-09-26 20:08:14
|
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 mostly for using to parse and validate vrml a heady task im sure & im really not sure what i need to know def some header file & libs info will be needed right now i mostly wanted to give a heads up and see if anyone else has ideas on other possible libs to try this with for what every reasons anyways anyone interested let me know im just starting to learn how perl XS works so dont expect a release tomorrow! ttfn |
|
From: Braden M. <br...@en...> - 2001-09-26 23:26:57
|
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...>
|
|
From: Braden M. <br...@en...> - 2001-09-28 00:01:44
|
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...> |
|
From: John R. <ric...@sp...> - 2001-09-28 16:41:07
|
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 |
|
From: clayton <dr...@sm...> - 2001-09-28 02:34:21
|
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
|
|
From: Braden M. <br...@en...> - 2001-09-28 03:47:45
|
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...>
|
|
From: Clayton C. a. d. <dr...@sm...> - 2001-09-28 05:29:08
|
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 !
|
|
From: Braden M. <br...@en...> - 2001-09-28 19:24:28
|
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...> |
|
From: clayton c. <dr...@sm...> - 2001-09-28 19:38:24
|
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
|
|
From: Braden M. <br...@en...> - 2001-09-28 20:42:56
|
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...>
|
|
From: clayton c. <dr...@sm...> - 2001-09-28 20:48:51
|
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
|
|
From: Braden M. <br...@en...> - 2001-09-28 21:09:59
|
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...> |
|
From: clayton c. <dr...@sm...> - 2001-09-28 21:40:12
|
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 |
Thanks for helping keep SourceForge clean.
X