-Jan
----------
From: gavin
To: Jan Hardenbergh
Subject: Re: Comments VRML 1.0 (Draft)
Date: Friday, December 02, 1994 7:35PM
> Is the VRML (IFF) parser really available somewhere?
Soon, I hope. It has been bouncing back and forth between Menlo Park
(Mr Pesce), Boston (Paul Strauss) and Mt View (me) for the last few
weeks, undergoing constant revisions. Stay tuned...
> - Should require no new support from HTTP server. Just more files.
> Or do we expect all VRML to only come from VRML servers?
I believe the general plan is to define a static description format
that can use http/ftp/whatever first, get it implemented and have
people start finding all the problems with it, and then working on a
more dynamic, real-time protocol to support the really really cool
stuff like telepresence...
> What is the scoping of names? Can a name be used outside of the
> curly braces (node) it was defined in?
The scope of a name is lexical, so yes, it can be used outside the
curly braces it is defined inside of. A name goes into scope at the
DEF, and stays in scope until another DEF with the same name is
encountered or the end of the file is encountered. Names are not
shared across files.
> Can I put children in any node? I.E. Sphere { radius 1 Seperator
{...} }
> A quick test of OpenInventor does not like this.
Only group nodes (Group, Separator, Switch, LevelOfDetail) may have
children.
> Do nodes always have names? If one is not specified, are they null?
Uhh... that's outside the scope of VRML, since DEF/USE are the only way
to use names in VRML and a node MUST have a name for DEF/USE to work.
In Inventor, yes, nodes always have names-- most nodes have the empty
string ("") as their name. If the Inventor file writer needs to write
out a node with an empty name using DEF because the node is multiply
instanced, it will create a throw-away identifier of the form
"+number"; on read, Inventor throws away the identifier, and the node
again has no name.
> The vertical seam in a cone is in the YZ-plane in which the cone is
> defined, right?
Right.
> (Inventor calls this object coordinate space) or in the
> YZ plane after transformation (World coordinate space).
Nope.
> Is anything
> ever defined in view or screen space?
No. All objects (including lights and cameras) are defined in object
space.
> - please have a short section on spaces in the document (right hand)
> - we need to define the viewing & screen space in order to interact
> with the models. This is something that PEX/PHIGS did pretty well,
> tho, as usual it was overdone. We need it when we point at things
> and need to convert from window coords to world coords.
> (the notion of a digitize plane to which the pointer gets projected
> is useful for drawing)
Agreed. I'm swamped-- somebody want to volunteer to write this up?
(Jan, wanna take a shot at it?)
> For the cube, front is parallel with the XY plane, with positive Z?
Yes.
> "the current cumulative transformation" includes the object to world
> and camera transformations? anything else?
Ummm.... not the camera transformations, although I'm not sure that
matters, since nothing is defined in world space.
> The structure of the document might be changed. I could not grasp the
> material binding stuff until I skipped ahead to the MaterialBinding
> node. I realize this is a second level of editing - better get the
> spec specified, then make it understandable...
I'd agree, although most specs I've read are really hard to understand
unless you already know what they're talking about... Take a look at
http://www.sgi.com/tech/Inventor/VRML/VRMLDesign.html for what is
essentially a more readable version of the spec.
> Light sources are affected by "the current transformation." Is that
> different from the "current cumulative transformation?"
No.
> No TriangleStripSet, QuadMesh or NurbsSurface? Why not? The Inventor
> Mentor says on page 109 that triStrips and QuadMeshes are faster...
> If I were going to pick one primitive, it would be triStrip.
It isn't terribly hard to convert from IndexedFaceSet to
IndexedTriangleStripSet, and IndexedFaceSet is a superset of the
functionality of tristrips/qmeshes.
My next two choices for shapes to add to VRML would be
IndexedTriangleStripSet (because it will save network bandwidth since
it specifies more triangles with less information than IndexedFaceSet)
and QuadMesh (same reason). If there's consensus from the people who
will have to implement VRML, sure, lets add them. I just don't want to
subject them to endless weeks of implementing rendering code for every
single Inventor shape (I've done it, it wasn't real fun).
> NURBS are a trickier issue. However, since network bandwidth will
> be an issue, I think is is worth byting the bullet and putting NURBS
> in VRML.
As I think was said in a later message-- not until there is a really
good public domain implementation available that makes implementing
them really easy. And not if it makes VRML implementations so big you
need tens of megabytes to run....
> Where does the ambient light get specified?
It doesn't. In my experience, that feature is hardly ever used.
>Don't we need an
> Environment?
Again, in my experience, Environment is nice but not necessary.
> If the answer is that the environent is not part of VRML,
> then we need to supply an appendix that recommends what parameters
> should be controllable.
Why? That's a quality of browser issue, and should be left completely
up to browser implementors, just like which fonts are supported are
left out of HTML (I really hope I don't start a why-HTML-is-broken
thread here...).
> Is the Ambient Color in the cycling example right? 0, 1, 1, 0???
(0,1,0,1)
Yes. For the checkerboard, you want 0,1,
1,0
> Does OpenInventor allow control over the attenuation of lights???
> Perhaps it is better not to allow control, since it just confuses
> most mortals. Anyway, please comment.
That's part of Environment in Inventor, not part of the lights.
> As mentioned before, filename for the texture URL is confusing.
Agreed; which do you like better:
"url" (could be a problem if URN's ever happen)
"name"
"externalReference"
> Will their be rendering semantics specified? I.e., are OpenGL
rendering
> semantics implied?
Definitely not; I hope VRML will be implemented on lots of different
rendering architectures.
> Will people care?
People will only care about how good the pictures are.
> Is there a default extension for textures?
> The VRML spec should specify the file format of textures.
Yes. That's an open issue. Are .jpg and .gif good enough?
> Is there a default checkerboard texture? (i.e. require viewers to
> find "checker.txr" locally.
No. But it is really really easy to do:
Texture2 { image 2 2 1 0xFF 0x00 0x00 0xFF }
... to do a 2 by 2 black-and-white checkerboard texture.
> Is anyone working on public domain servers & viewers? This stuff will
> catch on much more quickly if those are made available.
As soon as the SGI ftp-meister gets back from vacation, there will be
Inventor implementations of WWWInline and WWWAnchor that I wrote
available. Complete hacks, but they should be a good start if you're
on a system that supports Inventor.