thanks for your response to my previous posting. Here are my comments
about your comments:
>> - 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).
>
>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).
I understand your position that this would be a lot of work to fit into
Inventor, but I believe decisions about the spec should be determine by
what makes sense for the VRML format, not to cater to the current
implementation of that node type in any particular system (i.e. what
fits in Inventor as it currently stands.)
VRML != Inventor, and since The WWWanchor node in the current spec. is
inconsistent with the way properties are bound to geometry operators in
the rest of the spec., I think the WWWanchor node should be changed to
be consistent with the other bindings.
>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.
I consider using cgi functionality a hack to allow people to maneuver
around HTML's limitations. With VRML's 3D data model we should be able
to greatly diminish the dependence on cgi hacks. Using the URL binding
I proposed will allow most of the cgi usage to be avoided. It is still
useful to have a map function to be able to do some complex
functionality, such as accessing a datbase (DBMS), but there is no
reason we should have to write a cgi script to replicate image map
functionality.
If I do want to have a URL per face, should I really have to have a
WWWAnchor node for each face? This would mean rendering everything as
independent polygons which is a huge performance hit - not to mention
making the scene graph much more complex. Even given that, how would I
use such a hack to do a URL per vertex?
I think extending the shape nodes, such as IndexedFaceSet, to have a
urlIndex field would be a good idea. Besides it should be very easy for
you guys to implement. Make a subclass of the IndexedFaceSet node that
recognizes the field and have your parser create an instance of that
new node type when it finds an IndexFaceSet in the VRML file.
>> - 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.
What good is the object space point going to do? I can think of lots of
uses for the texture coordinate, but I can't think of any useful
applications for the object space point mapping that can't be done with
URL bindings. Consider again my globe example. Using the mapping
capabilities a logical way to do this would be to have a sphere with a
map of the world texture mapped onto it. The map function would pass
the texture coordinates into the URL that points to a cgi function.
Texture coordinates will be useful to determine where the user picked
on the globe, whereas object space points don't help me.
I think that adding the texture space points as another value of the
enumerator doesn't complicate the spec too much. Even if people
determine that it does, I would rather see mapping to texture
coordinates than to world space points.
>> - 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.
...
I like this scheme a lot, but it has a problem. Using the Inventor file
format for the scene specification does not require one to keep the
scene graph around. Adding functionality to make arbitrary changes to
the scene graph would require the scene graph to be kept. To do so
requires a browser implementation to re-create the capabilities of
Inventor, which is a lot more work than just being able to use the
format to describe the scene. This scheme does solve another problem I
have been curious about.
The VRML format allows the definition of switch node but provides no
facilities for ever changing the whichChild field of the switch.
Therefore there is no way to ever change the switch. The spec. should
either add some methodology to change which child is active or it should
drop the node type.
>> - 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.
...
>> 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:
...
It would be very useful to have the extensibility mechanism be able to
extend existing node types. I don't see what the problem is with that.
Remember we're not talking about the Inventor nodes we're talking about
the file format to describe the scene. Therefore if my implementation
of a cube node type supports a field foo and yours doesn't, then you
can just ignore the field. This would be like viewing an HTML page with
<BLINK> tags in it from Mosaic. The page shows up fine, the only
difference is the part doesn't blink.
The reverse case does not work. I want to be able to add things to the
existing node type such as cube. Requiring me to use a new NodeType
such as MyCube means that people without my browser won't get anything
at all (i.e. anyone who doesn't support my particular extensions will
just see gaping holes in their scenes.) In this scheme instead of the
blink tagged text just not blinking, it doesn't show up at all. This
would be a bad thing.
Note, if nothing else, alternate rep. support could avoid these holes
by allowing the file to say "if you don't support MyCube use a Cube".
Also, the subclass scheme you mention doesn't work in VRML. VRML has no
concept of classes and sub-classes. VRML just knows about the
pre-defined node types. Since the extensibility mechanism has no way to
say "this node I am describing is a child of node foo", there is no way
for an extension node to default to a parent class.
>> - 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 disagree strongly. This seems like a painful burden to place on the
author of a page. It would mean that if someone in Singapore changes a
file in the middle of the night, then in the morning my VRML page will
be broken.
Perhaps the solution is to put the bounding box for the entire file in
the header at the top of the file. Instead of saying:
#VRML V1.0 ascii
it could say
#VRML v1.0 ascii (X1,Y1,Z1)-(X2,Y2,Z2)
where X1....Z2 specify the corners of the bounding box for the scene
described in the file. This would mean that only the first line would
need to be read to get the bounding volume information.
All of this also brings up a concern regarding the VRML forum. Is there
any formal process for how issues regarding the spec. are resolved? I
have seen a lot of issues fly by and decisions made on a fairly random
basis.
Len Wanger -- [email protected]
San Diego Supercomputer Center