[openvrml-develop] Re: Some openvrml questions

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

I haven't worked on openvrml for a couple of years now.
You should direct your questions to the developers list,
where Braden is leading the project. Since he wrote the
parser, he is especially well-equipped to answer questions
on that topic. Braden et al, feel free to correct whatever
out of date, incorrect, or otherwise misleading half truths
I spew out below...


----- Original Message -----
From: <luc...@li...>
To: <cm...@ve...>
Sent: Monday, August 20, 2001 5:27 AM
Subject: Some openvrml questions


> I am beginning to use openvrml for a research project, if u dont mind i
> would like to ask two questions that would help me to gain confidence
> with the library's architecture.
>
>
> -The parser reads the wrl file and returns an MFnode containing all the
> vrml nodes.
> Why did u choose to embody so much complexity in the parser?

The parser converts from the external representation (wrl file) to the
internal
representation (VrmlNode scene graph). That is pretty much the definition of
a parser. What complexity would you like to leave out?  I'm not a big fan of
the parser construction technology used in openvrml but the parser itself is
a fairly well-encapsulated black box that hides its implementation
complexity
significantly better than the standard lex/yacc API.

> I mean the parser needs a Doc2 and a VrmlNamespace and only the doc2
> class requires zlib to compile properly.

That is a pretty minimal interface. The parser needs a data source that
can read from optionally gzip-compressed files/URLs (provided by Doc2)
and it needs to know what node types are defined in the current scope
(which is what the namespace supplies).

> Is it very difficult to move this complexity "outside" from the parser?

I see no advantages to doing so (of course, I haven't even looked at the
source for the last 2 releases, so I may be out of touch).

>
> -In a scene graph library the rendering should be a graph traversing
> process, so usually the renderer is implemented as a new class
> hierarchy and nodes classes in the scene graph dont know how to render
> themself ( at least i have seen something similar in open inventor and
> open performer). Why did u choose to embody in the VrmlNode part of the
> rendering process? It is very difficult to move the rendering
> process "outside" the scene graph managment process?

I think the paradigm of each node knowing how to render itself is a nice
encapsulation of the node-specific knowledge. It makes it simple to add
nodes and it lets each node use its own internal data for rendering
optimizations.
In fact I think much of the work currently (?) done in the Viewer classes
(triangulation now and stripification some day...) ought to be done in the
various node classes, so the Viewers become responsible for just blasting
tristrips out.

Chris

>
> Thanks in advance for ur attention.
>
> Greets
> Luca
>
>
>