Obviously, I'm biased !
Mitra mitra@mitra.biz, 9 October 95.
<Flame>: Please put URL's and email addresses on your papers - it makes it possible to cite them! </Flame>
VRBS is very close to our behavior scheme, I believe both were developed independantly. They are close enough that several good ideas from VRBS that we had missed have been incorporated, especially seperating out Loading a script, from Running it, event handling, and obtaining world and machine information.
DEF MyDoor WWWInline { "door.wrl" }
DEF MyAlarm WWWInline { "alarm.wrl" }
Connect {
from MyDoor.isOpen
to MyAlarm.ring
}
I cannot think of a good way to get this trivial behavior any other way.
DEF DoorPad RegionSensor {
bbox ~~~~~~ # define a volume above the doormat for sensing
Separator {
# draw a picture of the doormat here
}
}
DEF MyDoor SwingDoor {
# draw door frame here
isA Separator
fields [ SFBool READWRITE doorOpen ]
doorOpen FALSE
Switch {
whichChild USE MyDoor.doorOpen
Separator {
RotationXYZ { axis Y angle 0 }
DEF DoorBody Separator { # Draw door here }
}
Separator {
RotationXYZ { axis Y angle 1.5708 }
USE DoorBody
}
}
}
Connection {
from DoorPad.isIn # connect value of isIn field
to MyDoor.doorOpen
}
function "set SFColor diffuseColor 1 0 0"
vsSetObjDiffuse $obj $userData
I would have something like
setFieldSFColor $obj "diffuseColor" $userData
For example, (sorry I can't draw neat diagrams while I'm on the road :-), most people implementing VRML in a "Frame" or "Cluster" oriented render such as RenderWare or Reality Lab, seem to be moving towards a O-O representation which keeps a tree of Separators, with pointers to the internal data structures of RW or RL, throwing away any internal representation of things that are not Separators. This is why I get concerned about examples which change the color of a cube, since this cube won't have any single place to change its color in a RL/RW representation. A VRML file containing
Separator {
Cube { }
Cone { }
}
Will be mapped to an internal object representing the Separator, pointing to a RW Frame, and a polygon mesh inside that Frame representing both the Cube *AND* the Cone.
I'm not saying which O-O representation is correct, I think it inappropriate that VRML should enforce one or the other. However, I do believe that an O-O critique of VRML is usefull, and VRML should be written in such a way as to facilitate O-O representations of it.
Most of my comments below are to do with how *I* would implement an O-O like structure for VRML, and are not things I think should be required.
userData red
becomes
userData [ SFColor, "1 0 0" ]
Kyle suggests defing a new basic type SFFields instead of using an SFString, in which case this could be slightly simplified to.
userData [ SFColor 1 0 0 ]
While this is slightly more complex in this case, (but, you don't include code to turn red into (1 0 0) anyway), it is much nicer when it comes to multiple parameters, and doesn't require the script to have string matching algorithms to figure out parameters.
This paper has a lot of similarities to our work as well, especially to VRML+ [3], and to our networked protocol [4]