There are several pieces of information that might be interesting:
-- object-space point
-- object-space normal
-- object-space texture coordinate (S & T coordinates)
How about another field of type SFEnum called 'map' that can have
values of NONE (the default, no information tacked onto URL), POINT
(object-space point tacked onto URL in the format you suggest), NORMAL,
or ST_POINT (normal or texture coordinate tacked onto URL)?
Are NORMAL and ST_POINT overkill?
> I suggest that, even in the first cut of VRML, we will want more than
> just "teleport" links to VRML objects. In our WebOOGL project, we
> came up with three we felt were most important:
> Relationship Meaning
> (default) teleport to new scene given by target
> Embed keep old scene, but include target in the
> hierarchy under the link node that retrieved it
> WorldEmbed keep old scene, but include target under the
> root node of the hierarchy
What happens if a WWWButton that Embed's a URL is picked twice?
Adding the same set of children again doesn't seem very useful; maybe
it should become "dead" and ignore picks after the first one?
Should there be some way to un-embed embedded objects?
The semantics of embedding seem pretty fuzzy-- you're performing an
"transient change" to a scene.
Lets say navigate to URL "foo.vrml", and then click on a WWWButton
that embeds "bar.vrml". What appears in my browser's "Current URL"
status? What if I decide I really like the way the scene looks with
this particular embedding and add it to my hotlist; when I go to visit
it later, is "bar.vrml" embedded?
You want a (fairly simple) behavior. I think we should let VRML 2.0
define mechansisms to let you get that behavior. For example, wire a
button to the whichChild field of a Switch node to make some part of
the scene appear (you can make it an arbitrary URL by making the
Switch's child a WWWFile node!) when the button is pressed. The
semantics are very clear-- part of the scene was hidden, and the user's
action caused it to become visible, but it is still the same scene.