These are my opinions. Let me know if I'm wrong.
> - What sort of highlighting is going on, and what does the shininess
factor
> mean in the Material? e.g. is a shininess of 0.1 exactly defined to mean
> some particular Phong distribution? Also, which Phong distribution (see
> Graphics Gems IV, p. 388, "R.E versus N.H Specular Highlights" to know the
> difference)? This is pretty important to know if you're trying to create
a
> particular visual feel.
I'm not sure this has a good answer. Gavin has said before that we do not
want to specify exact rendering semantics. VRML browsers should be free
to use whatever renderer. However, Eric points out in private mail
---
I find that a little strange. This ain't art school, the shading equations
have been around a few decades now, there's general agreement about ambient
and diffuse, and specular has two flavors. Saying
shininess = 1 - (1/phong-power)
and saying use N.H shading or somesuch is no big deal - it's fairly
reasonable
to convert to other shading models, and shouldn't hurt anyone's
implementation. We don't need OpenGL conformance testing, but specifying
the
general equation would take two lines of text and probably wouldn't limit
anyone (if it does limit someone, I'd like to know why).
--
Seems reasonable.
> - ShapeHints: if I set shapeType to SOLID (which then clues the renderer
in
> that we can safely backface cull), do all succeeding objects within this
node
> inherit this property, even if some other ShapeHint is used? For example,
say
> I had code:
>
> Separator {
> ShapeHints { shapeType SOLID }
> Separator {
> ShapeHints { vertexOrdering COUNTERCLOCKWISE }
> ...some data...
> }
> }
>
> would the vertexOrdering ShapeHint actually set the shapeType to its
default of
> UNKNOWN_SHAPE_TYPE, or should the hint from the outside apply? I would
have
> thought the latter (after all, the deeper nested ShapeHints{} call is
setting
> only vertexOrdering), but browsing the qvnt.zip parser it looks like any
> call to ShapeHints always resets the defaults, and you must explicitly set
any
> hints you wish to inherit again. Which is it?
I think that the node always has those fields. So, you have to set them
everytime. I think you would need a mask of sorts if you only wanted
to set some of the fields, IMHO.
> - Similarly, the creaseAngle value always defaults to 0.5 - say I don't
want to
> use this angle. Do I have to explicitly turn this off (I assume 0.0 means
> off) every time I call ShapeHints for something else?
>
> - ShapeHints: does the vertexOrdering type COUNTERCLOCKWISE imply that
the
> first three vertices of the polygon are also convex, so a normal can be
> quickly computed? I know SGI does not need this to be the case (they seem
to
> get the signed area of the entire polygon on the fly), but other renderers
> might assume this hint means that the polygon's first three vertices do
not
> form a concave angle.
Seems like a good clarification to make.
> - What, if anything, is supposed to happen if a polygon is
self-intersecting
> (e.g. a star shape)? Are these simply verboten (I believe SGI doesn't
handle
> them well)? If so, this is worth noting in the spec.
I'd go for verboten. This seems like a lot of buck for a little bang - at
least in 3D.
> - NormalBinding: is there any way to attach both a face normal and
> normal/vertex's to a face? I don't think OpenGL allows this, so I suspect
the
> answer is no, but I thought I'd check.
I think you are right. Do you really want to cull polygons based on
something other than their vertex normals? (That was the only case where
that made a difference, no?)
> - MaterialBinding could use a lot more explanation of all the options:
what
> does DEFAULT mean, vs. OVERALL? What's PER_PART vs. PER_FACE, exactly? A
> lot more examples (in general) would be great. I suspect if one read the
> Inventor docs carefully this might become clear, but this information
should
> be a part of the VRML documentation.
I believe DEFAULT would be browser dependent. How about
The definition of a part for PER_PART and PER_PART_INDEXED is:
a face for face sets and cubes, one of top, bottom or side for cylinders,
bottom or side for cones, and a line segment for the line set.
Examples, Yes, I'd like that, too. But, the spec really should be done
before the browsers are out. Examples illuminate, the spec must specify
unambiguously, but having it a little dense is OK.
> - Line Length: for the ASCII format (and I haven't seen anything other
than
> "we need one" for a binary format), is there a maximum number of
characters
> per line? This sounds trivial, but lines can get extremely long for
things
> like IndexedFaceSet: imagine you write out indices for a circle with 100
> points in it on a single line. The line could be 300+ characters long,
longer
> than some people's default 256 character input lines. Is there (or should
> there be) an explicit line length limit?
I think the spec should ignore this.
> - Carriage Returns: sounds silly, but what constitutes a carriage return?
> Really, the only major question (I think) is whether parsers should also
> recognize "\r" (which the Mac uses, I believe) as an end-of-line
character,
> vs. Unix's "\n" and DOS's "\r\n". I've personally run into headaches
with
> importing DXF files from Macs, until I changed the text reading C++ class
to
> accept all of the DOS, Unix, and Mac conventions.
So, does a file coming from the Mac have just \r? I know that I tripped
of a .wrl coming from the EMWACS (NT) server. I had to add \r to the
QvLib parser (Oh, by the way, the concat stuff in QvBasics.h ought to
be more general. I know two people who've spent hours debugging
that.)
-Jan