3D WORLDS
Sponsored by Kahuna's 3D Libraries

Proto Benefits

If you are running cosmo player, you will notice that I have a little vrml logo running up there. The megaman character, flying around in red cape and 3D glasses is a good example of the usefullness of PROTOS. By using him as an EXTERNPROTO (a prototype file like an inline) I can set him up to strike the appropriate pose, i.e flying in this instance.

This type of proto demands a good understanding of how the proto node works, and of course the demands that will be placed on the proto necessitate good planning. Lets start from the begining, I'll describe a protos structure, and then show an example of a usefull proto node that you can take home and use in yourown vrml worlds.

EXAMPLE: PROTO STRUCTURE

	PROTO Myproto[
#in this area you will place events and fields that can be accessed or changed

eventIn SFBool over     	#any event can be an eventIn as long as it is initialized properly
eventOut SFTime stop		#any event can be an eventOut as long as it is initialized properly
field SFFloat   fracs   	#any field can be placed here
exposedField MFNode pos		#any exposedField here must be an exposedfield in the body of the proto

#note, in order to use the above fields and events, they must match with the fields and events in the 
#protos body.
			]
{# this is the beginning of the proto body. The most important condition to remember is that the very
 # first node in the proto body determines the characteristic of the proto
Script{	#The first node in this proto is a script. So the characteristic of the proto is a script proto
		#It is not necessary to define the script if it is not being routed to within the proto
eventIn SFBool over IS over	#this IS statement sets the event to the proto event following it.
					#in this case over which is an eventIn matching that type and declared at 
					#the begining of parameters of the proto
eventOut SFTime stop IS stop  #the script will send this event out to the proto

#now it is a simple matter of sitting up the script just as you would any other script, and ending the proto with
#an end bracket like this. You do not need any routes, since this proto will be used like a script.
} # end proto
You might ask, why not just use a script, and in some instances that would be okay. But lets say, for the sake of argument, that you have 5 objects, and they all have one behavior that is the same but they all act independently. It would be a littel difficult to set up a script that will execute this behavior to each object independently and with separate events.

Let me be more specific. Lets say you have five objects running around a world that you want to stop once they encounter the viewer. You could set up five scripts to stop them, with five separate names and waiste a lot of time in the process, or you could set up one proto, and decare it for each object. Here is a proto for stopping an object:

EXAMPLE:PROTO FOR STOPPING AN OBJECT

PROTO Stopper[
eventIn SFBool stop
eventIn SFFloat fractions
eventOut SFTime stopat
eventOut SFTime startat
exposedField SFFloat cycleint
		]
{#begin proto

	Script{
		eventIn SFBool stop IS stop			
		eventIn SFFloat fractions IS fractions	
		eventOut SFTime stopat IS stopat
		eventOut SFTime startat IS startat
		field SFFloat fracs 0.0				
		field SFFloat cycleint IS cycleint		

	url "javascript:
	function fractions(val){
		fracs=val;				
					}// end function

	function stop(val,time){		
		if(val==true)			
		stopat=time;			

		if(val==false)			
		startat=time-(fracs * cycleint);
							
		stopat=0;				
					} // end function

		"#end java script
				} # end script
}#end stopper proto

#declare new instances of the Stopper proto

DEF stopper1 Stopper{cycleint 60}	#this is where it becomes real cool. Since it is a proto, and you have made cycleint an
						#exposedField, you can make its value the same as totally diffenet timers running with
						#totally differen cycleInterval values
DEF stopper2 Stopper{cycleint 30}	#a new script with its own cycleInterval value



#routes for the first object

ROUTE  yourtimer1.fraction_changed TO stopper1.fractions 
ROUTE  yourtouchsensor1.isOver TO stopper1.stop		
ROUTE  stopper1.stopat TO yourtimer1.set_stopTime		
									
ROUTE  stopper1.startat TO yourtimer1.set_startTime	
									
#routes for the second object

ROUTE  yourtimer2.fraction_changed TO stopper2.fractions 
ROUTE  yourtouchsensor2.isOver TO stopper2.stop		
ROUTE  stopper2.stopat TO yourtimer2.set_stopTime		
									
ROUTE  stopper2.startat TO yourtimer2.set_startTime	


# end vrml example
As you can easily see, the benefit from using a protoed script is that it reduces the amount of scripting you have to write and each instance can act independently from the others. For a complete description of the stopper script see this url.