Len Wanger -- [email protected]
Interactive Simulations Inc.
http://www.intsim.com/~isigen
------------------------------------------------
- In glossary of data types, SFString should show an example of a URL,
since they're used that way a lot in vrml.
- AsciiText node: should specify that AsciiText has no thickness -- that the
text is rendered as 2D polygons in 3 space.
- AsciiText node: one should be able to bind materials to AsciiText on
a PER_PART, PER_PART_INDEXED, PER_FACE, or PER_FACE_INDEXED, with each
letter being considered a part or face. This allows specifying a
different material per letter; similar to how you can specify different
materials to different parts of the other geometry nodes (e.g. cubes,
cones, etc).
- Material binding on geometry nodes: why can't you do PER_FACE or
PER_FACE_INDEXED binding of materials to a cone or cylinder node?
Material binding on all of the geometry nodes should be consistent. My
vote is that they all should be similar to how a cube is handled (i.e.
allowing PER_PART, PER_PART_INDEXED, PER_FACE, or PER_FACE_INDEXED).
Also a nit-pick, the description specifies "the first current material
is used for the sides of the cone, ..." Change "Sides" to "side" as a
cone only has a top and one side.
- Texture binding on geometry nodes: the description of the geometry
nodes specifies how textures are applied to the nodes. Can
TextureCoordinate2 values be assigned to the geometry nodes (AsciiText,
Cone, Cube, Cylinder, and Sphere)? Also, is the application of
textures on the geometry nodes effected by Texture2Transforms? I assume
both of these should effect geometry nodes, but the description of
these nodes makes it sound like the texture application is hard-coded.
- orientation of geometry nodes: The orientation of all of the geometry
nodes needs to be specified (not just the size):
AsciiText: oriented in the XY plane, with the text flowing in the
positive X direction.
Cone: the description is pretty good. To clarify which the bottom is
change "with its apex at 1" to "with its apex at 1 and its bottom at -1".
Cone and Cylinder: Instead of saying the dimension they are centered
around specify which dimension their major axis lies on.
Cylinder: Which face is considered the top and which is considered
the bottom? The spec. should specifying which is the top and bottom
face (i.e. top is y=1 and bottom is y=-1).
- Materials and lighting: I agree strongly with Eric Haines that the
equations of the lighting model needs to be specified in the spec. This
is important to be able to specify detailed lighting. I understand that
many people want things that look roughly correct, but some or us to
through great pains to make sure lighting and look are accurate. For
instance, radiosity renderings go to great pains to calculate accurate
lighting. If browsers implement lighting differently, the walkthrough
will not accurately reflect the calculation.
- Switch: the whichChild field of a Switch node renders nothing when
its value is -1 and everything when its value is -3, what does it do
for -2? If nothing, then why is -2 skipped?
- Texture2: Instead of saying that setting both filename and image
fields is undefined, specify which one overrides the other, or add and
SFEnum field that specifies whether to use a filename or image. I
suggest having image always override file name if both are specified.
- SFImage should have some simple compression scheme. Without getting
into compression wars, it would be very nice to allow run length
encoding of SFImages.
- WWWAnchor: the map SFEnum field should be: NONE, POINT, or TEXTURE,
with TEXTURE appending the s and t values of the texture coordinates
picked to the url. If the mapping function is to allow the equivalent of
html-based image maps in vrml, then texture coordinates are much more
useful that object space coordinates.
- WWWInline: the vrml data read in from the url should automatically be
transformed by the browser to fit within the bounding box specified.
This makes culling very easy, as the data is guaranteed to fit in the
specified area. This makes modeling easy, because the model will remain
where you want it - regardless of any changes made to the possibly
remote file. Its easy to implement, as the inline node is read in, its
bounding box is kept track of. After the whole file is read, a
transform (scale and translation) is added to transform it in the
specified bounding box. Note, there is no problem with nested or
recursive WWWInlines in the file as they will automatically fit in the
bounding box specified for their WWWInline (so that bounding box can be
used in the calculation of the bounding box for the file). Finally,
this is compatible with any models out there as long as they specified
the right bounding box for the inline node. What this solves is the
problem of having to change your vrml file any time someone changes the
url pointed to by your inline node. Considering that the data in the
inline mode might any where on the net, this coherency issue is a real
problem as specified in the current spec.
the transform would be:
(x1a, y1a, z1a) - (x2a, y2a, z2a) - the bounding box specified in
the WWWInline node
(x1b, y1b, z1b) - (x2b, y2b, z2b) - the actual bounding box of the
data stored in the file.
the transform is to scale to the same size, concatenated with a translation to the same place
Matrix T1 = translate to origin:
1 0 0 0
0 1 0 0
0 0 1 0
-x1b -y1b -z1b 1
Matrix S1 = scale to same size as specified bbox:
(x2a-x1a)/(x2b-x2a) 0 0 0
0 (y2a-y1a)/(y2b-y2a) 0 0
0 0 (z2a-z1a)/(z2b-z2a) 0
0 0 0 1
Matrix T2 = translate to position of specified bbox:
1 0 0 0
0 1 0 0
0 0 1 0
x1a y1a z1a 1
The final transformation to use is: P1 = (T2 * S1 * T1)
- Extensibility: The "fields" field should not have to specify
inherited fields from isA relationships. For instance, if
ExtendedMaterial has an isA relationship to Material, then the fields
of Material (e.g. ambientColor, diffuseColor, etc) should not have to
be specified - only fields that are new should be specified. This is
no problem to implement as long as the isA field is required to come
before the "fields" field.
This would make the example from the spec:
ExtendedMaterial {
isA [ "material" ]
fields [ MFFloat indexOfRefraction ]
indexOfRefraction .34
diffuseColor .8 .54 1
}
- Extensibility: Setting the isA field to "none" should cause the node
not to be drawn if the extension doesn't exist. All non-recognized node
types should default to an isA value of "none". That way the two
extension types show in the spec. are really the same. The first
example is not to be drawn if the extension node-type doesn't exist (as
the isA field defaults to "none"). The second example would be
implementeD as a Material node if the extension node-type doesn't
exist.
- Extensibility: I think "extends" is a more accurate name for "isA"
field. This also the term used by several object oriented functional
languages.
- Field changes: Similar to how state parameters can be passed into
URLs from forms, browsers should be able to handle URLs specified in
the form:
url?field=value&field2=value2&...&fieldn=valuen
When a browser sees a URL of this type it should change the values of
the specified fields in the scene graph when the URL is read in. This
gives a much easier way to perform limited interactivity. For instance
clicking on a icon representing a camera could set the whichChild node
of a switch to the proper camera.
This functionality would not be difficult for the browser writer.
Assuming the field change is a change to the current vrml scene (i.e.
the current URL), broswers with the ability to dynamically change field
values could recognize the URL as the current URL and make the
appropriate change. Browsers which cannot dynamically change field
values could re-read the file making the appropriate changes as the
vrml data is read in.
- The whole spec. needs spell checking: I noticed:
"acheivable" --> "achievable"
"adjascent" --> "adjacent"
"exicited" --> "excited"
"plament" --> "placement"
"retreival" --> "retrieval"
"specifiy" --> "specify"
"straightjacket" --> "straight jacket"
"whitespace" --> "white space"
----------