my two more 2 cents on VRML (was Scripts vs. APIs)

pei@ora.com
Thu, 8 Sep 1994 12:42:04 -0700


Um, since I'm the one who most recently sparked this scripting issue,
I feel that I should clarify one thing, so there's no confusion on
at least this point:

I would *not* suggest that we use any proceedual language (such as
viola scripts) for VRML as might be implied. I too would hope that
VRML is declarative.

OK, now that's out of the way, on to where I think where a scripting
language fits in.

One place where a scripting language can come in is for programming
the behaviour of objects described by VRML. Another is for smarter
generation (on the local machine) of objects, as I see Dave Ragget
and John Ellson just mentioned.

Some salient points of what I was thinking VRML might be like:

* Uses SGML, so that it might blend in with HTML better.

* Separates the objects/scene description language (VRML) from
the procedual language extension that is used to program
object behaviour.

* Objects can send and receive messages. Scripts can be attached to
the object to program the behaviour of the objects...

* There is an set of standard messages that objects send&receive.
This is the "API" part I suppose. If this part is rigidly defined,
then the script could be Viola or TCL or whatever script.
Or, hook up to RPC so that the logic can be running on remote machines
with more CPU crunchies.

* Some kind of objects changes synchronization/propagation mechanism
such that changes to one object instance on machine A will be
reflected on machine B,C,D... (ie: move a chess piece on a board,
and everyone watching the board sees the piece moved).

Here's an example from a VRML proposal that I had started but
havn't the time to finish...

Suppose you want a page that looks like the one below, where there
are two buttons which bring the square closer to or farther from view.

------------------------------------------------------
A Revelation in Perspectives

Things look smaller when it's farther away, bigger when it's closer.

+------------------------+
| /======\ /=======\ |
| |Closer| |Farther| |
| \======/ \=======/ |
| |
| |
| |
| +---+ |
| | | |
| +---+ |
| |
| |
| |
+------------------------+
------------------------------------------------------

And this is how you might mark up the "document/scene". Note that it's
HTML mixed with VRML. The <GRAPHIC> tag is basically a container for
VRML.

Don't mind much about the exact syntax and tag name choices.
It's the basic architecture that I'm showing here.

-------------------------------------------------------

A Revelation in Perspectives

Things look smaller when it's farther away, bigger when it's closer.

-- shown to illustrate different ways of accomplishing the same task.
-- The first version is scripting-language neutral but will probably be
-- too limiting for many things. The second version is more flexible,
-- but is language dependent. Hopefull you should be able to plug in
-- whatever language or a RPC interface into the action handler.
-->


-- a while to come up with a usable API. But it can provide
-- minimal object behaviour programmability without getting
-- into a scripting language war. (Thou, this is a feeble
-- scripting language disguised in SGML)
-->








-- is more appropriate.
--
-- Use either scripts or the next action handler which is more
-- limited but declarative.
-->

switch (arg[0]) {
case "buttonUp":
for (i = 0; i rotate(0, 0, 1.0);
render();
}
return;
break;
case "shrink":
scale(1, 1, 1.5);
return;
break;
case "expand":
scale(1, 1, 0.5);
return;
break;
}
usual();







Click on me, and I'll twist



switch (arg[0]) {
case "buttonUp":
send("#sq1", "closer");
break;
}
usual();







Closer
Bring the square closer to view



switch (arg[0]) {
case "buttonUp":
send("#sq1", "farther");
break;
}
usual();




Further
Push the square further from view

-------------------------------------------------------

The SC attribute says that whenever the attribute in the object
changes, the change should be relayed to a server which broadcasts
the change to all other browsers looking at this object...
Have to think about this more...

OK, so that's what's been on my mind regarding VRML.

More thought needs to go into making it more "open" and extensible
so that new object classes can be defined... (so I guess the particular
graphics types should be identified as an attribute, not tag name).

Anyhow, I'm also echoing the opinion that VRML should be declarative,
but needs hooks for some kind of scripting language so that objects
behaviour can be programmed.

-Pei Pei Y. Wei
wei@ora.com
wei@xcf.berkeley.edu