Len Wanger -- [email protected]
Project Sequoia 2000
San Diego Supercomputer Center
-----------------------------
- WWWAnchors are inconsistent with the rest of the spec. An anchor node
should be a separate attribute node, like a material, that is applied
to all subsequent shapes. A WWWAnchor node should contain n URLs,
which are applied to shape nodes using an anchorBinding (analogous to a
material binding).
Since an Anchor node could have multiple values, the AnchorBinding
would specify how the URL (anchor) values are distributed over a
shape. When multiple anchor values are specified the values should be
cycled. Like material bindings these should be applicable as:
DEFAULT use default binding
OVERALL one URL for the entire shape
PER_PART one URL for each part of an object
PER_PART_INDEXED one URL for each part indexed
PER_FACE one URL for each face of an object
PER_FACE_INDEXED one URL for each face indexed
PER_VERTEX one URL for each vertex of an object
PER_VERTEX_INDEXED one URL for each vertex indexed
Imagine using specify a URL per face on a globe, so that picking on a
face for a country would link you to a web document about that country.
This would give similar functionality to image maps in a much cleaner
manner.
- The WWWAnchor node has a map field of type SFEnum. What are the legal
values for the enumerator? I could certainly see wanting to getting
texture parameters opposed to object-space x,y,z coordinates of the
pick point on the object. This mapping feature could be used for fancy
CGI back-end functionality, but I imagine for the most part one would
just use the anchor bindings described above.
- Specifying the texture filename for Texture2 nodes won't work. You
cannot assume that you will have a particular texture map file on you
local machine when using a texture map. This texture should be a URL
to a texture file. Also, what format is this texture in? Inventor says
to check the release notes for the format used in your implementation
(although I assume this is usually SGI RGB files), but that won't work
for VRML. Since browsers can't deal with arbitrary image formats it
seems to me a particular format, or small set of formats, needs to be
specified. Is this SGI RGB files, GIF images, JPEG?
- VRML should also be able to set named camera positions. This would
allow one to point to relative positions in a VRML world - similar to
HTML where you can specify a relative point in a document. For
example, setting the WWWAnchor to:
WWWAnchor { name "httpd://foo.domain/bar.wrl#cam_pos1" }
would link to the viewing position named "cam_pos1" in document
bar.wrl.
Named camera positions should specify a textual name of the camera
specification (maybe viewing parameters along with the name of a
particular Ortho. or persp camera node?).
- It would be useful to add alternative representations, as seen in the
Inventor spec. This would allow me to put extra fields into objects,
such as state variables and behaviors. Browsers that can't handle these
extended nodes would use an alternate node type. This would prevent
there being large holes from missing (ignored) nodes in an environment.
This brings up another question, does the extensibility scheme work for
standard VRML node types? The description in the 1.0 spec. sounds like
it doesn't. I think being able to specify optional fields for the
standard node-types would be very useful. This would provide a
standard mechanism to allow me to add state and behaviors to objects
without having to use an alternative representation.
- It would be useful to have Inventor style field connections and global
fields.
- Having the WWWInline nodes specify the bounding box size and center
leads to coherency problems. The contents of in-line nodes can be
anywhere on the net. How will the bounding box size and center be
updated in a file if it is changed independently in the in-lined file?
Think about how image references work in current browsers. If the HTML
page contains a URL for an image, the X and Y image dimensions are
fetched from the referenced image, and are then used for laying out the
displayed page. Similarly I believe that the bounding box information
for the in-line node needs to be retrieved from the URL for the in-line
data.
- I am assuming the bounding box on WWWInline nodes are in the in-lined
data's object space - not in the current world space. Is this true? I
don't see how it can work otherwise.