Re: Methods vs. ROUTES

Johannes N. Johannsen (jojo@well.com)
Tue, 08 Apr 1997 15:11:36 +1200

> Park SungWoo wrote:
> >
> > 1. Event handler
> > The main reason for introducing event handlers is
> > to ensure that the behavior of a node 'MUST' be described completely
> > in its node definition or its prototype definition.

But what if the node itself is only describing behavior? What would
that look like? My understanding of the example below is that it
defines the viewable objects AND the behavior. I'm trying to detect
simple animation patterns in VRML 2.0, and at the moment, the approach I
am taking is to create objects that define only behavior.

> > Actually, this can be achieved easily in VRML as follows:
> >
> > # in VRML 2.0
> > PROTO T [...] {
> > DEF X Some_Node {...}
> > ...
> > DEF Y Script {...}
> > ...
> > ROUTE Y.out to X.in
> > }
> > However, if a Script node P controls a node Q, then P and its relevant
> > ROUTEs may be placed anywher in the VRML file. Hence, this approach
> > may decrease object-orientedness sometimes.
> >

The way I would see this is that P & Q & ROUTEs are an object. The
object contains the ROUTEs, but only references to P & Q. I don't know
if this always works in practice, but I find it much simpler to think
about this way.

For the patterns I am detecting (very simple ones), the ROUTEs
connecting a set of nodes define a higher level animation object. For
example, I need to detect if a Transform node is spinning. To do this,
I find the ROUTEs connecting the TimeSensor to OrientationInterpolator
to Transform. The template I use to describe this pattern is very
similar to the VRML++ connection class.

Once that is found, a more restricted form (for spinning) is detected.
But at this point, the object in my program is an Spin object -- it is
associated with a Transform, has an axis of rotation and a few other
fields. It doesn't have any TimeSensor or OrientationInterpolator.
Those are implementation details that I have to worry about when it
comes time to generate VRML.

One reason I have to use ROUTEs alone to identify the higher level
patterns (objects) is that the lower level nodes implementing those
patterns (TimeSensors and interpolators), can be shared among several
higher level patterns. For example, the same TimeSensor can many
different animations.

I'm at a loss how this affects the Methods vs. ROUTEs approaches, but
just thought I'd describe the sorts of problems I've been coming across,
since it seems to be in the same area.

JJ