Re: LANG: Re: scalability (VRML)

Brian Behlendorf ([email protected])
Thu, 16 Jun 1994 01:55:39 +0000 (GMT)

Mark Waks wrote:
> Greg writes:
> >How about some kind of scalability? If a system has a high-bandwidth
> >line and fast renderer, there is no reason to not allow thousands of
> >texture-mapped polygons. If the system has a 2400 baud link and CGA
> >graphics, they could get by with wireframe graphics with only the
> >most important objects shown. Other systems might want to just see
> >simple text.
>
> Which gets us back to the language issue of object classes. As this
> discussion goes along, I become more and more convinced that, at least
> in the long run, we *must* have a really object-oriented solution here.
> The description of a scene shouldn't incorporate a thousand polygons --
> it should say "Put a six-foot refrigerator over there". *Which*
> refrigerator image the user gets depends on how his system is configured,
> and could be anything from a photographic-quality image to a vector
> outline. Both should be subclasses of a general object class of
> "refrigerator", which would define the important characteristics
> of the beast, and might or might not include a basic image.

Aha! Here's an interesting problem. At what point does the author's
wish to have you see "his" refrigerator conflict with your desire not
to have to download "his" refrigerator but view one of your own?
Perhaps it's done this way - you enter a kitchen, and the kitchen
scene downloaded to your computer really quickly because it's just a
bunch of simple bounding boxes - a box here for a fridge, a box
there for a stove, etc. Now, the browser you are using is smart,
as was the author. The author added a semantic, hidden tag to the
refrigerator object saying, essentially, "This is a REFRIDGERATOR -
its code is at <URL>" Now, your browser happened to find in its
local cache an object which was named "REFRIDGERATOR", so it gives
you the option of loading the local version (stretched to fit in the
right place) or fetching the "real" one. Now, if the author REALLY
wanted you to see his fridge, he could call it "REFRIDGERATOR-NEW"
or "REFRIDGERATOR-<AUTHOR>", and it wouldn't give you the choice of
locading the local one. Even better, just like the "delay image
loading" option in certain web browsers, you could say "load only
local cache" and the browser, upon downloading the kitchen scene,
would insert its local cache for REFRIDGERATOR and STOVE, but
MICROWAVE and DISHWASHER would have to wait because there are no
locally defined objects for them. A "load local cache, then
remote objects" and a "always load remote objects" option would
be great, too.

This is more of a browser issue, though - if we go along with
naming all objects in a given scene, and recommend making VRML
files as modular as possible, we go a long ways towards optimizing
bandwidth.

> BTW, there are two subproblems to this matter that we should bear in
> mind. On the one hand, we want to be scalable with respect to how
> much processing power the user must have; on the other we want to be
> scalable with respect to how much bandwidth the user has. They're
> closely related, but not identical, and we should bear both in mind
> as we discuss language alternatives...

I consider processing power to be less important than bandwidth, but
a highly modular system will help out there, too.

Brian