In my mind, pointer variables in Garnet and Amulet are the
equivalent of paths in VB2. It is true that most constraint algorithms
do not take 2nd (or higher) order control into account. So it is true
that skyblue do not handle pointer variables, but... the algorithm
can be modified to incorporate them (see VB2).
> If the answer to both questions is YES, then Garnet's
> one-way constraint model seems to be the answer. But
> then there is the problem of how to implement constraints
> with VRML 2.0 and JavaScript-Scripts or Java-Scripts.
>
One way constraints are enough in nearly all cases. I have programmed
nearly the same system in Amulet (one-way constraints) and in VB2
(multi-way constraints). I never felt that the constraint system in
Amulet was limitating. It was mainly due to its capacity to build
automatically dependency list.
Now if you think about VRML, ROUTEs are just one-way equality
constraints. Adding more complexity to routes would allow us to
incorporate one-way constraints to VRML.
ex:
// Assume we have access to the parent and globalTransform of a node
DEF SFColor same_diffuse_color_as(SFNode node) {
if (node.appearance)
var material = node.appearance.material;
if (material) {
return material.diffuseColor:
}
}
return new SFColor(0.8,0.8,0.8);
}
DEF NODE Shape {
appearance Appearance {
material Material {
diffuseColor 1 0 0
}
}
}
DEF NODE2 Shape {
appearance Appearance {
material DEF M Material {
diffuseColor 0 0 0
}
}
}
ROUTE same_diffuse_color_as(USE NODE) TO M.diffuseColor
If you don't care about routes in the syntax, we could go a step
further and do it as
DEF NODE2 Shape {
appearance Appearance {
material DEF M Material {
diffuseColor IS same_diffuse_color_as(USE NODE)
}
}
}
> Currently in VRML 2.0 fields of type SFNode the
> value NULL or a pointer to a node (object) is stored.
> To use Garnet's constraint solving mechanism we have
> to attach to each field additional information:
> outofdate : indicates if the value of the field is out-of-date
> dependencies: list of fields which depend on this one
> eval: a method (constraint) to compute this field's value
> timestamp: number of times "eval" was executed
>
Correct. Timestamp might not be necessary....
> 3) How do we attach this information ?
>
Do we want to propose an evolution of VRML that will use constraints
or wrap constraints around the existing VRML?
> Now the idea is, that if a value of a field is changed
> the values of all fields depending on it are recomputed.
>
In practice, you might want lazy evaluation too.
> 4) How do we get the information, that a value has
> changed? We cannot expect VRML programmers to
> use only our function to access and modify fields !
>
Normally, the field should be aware of its changes and inform its
dependent. Otherwise, you need to do event handlers (yack)
-- _____________________________________________________________________________ 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/