I'd suggest using "WWWInline" in place of "WWWFile," and "WWWAGroup"
in place of "WWWButton" (the WWWAGroup name could use some work, but
it's a step in the right direction, I think). WWWAGroup is an
almost exact equivalent of HTML's ubiquitous Anchor type. As such,
WWWAGroup has no representation itself, but rather adds a hotlink
property to the elements expressed within its scope. On the other
hand, WWWInline is very similar to Mosaic and its descendant's
inline graphics functionality, except probably with a few added twists
linked to the spatialized aspects of VRML.
This nomenclature synchronizes the WWW functionality of VRML/InventorWeb
with its HTML counterparts, and also more fully expresses the generality
of these keywords. I'm not sure whether this use of WWWInline is
exactly what Gavin had in mind, but I think it's a useful interpretation.
With respect to Kevin's comments,
> Try this HTML anologue. Off my web pages, I have a page of "cool
> links" where I make links to other web pages I have (and feel other
> people might also) an interest. Now the same thing could be done with
> VRML. I have my VRML "cool links" space where I layout an area and put
> links to other peoples VRML pages. Their links would be represented by
> their geometries or possibly (depend on how close we want to be to
> HTML) my geometry. In HTML I decide how a link looks, how do we plan
> to do this in VRML?
With the names I've suggested, if you want to represent the cool
link with your own geometry, you might say...
DEF KevinsBldg WWWAGroup
{ name = "...kevins-homespace.vrml"
Separator
{ USE MyCoolLinksVis
LevelOfDetail
{ [relscale expression]
Separator
{ translation {0 3 0}
Text { string "Kevin's Cool Link" }
}
Info {} #Text is expensive; don't show it if we're far away
}
}
On the other hand, if "kevins-homespace" was a building representation
I found while strolling along Microsoft Boulevard, and I'd like to
incorporate his building in my street of cool links, we might try
DEF KevinsBldgFullvis Separator
{ Translation {#relative transformation to place Kevin's bldg in my space}
LevelOfDetail
{ [relbandwidth expression]
WWWInline { name = "...kevins-homespace.vrml" }
USE KevinsBldg
}
}
In this instance, if my relative allocation of net bandwidth for Kevin's
homespace is large, I'll seamlessly include his own public representation
of his homespace (likely more distinctive than any rep I could give,
which is *important* in trying to effectively employ spatial semantics
without always resorting to text labels). This also has the advantage
that I can stroll on into his building vis without explicitly requesting
a hyperlink to be followed, because the entrance is implicit in the
spatial semantics. If the net bandwidth limitations are more severe,
I'll default to my local representation of his space, with the tradeoff
that I do require the display discontinuity to enter Kevin's space.
Display bandwidth issues will fall down in scope to
KevinsBldg or "...kevins-homespace.vrml." Note that the WWWInline
expression may well require some maxscale parameter to rationalize
the size of "...kevins-homespace.vrml" to the space I can allocate it.
Make sense? [Gavin, this is also to say that I think that support for
overloading the LevelOfDetail selection filter to later add net-bandwidth,
semantic-filtering, etc. criteria would be valuable.]
> Culling and level of detail management will be crutial to VRML I
> think, both of which are somewhat provided for in Inventor.
Inventor's LevelOfDetail does look like it provides at least part of
the necessary functionality, though I'm somewhat doubtful that
LevelOfDetail as presently described can support either very deep
visual spaces (in the style of Philip Morrison's "Powers of Ten")
or very broad spaces (e.g., a spatially-continuous version of a
country's full surface structure, seen from human scale) where
the population of possibly visible nodes is truly unbounded.
I think both of these cases will show up frequently in applications
where one would like to use VRML, and it's this sort of functionality
the multiscale structures I referenced in my last message are designed
to support.
>> Equally fundamental is the set of bindings between the information
>> represented and the information itself...
>...
> I think we could avoid that problem by saying you can't, or by popping
> up a HTML external viewer in the same way Mosaic pops up external viewers now
The pop-up case should work just fine; I've frequently invoked X-Mosaic in
a slaved mode from Inventor apps in just this manner. The
WWWAGroup node should support this; selecting a VRML (or DXF/IGES/etc.)
link would represent a discontinuous jump to a viewing of the geometry
in question (in contrast to the continuous movement supported by WWWInline),
while selection of an HTML, Gopher, GIF, or other "flat" link would invoke
a slaved HTML viewer. In more advanced viewers, one could instead
imagine hyperlinked geometries or flat data structures to appear within
the cupped hands of the navigator (if the navigator is embodied -- another
whole point of discussion), with flat formats perhaps texture-mapped
onto a polygonal construct.
Brygg