But we're thinking, OK, if we can still make modest changes to the spec at
this point why not throw in "WWWSwitch". Why? Because I'm afraid it could
take a long time to come to agreement on something as complex as general
purpose behaviors. In the meantime VRML 1.0 could be much more powerful
with a limited, but useful facility that would still be useful even when we
have a more complex facility (you know, simple tools for simple cases).
The essence of WWWSwitch is that it has multiple children, displays one of
those children at a time, and "switchs" to the next child (with wraparound)
when chosen (clicked on or whatever). The children, as usual, can be
anything: Separators, WWWAnchors, WWWInlines, Lights, Cameras, etc. This
provides a simple way to do simple, but very useful interactivity. It's
also very simple to implement -- if you've already done both Switch (the
regular one) and WWWAnchor, this is a piece of cake.
What can you do with it? You can make doors open and close when clicked,
turn lights on and off, step through a series of viewpoints, implement 3D
"push buttons", etc, etc. For example:
WWWSwitch {
whichChild 0 #Initially display first child
Separator { #Child 0
# Geometry for closed door
}
Separator { #Child 1
# Geometry for open door
}
}
Something to think about anyway.
-Mike Heck
[email protected]
-------------------------------------------------------------------------
Specification:
WWWSwitch
This group node is almost identical to the Switch node (traverses one
or none of its children, whichChild field specifies index of child to
traverse). The only difference is: When whichChild is greater than or
equal to zero and one of the children of the active child is chosen,
the WWWSwitch increments the value of whichChild. Exactly how a user
"chooses" a child is up to the VRML browser. The value of whichChild
wraps around to zero. The -1 and -3 values defined for Switch are
allowed but the WWWSwitch does nothing when its children are chosen.
FILE FORMAT/DEFAULTS
WWWSwitch {
whichChild 0
}