Miriam wrote:
>* I would like to see a simpler, less wordy language.
I totally agree with Cindy: the problem here is not the wordiness of the
language, it's the dearth of good authoring tools. Nobody should ever have
to write {VRML, X3D} by hand. Top creators will probably still have to
tweak it by hand, but wordiness-of-syntax is much less of an issue for that.
quoting John:
>>Certainly "appearance Appearance { material Material { ... } }" is ugly as
>>heck and should be immediately killed
I remember the meeting in which that syntax was chosen. It was Gavin,
various other VRML designers, and the Performer engineers (and me and maybe
Josie taking notes for the Handbook and the spec). The Performer engineers
convinced the Inventor engineers that separating things out that way made
certain important optimizations possible in the browser. Everyone was put
off by the syntax, but the winning argument was that authoring tools would
soon hide the syntax. Unfortunately the authoring tools took a long time
to come to fruition, and still aren't as far along as they ought to be.
But that's the direction we should be heading.
Think about it this way: imagine a world in which images have to be
edited by hand in a binary editor. You have to fiddle with binary numbers
representing strings of pixels of different colors. You might say "the
binary representation of images sucks!" But the real answer is PhotoShop.
>* Allied to the above point is routing and interpolation.
Repeat after me: Authoring tools. Authoring tools, authoring tools,
authoring tools. It's a good mantra.
(Cosmo Worlds uses a "Keyframe Animator" to take some of the sting out
of interpolation. It's not all the way there yet -- it has rough edges and
non-intuitive aspects. But it's way better for most people's purposes than
typing interpolator numbers by hand.)
(I do, btw, like your idea of vectors as properties of objects. The
VRML event model has a *lot* of rough edges.)
>* a general solution to the gravity problem
I played a Mac version of the arcade game Gravitar once; you could
design your own levels, which involved placing gravity generators in
various places. I rather liked that approach -- very simple and intuitive
from the content creator's standpoint. "This point is a source of gravity;
things will tend to fall toward it." For simplicity of VRML worlds smaller
than Earth, we could have DirectionalGravity instead of PointGravity...
>* a general collision solution
Whether or not the physics engine is in the core spec, for our purposes
we *will* need a physics engine. I saw quite a nice one at SIGGRAPH '97,
but don't know how much it succumbs to the problems mentioned on the main
list (about chaotic systems and such).
>* Boolean objects. From a content-maker's viewpoint they would make life a
>LOT easier, but I think it might slow the player software a lot. Perhaps
>that has to be relegated to just the sculpting software.
Yah. There's a name for this, but I forget what it is. We'd love to
have it be part of Cosmo Worlds (it's one of the things that designers
always ask for), but it's definitely not gonna be in 2.5.
>I remember a post about a year ago by somebody who managed to make sound do
>the doppler thing with a subway train approaching, passing and going
>away..
I just saw this again the other day. I think it's at
http://www.janvier.com/ -- but that may just have been slowing down the
sound as the train arrived.
So how do we want to present our list of demands^H^H^H^H^H^H^Hdesires?
Should we compile a big wishlist and just forward it to the Consortium? Or
should we try for something more formal? Perhaps get the CDWG folks in on
this? (I dropped that list for lack of time some months back, but it does
seem like the sort of thing they should be discussing too.)
--jed
Jed Hartman * [EMAIL PROTECTED]
Wordplay column: www.kith.org/logos/words/
