A very interesting idea. The only problem with this I can think of is that
implementing WWWAnchor as a property will probably be harder than
implementing it as a group. If implemented as a group, the code for "if
picked, goto URL" is nicely encapsulated in the group. Shapes pay attention
to properties, so if implemented as a property you'd probably have to put
that code into every shape (or put it in the browser and let it try to figure
out what picks means).
Also, I doubt PER_FACE/PER_VERTEX URLS will be used much; I think it is
easier to think of each hyperlinked thing as a WWWAnchor with geometry under
it. If they were common, IndexedFaceSet should probably be extended to have
a urlIndex field to be consistent with the other per-face/per-vertex
properties (material/normal/texcoord).
> 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.
You can get the same effect with either the map field and a cgi-bin script
(see below) or by spreading the geometry under multiple WWWAnchors.
> - 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.
The legal values are POINT and NONE. The desire to keep the spec small
prevented me from adding values for world-space point, texture coordinate and
normal; maybe in VRML 2.0 if the map field is found to be useful.
>
> - 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.
Yes. I'm working on the spec now, I'll add a note to that effect. Does
anybody feel strongly about renaming the filename field? (last time I asked,
nobody seemed to care; see: http://vrml.wired.com/arch/0750.html where I ask:
"Which do you like better: "url" (could be a problem if URN's ever happen)
"name", "filename", "externalReference"?"
> 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?
That is another unresolved issue. I think we should take the lead of HTML
and leave the supported formats unspecified (see:
http://hopf.math.nwu.edu/html2.0/htmlspec281194_17.html
for the HTML <IMG> spec); it doesn't seem to have hurt HTML.
> - VRML should also be able to set named camera positions.
There's an easy way of getting this even with the current spec, although it
is sort of clumsy. Put all the world's geometry in one file (geom.wrl,
perhaps). Then, for each different "entrance" (camera position) create a file
that contains just a camera and a WWWInline that references geom.wrl. Then
you just link to whichever "entrance" file you want.
If you think that is too clumsy, how about this scheme:
Extend the VRML URL syntax to allow a link plus changes; the syntax could be:
?SET:nodeName={value},nodeName={value}
Where nodeName is a named (DEF'ed) node, and {value} is file format to set
the node's fields.
So, you could set up a switch with multiple cameras underneath it:
... in foo.wrl:
DEF CameraChooser Switch {
whichChild 0
PerspectiveCamera { ... }
PerspectiveCamera { ... }
}
... and then specify a link as either:
http://www.foo.com/.../foo.wrl?SET:CameraChooser={whichChild 1}
or
http://www.foo.com/.../foo.wrl?SET:CameraChooser={whichChild 0}
Or you could just name the camera and set its fields directly, letting you
link in to an arbitrary location. This is a nice, general scheme that I
suspect could be used to do lots of interesting things (and is really easy to
implement if you're using Inventor; actually, I don't think it would be too
hard to implement even if you weren't using Inventor, you'd just have to add
some stuff to your node-naming code...).
> - 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.
I'm torn. alternateRep is most useful when you define new types of
geometry-- for example, if you add a Torus node you could give it an
alternateRep that was a Group containing appropriate coordinates, normals and
an IndexedFaceSet. However, if you do you'll lose most of the benefit of
creating the Torus in the first place-- cutting down on network bandwidth by
giving a much simpler description of the complex object.
Combining alternateRep and WWWInline may create some interesting
possibilities; for example:
Torus {
fields [ SFFloat r1, SFFloat r2, SFNode alternateRep ]
r1 10.5
r2 1.2
alternateRep WWWInline {
bboxSize 21 2.4 21
name "..../cgi-bin/generateTorus?10.5,1.2"
}
}
This kind of use is pretty sophisticated, though, so I'm inclined to leave
alternateRep (and the SFNode field) out of the 1.0 spec (anybody else have
opinions?).
> 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.
No, to add functionality you must create a new type. Which brings up a
feature which might be worth adding to VRML 1.0 (we are going to add this to
Inventor 2.1):
Nodes derived from existing classes can be safely treated as their parent
class if the subclass is unknown. If the list of parent classes is written
along with the field descriptions, then a VRML (or Inventor) implementation
can automatically do this. For example, if I want to add indexOfRefraction
to the Material node to support ray-tracing VRML scenes, I would implement a
RayTraceMaterial class. It would be written to file as:
RayTraceMaterial {
fields [ MFColor diffuseColor, # ... etc, Material's fields
MFFloat indexOfRefraction,
MFString parentClasses
]
diffuseColor .9 .3 1 indexOfRefraction .1
parentClasses [ "Material" ]
}
If RayTraceMaterial is unknown, it can be treated as a plain Material,
ignoring the indexOfRefraction.
> - It would be useful to have Inventor style field connections and global
> fields.
Left out on purpose; maybe in VRML 2.0.
> - 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 would agree, if we could rely on a better protocol than http/ftp/... Until
there is a protocol with a request like "Please tell me just the bounding box
of this VRML URL", I think we'll have to deal with the coherency problems;
I'm willing to trade the coherency problems for the problems that occur if
you have to fetch everything in an entire world before knowing what to
render. With bbox information in WWWInlines, VRML 1.0 is (theoretically) an
infinitely scalable cyberspace.
> - 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.
Correct assumption. I'll add some wording to the spec.