> But it sounds like we'll need a "name registry" to handle the
> identification, i.e. naming of standard objects such as "utah-teapot" and
> "bay-window" (apologies to architects/interior designers reading the
> list). In this way a VRML scene can be published which instances such
> objects and allows the browser to optimize bandwidth, or provide a
> personalized view of an object (a *key* feature, according to some human
> factors folk) by using locally defined rendering descriptions. Naturally,
> such scenes should also define fallback URLS in case the named object
> can't be found locally.
"utah-teapot" sounds like a good idea; it's a very specific object, with
a very specific shape, and I'm sure a standard size could be determined
from which to do scaling. "bay-window", though, would be a bad object,
unless you want something like "pitt-bay-window". A bay window can be
instantiated in a great variety of shapes and sizes; this would make use
of such in a shared space essentially impossible. Personalized views of
objects, similarly, would fail utterly to make any kind of sense in
shared spaces; thus, this is really outside the scope of VRML 1.0 and
(hopefully) any of its lineal descendants.
Languages for concrete scene specification should be separate from
languages for abstract scene specification for a lot of reasons, not
least because for shared scenes they would need to be instantiated at
different times. This is entirely without even thinking about the
issue of the way including logical scene description in VRML as we now
know it would limit choice in that area and would tend to give an
undeserved endorsement to a wholly inadequate method of scene
description. (Don't tell me it won't be wholly inadequate. This has
never been done before, so I don't really see how it can help being
wholly inadequate no matter how many supergeniuses may be working on
the project. Version 0.1 is always broken in any software area. It's
a law of nature.)
-- James Deikun (University of Pittsburgh) #include <std_disclaimer.h>