Caching and Common Objects

Paul Lindner ([email protected])
Mon, 29 May 1995 01:14:26 -0500 (CDT)


I for one think everyone should stand back and take a look at the big
picture before we pollute VRML with caching schemes. First, let's
define the problems we want to solve:

1) World builders want the potential to specify an object in
"real-world" terms. An object builder wants to say, "Put an
elephant" at 0,0,0; insead of having to specify the exact methods
to draw a specific elephant.

2) Browsers don't want to download huge models of elephants,
especially if they have a perfectly good copy of an elephant in the
local memory, hard disk, or CD-ROM drive.

3) Everyone wants to have some sort of centralized library of standard
objects that could be easily replicated. Everyone wants a way to
access a repository of information that might have a model of an
elephant.

--------
These are hard problems without easy answers.

There might be a solution to this interrelated set of problems. The
first part of the solution lies in specifying the characteristics of a
"Building-Block". The second part of the solution is retrieving
"building-blocks" based on characteristics.

An example of prior art in this situation is X display fontlists. You
specify a font in X based on the fonts characteristics. The more
characteristics you specify, the closer the approximation you get. We
should be able to do the same thing with 3D objects.

First let's solve this problem with lots of hand-waving..

Here's how a World-builder might use such a system in english:

Give me a a highly realistic 10 meter long, 20cm wide, 10cm tall, 5mm
thick steel I beam and a 2x4

Here's how a building-block manufacturer might use such a system in
english:

I-Beam, Girder:
Materials: Steel, Aluminum, Anodized Aluminum, Platinum
Sizes: Any width, length, and height. Any thickness less than
the height/2.
Quality Levels: #1 Realistic at 20m, #2 Realistic at 5m, #3
Realistic at 1 meter

2x4:
See Rough Pine wood 2.25in x 4.5" by 8 feet long

Here's how a Browser might use the above tools:

Search local resources for a copy of a 2x4.

Contact local building-block agent for a copy of an 2x4.
(Building-block agent goes out and finds a provider of the
building-block caching it locally if it's been requested many
times.)
----------------------------

So I'm sure you're all saying, sure Paul, this is all fine and good,
but how do we implement it? Here's the technology that's needed:

1) Lots of scripts that can generate materials at different sizes and
resolutions.

2) A standard method of specifying characteristics of
"building-blocks". This meta-information could be represented
with a URC.

3) A standard method of retrieving a building material given a list
of characteristics. This could be as simple as standardized
arguments to a cgi script, special headers in an HTTP
request, or a new protocol similar to whois++.

So, let's see if this solution applies to the problems:

For #1, yep we've got it covered. You could ask for a specific
object by it's characteristics. For #2, this proposal allows you to
keep building materials data cached locally or in a nearby cache if
you want.

I haven't covered #3 very well... There should be standard
definitions for objects I guess. The problem is that such standards
get out of date the minute they're decided on. I think we should let
the marketplace sort it out. This will work as long as it's easy to
find common cached items locally.

-- 
 | Paul Lindner | [email protected]   | Slipping into madness
 |              | Distributed Computing Services  | is good for the sake
 | Gophermaster | University of Minnesota         | of comparison.
///// / / /    /////// / / / /  /  /  /   /      //// / / / /  /  /  /   /