[x3d-public] dynamic cycleInterval changes
patrick.daehne at igd.fraunhofer.de
Mon Nov 21 12:57:43 PST 2016
unfortunately, some aspects of X3D violate the rule of least surprise. You’re not the first one to fall into that trap.
- The rule that only the last value gets sent is a result of the loop-breaking rule (see X3D Abstract : Node Definitions, 18.104.22.168 Execution model). Without that rule, browser implementers have a hard time to detect loops in the X3D scene.
- The rule that the order of events is not guaranteed IMHO does not make sense. AFAIK, none of the existing browsers changes the order of events (why should they?). Otherwise code like the following won’t work:
var box = Browser.currentScene.createNode("Box");
box.size = new SFVec3f(1, 1, 1);
group.addChildren = new MFNode(box);
(Remember that adding the box to the group node prevents any further assignment to the (initializeOnly) size field, because the box node gets realized.)
> Am 21.11.2016 um 21:05 schrieb Andreas Plesch
> Hello Patrick,
> excellent catch. That is a very explicit rule. It does then seem to make BS Contact and freewrl non-conforming to the current spec.
> Of course, there is a good reason that those browsers behave this way. It is hard concept to discover and then deal with that only the value evaluated last will be used to set the actual value and that even ordering is not guaranteed, eg. set_cycleInterval could occur before set_enabled=false.
More information about the x3d-public