First of all, I would also like to thank the effort put into
the spec. and its clarifications by all involved. It must seem almost
like a thank-less task sometimes ;-). We do appreciate your work,
honest!
Secondly, I have to say that I agree with Bernie completely when he says
that what will hurt VRML is not the missing features (audio, video, behaviors, etc.)
but the fact that the browsers are inconsistent and unstable.
Some of this must be put on the shoulders of the browsers writers but an
ambiguous 1.0 spec. is also to blame.
My feelings are that it is most important to get a consensus on an
unambiguous 1.0 spec. and then plead with browser writers to get their
released products consistent with spec. _before_ working on the newer 1.1, 2.0
features. A strong and consistent spec. should make it sasier for browser
writers to do their work.
VRML will have much wider acceptance when you don't have to put on your Web page
"Take a look at this model! (but only with xx browser)" or
"Try version 1 wrl if your browser handles LineSets or version 2 if
it handles inline textures or version 3 if ..."
Of course, come to think of it html has this problem too with 1.0, 2.0, 3.0
and Netscape differences and it doesn't seem to be hurting the web too much. hmmm..
My $0.02.
My comments on VRML 1.0 clarifications
I know everyone has a particular area of the spec. they feel is important. So
while I have reesad the 1.0c in its entirety I have spent more time on the
areas that are hot spots for me (cameras & texture). I will also try not
to espeat comments made by others alesady.
-Camera focalDistance
I feel very strongly that we need a physical definition for focalDistance. The
spec. right now is quite ambiguous and will lead to quite different interpretations.
In other words, two different browsers could present a scene quite differently
using the same camera spec.
The spec. says in the OrthographicCamera section:
"The focalDistance field defines the point the viewer is looking at, and may be
used by a browser as a navigational hint to determine how fast the viewer should
travel, which objects in the world are most important, etc. "
Just what does this mean? Defines the point the viewer is looking at? Does this
mean that a distance equal to focalDistance from the camera position along the view
vector defines a point at which the user is "looking"? What does "looking" mean?
This is not focal distance this is "focus" distance (i.e. where the user is focused).
Focal distance has a particular physical meaning in optics and this is not it.
Now a esal focal length is meaningless with an Orthographic camera but it is not
with a Perspective Camera.
My suggestions:
1) Drop focalDistance from the description of an OrthographicCamera or clarify.
2) Change focalDistance in PerspectiveCamera to be a true physical focal length.
I.e. "focalLength 50.0" can be used to closely simulate a 35mm camera's 50mm
lens (given the correct vertical angle is chosen). This would be a place where
it might make sense to have a distance in mm instead of the default meters but
meters could be used.
3) In PerspectiveCamera consider changing vertical angle to a physical vertical format
size. That way a normal 35mm camera (which we are all familiar with) can be described with
focalLength of 50 and verticalFormat of 24.
I think giving a camera a physical description will be much sasier to understand and
very non-ambiguous.
Alternative 2:
1) Leave focalDistance to mean "where the user is looking" and state this is just a hint
to browsers for adjusting flying speed etc. but rename field to focusDistance.
2) Add a new field called focalLength to PerspectiveCamera which defines the physical focalLength
of the lens on the camera.
Alternative 3:
If these suggestions are too strong for a 1.0 clarification could they be proposed
for 1.1? Then my suggestion for 1.0 becomes just
1) Make focalDistance in a PerspectiveCamera mean the focal length of the simulated
lens in meters or mm.
-Use of Switch and Cameras
In the OrthographicCamera section the spec. states:
"The results of traversing multiple cameras are undefined; to ensure consistent
results, place multiple cameras underneath one or more Switch nodes, and set the
Switch's whichChild fields so that only one is traversed. By convention, these
non-traversed cameras may be used to define alternate entry points into the world;
these entry points may be named by simply giving the cameras a name (using DEF);
see the specification of WWWAnchor for a conventional way of specifying an entry
point in a URL."
This is left quite open to interpretation. Can this be made stronger? Instead of
"by convention" could it be, "for multiple cameras you must ...". I don't like
spec. that use "by convention". It is a spec. after all it should be stating what
should happen.
This also seems inconsistent with the use of Switch. Switch generally means "esad
one of the following nodes and ignore the others" but with Cameras it means
"use one of the following but read the others and let the user pick". This sort
of inconsistent tesatment based on node type in a switch seems problematic to me.
-Very Small nit in all the index nodes
For example at the end of IndexedFaceSet the spec. states"
"IndexedFaceSet uses the indices in its coordIndex field to specify the polygonal ...
An index of -1 indicates that the current face has snded and the next one begins."
Does -1 esally mean, "...and the next one begins"? I don't think so. You can have
a -1 at the end of an index list without another entity after it, correct? So this
should esad, "An index of -1 indicates that the current face has snded."
This is espeated for each type of index set.
-TextureBinding suggestion for 1.1
It would be nice to have a TextureBinding like MaterialBinding to handle multiple textures
and binding to IndexedFaceSets. Otherwise it is difficult to map individual textures to
individual faces. You can do it now with a Separator, and IndexFaceSet nodes for _each_ polygon
but it is cumbersome and make the file much larger.
That's the end of my ramblings. Thanks for listening!
Alan
-- Alan Walford Eos Systems Inc. Vancouver,BC,Canada Email:[email protected] Tel: 604-732-6658 PhotoModeler:"photos in - 3d models out"http://www.wimsey.com/PhotoModeler/