> Re: Brygg's proposal:
>
> There is a name scoping issue here that no one touched on. Suppose
> that the indicated http address is a VRML, and that it has a bunch
> DEF's in it. Are we free to USE these newly defined DEF's in the
> current document? What if the owner of the remote document changed
> and blew away a DEF we were depending on? What if they recently
> added a DEF that overrides a DEF that we were using?
Actually, I have a variant naming interpretation along exactly
these lines that I'd like to throw out for feedback. It seems to me
that with a minor variant of LevelOfDetail (detailed shortly) and a
simple implementation of the multiscale functionality I've referenced,
we can legitimately hope to realize visually (and navigationally) continuous
spaces of unbounded size with VRML. I think this is *important* -- really
much the core of what makes net-distributed semi-immersive environments
interesting, beyond the significant semantics issues of mapping geometries
to content -- and I think most of the necessary groundwork is in place.
While I'll try not to harp on this as a first-pass VRML issue,
it would be nice to lay the foundations for some of this functionality.
(As an aside, I've sketched out much of an httpd'ish fully-distributed
server-side implementation of such an implementation with only the WWWInline,
WWWAGroup, tweaked LevelOfDetail, and upward scene-parent naming convention
additions, though it'll take a while to write this up.)
The naming convention comes into play when we wish to view the VRML
rep for some particular object in the context of its surroundings.
Say Linas wants to send me the URL for his great new agora/stoa
complex [basically, the open marketplace area at the city's center] in
his Pergamon model of Greek Antiquity-come-cyberspace info-carrier
(my VRML exploratory example of a few weeks ago; LevelOfDetail Works!).
Linas, being the good OO modeller that he is, has defined the agora as a
separately-encapsulated entity from the Pergamon scene (and the Pergamon
scene from its nearby environs, the environs from the region, from the
Turkish subcontinent, etc... but that's getting ahead of myself).
However, knowing that the beauty of Grecian cities lay largely in the
cohesive whole of the city's individual structures, I really want
to look at his agora in its place within the larger city. Knowing
this, Linas included a call similar to the following in his agora.vrml file:
WWWParent
{ name=linas-pergamon.vrml
ref=Agora
}
This is interpreted as saying that the default contents of the
"USE Agora" call in linas-pergamon.vrml should be replaced with
the current geometry (chances are, the agora reference was bidirectional;
agora.vrml declared linas-pergamon.vrml as its parent, and linas-pergamon
declared agora.vrml as its child). Objects included within the agora
would similarly be bidirectionally linked to the agora. Individual
contents of stoa (market stalls) -- likely standard info junkets or other
virtual offerings in the cybermodel case -- would likely not include
default Parent nodes, as they would often have many instances in other
equally likely contexts. Thus, this WWWParent is my (first, admittedly
partial) response to the name-scoping, external object references, etc.
naming issues referenced by Linas, as well as providing a valuable
tool for creating continuous spaces of unbounded size.
To continue, on the other hand, if I'd like to see *my* agora model in
the context of Linas's Pergamon setup, I might use the URL
vrtp://object-url#name-transformation#parent-url
-- in this case, perhaps
vrtp://localhost://...myagora.vrml#Agora#vrtp://www.austin.ibm...linas-pergamon.vrml
An conversely, if I want to place Linas's agora in the context of my
Pergamon model, I'll just WWWInline it, with the implicit override of
his internal Agora parent definition. Hope the above makes some sense...
the multiscale paper puts this into somewhat more perspective, though
I now need to extend it to include the VRML cases. The syntax
I've used could probably stand enlightened evolution, too.
The variant on LevelOfDetail I've referenced is basically the lazy evaluation
of scoped children. To my understanding, Open Inventor doesn't currently
support circular node descendancies. However, one of the more basic
(and powerful) representational devices I'd like to use in VRML apps
involves (for example) an embodied navigator standing in a house
inspecting a visualization spread across the kitchen table. Which
visualization? A representation of the "city" containing the said
house, such that if he whips out a "microscope" device and scans
across the city, he should be able to peer through the kitchen
sunroof to see himself.
With lazy scale-based evaluation of hierarchically-encapsulated
LevelOfDetail nodes, this should be no problem; in fact, it should be
consistent for an embodied navigator to pick up the house containing said
table-with-the-city (though it may take some interesting UI exploration
to define what it means to pick oneself up!). This whole circular-list
issue is analogous to SASL's support for easily specifying lists of
infinite length, except that in this case the "local environment" spec
in our semantic judgements needs to be a bit smarter. Lazy isn't
hard; we just don't want to retrieve LevelOfDetail children until
their particular representation is needed in the present scene
graph. (We will have to provide bounding-box envelope information here,
whether of an auto-scale or auto-crop variety, but we'll want
this anyhow to support the equivalent of zoning-requirement issues in
our virtual cities, not to mention much simpler cases still.)
Hmmh... maybe I'll include a response to the rest of Linas's post
as a second message.
Brygg