This chapter describes three types of special PROTO nodes used by the Matrix System. These types hold information about gates used to jump between different VRML worlds, events which are to be distributed to other instances of the same world and finally the SharedObjects that encapsulate VRML geometry and shared events. The definitions of these PROTOs can be found in the file matrix_protos.wrl.
Gates are nodes with tell the client to jump to another VRML world. They are triggered by an SFBool event. Their PROTO definition is the following :
PROTO Matrix_Gate [
eventIn SFBool activate
eventOut SFString isActive
field SFString target ""
]
{
Script {
eventIn SFBool activateSc IS activate
eventOut SFString isActiveSc IS isActive
field SFString targetSc IS target
directOutput TRUE
mustEvaluate TRUE
url "javascript:
function activateSc(value) {
if( value == true ) {
isActiveSc = targetSc;
}
}
"
}
}
This little script appearantly does not very much. But it is necessary because the EAI allows only the monitoring of eventOuts. The client has to use a special type of node which it can recognize at its type, because it has no access to any DEF names of nodes of a VRML file ( remember the replaceWorld call ). It is instanced as a child of the Group node holding all information vital to Matrix ( see previous chapter ).
Using this node is quite simple. If you want to use a gate make an instance of the node as a child of the central Group node. The following example is a line from the example in the last chapter.
DEF door Matrix_Gate { target "cone" }
The SFString field target tells the client which world to jump to. The value of this field is the name of a certain world as in the server configuration file matrixrc. The jump is triggered if the node receives an SFBool event via its eventIn activate. You have to provide a ROUTE from a source of SFBool events to the nodes eventIn.
In the Shout3D Client version, there is no isActive eventOut defind, because we don't need it there. To be content compatible do not use this eventOut in your own VRML files.
By adding # and an index number greater or equal to 1 to the target name, you can select to which Viewpoint in the Matrix core Group node should be bound upon the users arrival in the next world.
DEF door Matrix_Gate { target "cone#2" }
Triggering this gate would teleport the user to the world called cone and and bind the second viewpoint found in the Matrix core Group node.
The NetworkState nodes are implemented following the Living Worlds specification. For a full description of their definition see NetworkState from the Living Worlds specification.
NetworkState nodes are a set of prototyped nodes which implement the distribution of events to other instances of the VRML world. They are also build of a little script which works similar to the one used in gates. There is one net node type for each VRML event type. The following PROTO defines a NetworkSFBool node for SFBool events. Other net nodes are build similar
PROTO NetworkSFBool [
eventIn SFBool set_value
eventOut SFBool value_changed
eventIn SFBool value_fromnet
eventOut SFBool value_tonet
exposedField SFString tag ""
exposedField SFBool pilotOnly TRUE
field SFBool localCopy TRUE
exposedField SFBool echo TRUE
exposedField SFBool cont FALSE
]
{
Script {
eventIn SFBool InSc IS set_value
eventOut SFBool OutSc IS value_changed
eventIn SFBool netInSc IS value_fromnet
eventOut SFBool netOutSc IS value_tonet
field local IS localCopy
directOutput TRUE
mustEvaluate TRUE
url "javascript:
function InSc(value) {
netOutSc = value;
if( local == true )
OutSc = value;
}
function netInSc(value) {
OutSc = value;
}
"
}
}
To be accessible by the applet NetworkState nodes have to be instantiated inside of the central Group node holding all information for the Matrix System. They have two pairs of eventIn/Outs. The first labelled set_value/value_changed are connections to the VRML file. Any ROUTEs can connect to these events. The other pair is labelled value_fromnet/value_tonet. The eventOut value_tonet is monitored by the client applet and the eventIn value_fromnet is used to insert a distributed event into the VRML world. Both is realized using the EAI. The net nodes names prefix Network must not be changed because the client applet recognizes net nodes by their PROTO type name. For more information about the use of these nodes, read the next chapter.
A SharedObject PROTO encapsulates a VRML object that is loaded at runtime into the virtual environment. It can also contain NetworkState nodes like the background world to share events with the other instances. It is defined by the following PROTO definition.
PROTO SharedObject
[
exposedField SFString name ""
exposedField MFNode children []
exposedField SFVec3f position 0 0 0
exposedField SFRotation orientation 0 0 1 0
eventIn SFBool set_isVisible
eventOut SFBool isVisible_changed
exposedField MFString url []
exposedField SFBool isPilot TRUE
exposedField SFBool isAvatar FALSE
exposedField MFNode states []
]
{
Transform {
translation IS position
rotation IS orientation
children [
DEF Visible Switch {
whichChoice 0
choice [
Transform {
rotation 0 1 0 3.141592 # to compensate for Camera direction
children IS visualDefinition
}
]
}
Group {
children IS states
}
DEF Control Script {
eventIn SFBool set_isVisible IS set_isVisible
eventOut SFBool isVisible_changed IS isVisible_changed
eventOut SFInt32 choice
mustEvaluate TRUE
url "javascript:
function set_isVisible( value ){
isVisible_changed = value;
if( value == true ){
choice = 0;
} else {
choice = -1;
}
}"
}
]
}
ROUTE Control.choice TO Visible.set_whichChoice
}
This is a list of all PROTO fields and their function.
The field name gives the name of the SharedObject and is set by the client. Currently a SharedObject can be used as an Avatar, providing more capabilities than a standard BOMU Avatar. It can also be used by bots that introduce their own SharedObjects into a world to add dynamic content.
There are some limitations right now. The standard client cannot add SharedObjects. I left that out because there is no clear user interface yet to control ( like move etc. ) such an object. The other limitation is that SharedObjects can not be authored as part of the world directly. This is also left out, because I haven't found a completely nice model of managing such objects yet.