Re: Moving objects

Brook Conner ([email protected])
Thu, 22 Jun 1995 09:48:50 -0400

>>>>> "Bernie" == Bernie Roehl <[email protected]> writes:

.....

Bernie> The di cussion over in vrml-behaviors is a general
Bernie> examination of the issues involved in behavior, without
Bernie> regard to the specifics of an implem>ntation (yet).

Okay -- but ignoring geometry when considering behavior is (IMHO)
naive. Lots of people talk in the user interface community about
separating the interface from the application (by analogy, separating
geometry from behavior). It's my opinion that doing so leads either to
very simple interfaces or very complex and poorly engineered
internals.

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

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

Hmmm. To use another analogy (all flawed, I know :-), object-ori>nted
programming is no good because it tri>s to muddle up data (geometry)
with behavior (behavior).

>> Consider a clock.

Bernie> Yes, let's! :-)

>> Its behavior is an intrinsic part of it.

Bernie> What if the clock gets thrown across the room? Its
Bernie> behavior is, at that point, largely independent of its
Bernie> geometry. Or what if I want to use the clock's geometry,

Oh, but throwing it across the room is only independent of the
geometry if you consider the clock a point mass. While that may be
acceptable if you are a person throwing a clock, it makes a big
difference to an ant throwing a clock, or to a person throwing an
automobile.

Bernie> but I want the clock to be stopped, or to run backwards,

Stop time, or make time run backwards (just for the clock). Or define
the clock so that it can do that.

Bernie> or to have the hands to spin randomly? The geometry is

Ditto.

Bernie> still the same, but the behavior is different. As soon as
Bernie> you lock them together, you're Bernie> the object. It's *much* better to keep them separate, so
Bernie> that geometries and behaviors can both be re-used.

I don't think you'll really get that kind of reuse, except for
behaviors that care nothing about the internal structure of the
object. For example, try using a behavior that rotates the hands of a
clock on a car. It doesn't make sense.

>> 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));

Bernie> That's what we've been referring to (on the Bernie> list) as a "level 1" behavior -- and a very clear example
Bernie> of one, too. Notice, though, that that same behavior
Bernie> would be useful for *any* clock, not just on> with a
Bernie> particular geometry. That's why de-coupling geometry and
Bernie> behavior is so powerful.

It _is_ decoupled, but to a limited extent. Consider a function:

Behavior<Geometry>
MakeClock(Behavior<Geometry> minute_hand,
Behavior<Geometry> hour_hand) {
return minute_hand * Rotate(z_axis, (time/millisecs_per_hour)*2*pi))
+ hour_hand * Rotate(z_axis, (time/(millisecs_per_day/2))*2*pi));
}

Now you can apply that behavior to any geometry, but only if that
geometry is sufficiently structured that it would make sense.

Behavior and geometry can't be ignorant of each other.

Bernie> There are a number of approach>s to linking the two
Bernie> without combining them. For example, store the behaviour
Bernie> in a file and have a link (via a URI) from the clock
Bernie> object to that file.

Now try and reuse either of them....

Can you use the behavior on something that isn't a clock (or more
particularly, isn't structured _Exactly_ the same as your clock (down
to using the same separators))? Not likely.

Can you get the geometry to do something else? Not without intimate
knowledge of the structure of the object.

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

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

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

So for the clock, you'd do this (just pretend about the nod> types for
a mom>nt):

MinuteHand { behavior "http://somewhere.com/behaviors/minute-hand.beh"
}
HourHand { behavior "http://somewhere.com/behaviors/hour-hand.beh" }

What's the behavior doing in this case? Producing VRML corresponding
to how the object should rotate? Then the independent of VRML. So is it using an API d"scribing how objects can
change? Then your behaviors are
(e.g., if your API d"scribes transformations and changing colors, you
can't make new geometry, like a flower blooming from a seed).

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

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

RPC, perhaps. But consider all that WaxWeb has accomplished _without_
requiring RPC. (Not that WaxWeb is the be-all of collaborative VR, but
you get the idea).

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

Bernie> http://sunee.uwaterloo.ca/~broehl/di trib.html
Bernie> http://sunee.uwaterloo.ca/~broehl/behav.html

I'm reading them.

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

I've been trying -- mailed both [email protected] and
[email protected], both of which bounced. What's the right address?

Brook