> In fact, is WWWInline or WWWFile really needed? Why not just support
> the syntax
>
> USE http://www.dead.net/treasure_chest/skulls.vrml#one_eyed_skull
>
> where we assume that skulls.vrml has a DEF one_eyed_skull ... {...}
> in it?
Actually, perhaps even more direct still (given the existing Open Inventor
syntax) is the "File" node. The line
File {name SomeObj.iv}
reads the specified file into the current scene graph in a manner
immediately extensible to the VRML case.
On the other hand, so long as WWWInline is allowed to specify non-VRML
Web data -- HTML docs, sound, perhaps TCL or other behavioral scripts,
etc. -- WWWInline's content abstraction does have some upsides to
USE or File. For instance, while WWWAGroup might invoke pop-up browser
support for flat Web files, on systems with adequate graphical support, it
might be nice for WWWInline to texture-map these flat documents over
a scalable polygonal construct to allow seamless interaction in the 3D
space. If you have a copy of the Inventor Mentor handy, take a look
at the cover art. I see no reason why WWWInline shouldn't (in the fullness
of time) support the graphic on the monitor to be a texture-mapped X display,
the Inventor sheet on the easel to be SGI's HTML Inventor home page,
the pictures on the wall to be inlined JPEG's (or perhaps live MPEG's
displaying video from one of Malamud's future multicast video servers),
and the clouds in the sky to be the product of a .mailcap-specified
interpretation on data from the UIUC Weather Machine. (And did I mention
the Wright flyer counterweight is a circularly-scoped linkage of the
earth, with enveloping scale and mass properties? :-)
Sure -- I don't expect this to be possible in a first-pass implementation,
though I don't really think these examples are far-fetched, or even
beyond what we might hope to see in six month's time (with the possible
exception of the weather .mailcap synthesizer ;-) But in the interest of
supporting future VRML extensions without kluging in various gross
hackeries, let's try to leave the navigator interpretation of inlined
data types as general as possible. It's no sin if some legal expressions
have no implemented support in the early generations.
> Could we add some keyword that would define a named object, without
> necessarily implying that it should be drawn? That way, I could
> pull in a file of object definitions, but only draw/"USE" the ones
> that I want.
This support is somewhat indirectly supported in Open Inventor with
the "Switch" node-type. Switch, used as a grouping operator over a series
of DEFs, will not display the internally-scoped objects, but will allow
the objects to be USEd outside of its scope. Unfortunately, when I
experimented with this in conjunction with the "File" node while
building some VRML'ish examples, I still couldn't replicate the desired
object-library functionality because "File" atomizes its contents
without allowing their external reference. Does anyone know if there's
a way around this in Open Inventor as it currently exists? I found
mention of achieving this through C++ coded calls, but couldn't find
a workaround at the data file level.
Sometime I'd also like to bring up the issue of embodied vs non-embodied
navigation of VRML spaces, as well as support for multi-user embodied
interactions in these spaces. I have some ideas for possible
implementations... but that's for another day. Sorry about this note's
length... no wonder I have trouble finding time to post.
Brygg
P.S. -- thanks for the WebWorld pointer, Linas!