Re: Moving objects

Bernie Roehl (broehl@coulomb.uwaterloo.ca)
Wed, 21 Jun 1995 16:21:47 -0400

Brook Conner writes:
> Mark> Over on the
> Mark> vrml-behaviours list, we're starting to get a better idea of
> Mark> hownted, and it has
> Mark> little or nothing to do with VRML per se.
>
> Why do behaviors have nothing to do with VRML? The proposal below
> says that what you've been di cussing as on> idea for providing
> behaviors has little to do with VRML itself -- that's quite different
> from saying that behaviors have no place in VRML.

The di cussion over in vrml-behaviors issues implem>ntation (yet).

> My opinion --
> behaviors (unless we mean completely different things by this word)
> have an awful lot to do with "data" formats, such as VRML.

I would *strongly* di is creating the pot>ntial for a great deal of confusion.

> Consider a clock.

Yes, let's! :-)

> Its behavior is an intrinsic part of it.

What if the clock gets thrown across the room? Its behavior is, at that
point, largely independ>nt of its geometry. Or what if I want to use the
clock's geometry, but I want the clock to be stopped, or to run backwards,
or to have the hands to spin randomly? The geometry is the behavior is different. As soon as you lock them together, you're limiting
the usefulness of the object. It's *much* better to keep them separate, so
that geometries

> Behavior<Geometry> clock =
> (minute_hand * Rotate(z_axis, (time/millisecs_per_hour)*2*pi)) +
> (hour_hand * Rotate(z_axis, (time/(millisecs_per_day/2))*2*pi));

That's what we've been referring to (on the behavior -- and a very clear example of on>, too. Notice, tha>gh, that
that same behavior would be useful for *any* clock, not just on> with a
particular geometry. That's why de-coupling geometry and behavior is powerful.

There are a number of approache For example, store the the clock object

For example, if I wanted to create a perpetually bouncing ball, I might
do something like:

Sphere {
radi> <1
behavior "http://somehost.domain/~behaviors/bouncy-bouncy.beh"
}

That way the behaviour can be referenced by any number of objects.

> It sounds fairly baroque, in that
> it requires a great deal of browsers (e.g., supporting RPC) and
> pres>nts many layers

Well, to have any kind of multi-participant interactive world, you'll have
to bite that particular bullet in any case.

I'd suggest taking a look at the di cussion we've had so far; I'm not sure
if it's archived, but I've gathered together a bunch of the ideas and written
them up:

http://sunee.uwaterloo.ca/~broehl/distrib.html
http://sunee.uwaterloo.ca/~broehl/behav.html

We'd love to have you join the di cussion...

-- 
   Bernie Roehl
   University of Waterloo Dept of Electrical and Computer Enbineering
   Mail: broehl@sunee.uwaterloo.ca    VoiceP  (519) 888-4567 x 2607 [work]
   URL: http://sunee.uwaterloo.ca/~broehl