What is very interesting with Amulet is the fact that you have a
prototype
instance object system integrated with constraints. Amulet objects are
not typed. They are defined by a prototype and a set of local slots
(fields).
Objects are created by creating a empty object that has for prototype an
existing objects. Initialising the system consists in creating the set
of
basic prototypes that will serve to create new objects.
Every slot which is not found locally is searched by delegating the
request
to the prototype. Creating a new object is done by creating an empty
object that will delegate all data requests to its prototype. Amulet's
objects
only have one prototype, but we could add multiple inheritance by
allowing multiple prototypes or parent slots.
Each slot may contain some data or a method. The type of values
that are contained in slots is not determined and can evolve at
run-time.
Which slots are installed in an object can also evolve at run-time
allowing to enrich individual objects with richer behavior or to modify
the behavior of the object depending on the execution context.
The value of slots (containing methods or slots) can be computed by one
or several constraints. Amulet offers two constraint solvers, one for
one
way constraints and the other one for smooth transitions between
successive
values. In Amulet, it is very easy to write a constraint. You just write
a routine that returns the value and then you install it in the slot.
All
the slots that are traversed during the evaluation of the routine are
marked as dependencies. If the value of any of these slots changes, then
the constraint is mark invalid and is reevaluated. During reevalution, a
new dependency list is built from the slots being traversed. It may be
totally different from the previous one.
For having worked with VB2 and Amulet extensively (i3d v2.0 and v3.0 are
built using Amulet), it is my feeling that for a langage like VRML, the
concepts that are in Amulet (prototype-instance object models integrated
with one-way constraints with automatic dependencies) is exactly what we
need. Prototypes and slots maps well with nodes and fields, while
one-way
constraints maps well with clever routes.
In VB2, the role of paths was to build the dependency list. Paths are
not
needed in Amulet. They are integrated in the routine code that
implements
the behavior of the constraint. For the programmer, the Amulet solution
is much more easy.
Now, when it comes to having a PARENT slot, you will have to think about
multiple instances of a node in the graph. That is the main reason why
you
are not able to go up the graph in OpenInventor and VRML.
In i3d v3.0, multiple instances are obtained with multiple objects
sharing the slots that corresponds to VRML fields. That way, I can
maintain all kinds of information that depends on the position in the
graph, like the parent, the global transform.... I call these sharing
groups. The promotion/depromotion of an object to/from a sharing group
is done automatically simply by declaring the VRML slots as shared/local
when
you add/remove the children to nodes. That's a good example of the power
of prototype-instance systems where objects can change their behavior at
run-time.
All the best, waiting for your comments.
-- _____________________________________________________________________________ Jean-Francis Balaguer Technology Manager 3D/VRML Artemedia Online SA e-mail: balaguer@artemedia.ch rue de Morges 24 tel: +41 21-706-2084 fax: +41 21-706-2071 1023 Crissier - Switzerland www: http://www.artemedia.ch/~balaguer/