https://www.web3d.org/wiki/api.php?action=feedcontributions&user=Joedw&feedformat=atomWeb3D.org - User contributions [en]2024-03-28T09:04:59ZUser contributionsMediaWiki 1.25.1https://www.web3d.org/wiki/index.php?title=About_the_X3D/VRML_ROUTE_statement&diff=1901About the X3D/VRML ROUTE statement2008-12-15T17:45:52Z<p>Joedw: typotyu[tupoyyy</p>
<hr />
<div>About the X3D/VRML ROUTE statement<br />
<br />
I have heard items like:<br />
<br />
" Tracking ROUTEs is tedious tasks and error-prone.<br />
Routes have as many detractors as fans, and more when experienced<br />
HTML Javascripters first pick up VRML, They may look at ROUTE <br />
and say,"What the heck is this?"<br />
<br />
cloud1<br />
Imagine a complex highty structured hierarchy of many nodes, <br />
each with native eventOuts, eventIns, and even inputOutputs.<br />
Imagine these nodes with nothing to tell them who they can <br />
talk and listen to.<br />
Imagine being able to configure these collections of<br />
connections in a highly dynamic way that is essentially self-documenting.<br />
Fan out folks, and also Fan in...:)<br />
Give the Route a chance to breath.<br />
They are so obvious in their necessity and simplicity.<br />
And the Nodes really need 'em.<br />
/cloud1<br />
<br />
When the experienced regex or DOM script <br />
programmer looks at VRML/X3D and says:<br />
"What the heck are those ROUTE thingees" you don't<br />
need to be a 'fan' of the Route statement to add a listener<br />
and see the need to help them understand<br />
how the Node employs the Route.<br />
<br />
True, it may be possible to create and deliver very complex X3D/VRML <br />
without using the Route statement, and in fact, that is the way<br />
'they/us' probably learned to to program, But, it may not be the<br />
programmer-friendly or even browser-friendly way to create and<br />
deliver interactive Web 3D.<br />
<br />
It is not uncommon that the first "Route-like' programming 'they/us'<br />
ever used was the equal sign and even then used that as an<br />
assignment operator, not as a Route. Then, onward and upward<br />
to building a real node and then actually adding a live field to that <br />
node and building an event listener for that field of that node so<br />
that if that field is acitivated there is a target node that has a<br />
live field that can be activated to process the event and maybe<br />
pass it on to another node. Now, to import/export raw characters<br />
and data structures between live distributed web applications.<br />
After mastering all this, including XML and ECMAScript/Java DOM<br />
and maybe ActionScript, they/us come to X3D expecting order sanity<br />
and evolution. And they/us find out that you gotta use ROUTE?<br />
<br />
So, since this may be intense, it still more than likely will be<br />
better in the long-term to just go ahead and explain some facts<br />
about the Nodes and the Routes.<br />
Besides, you can leverage this learning experience because<br />
there are several other examples where X3D Nodes and<br />
X3D Statements get along together real nice.<br />
<br />
sidebar1<br />
As another besides, at the high end, please recall that the<br />
list of ROUTE statements of a particular SAI context of the<br />
X3D scene is intended to be a live list, like others possibly<br />
encountered, like maybe in the DOM. <br />
So, for X3D, at the beginning of a potential next event cascade<br />
to figure out what needs to be done to produce the next frame,<br />
this list constitutes an instantaneous map of possible event<br />
flow needed to produce that next frame.<br />
Of course the list may be changed by events of the current cascade.<br />
This is the intent in an conformant X3D browser.and should be<br />
a tool to be employed by the efficient scene content developer.<br />
(Please see Add/Delete Route SAI interfaces.)<br />
/sidebar1<br />
<br />
Some detailed facts about the Route and its relationship to the Node.<br />
<br />
We can generally discuss a Node with field content that may be a Node,<br />
and how one node's eventOut may get connected with another node's eventIn <br />
for the purpose of information exchange using the X3D VRML Route<br />
statement.<br />
<br />
In short, to connect an eventOut with an EventIn, you write an <br />
X3D statement like:<br />
<br />
Route From DEFNode1.fieldName To DEFNode2.fieldName <br />
<br />
The exact characters used for the Route depends upon the encoding, <br />
but that is it. The important items are the "From" where you define the <br />
named node's eventOut field of interest, and the "To" where you define the <br />
target named node's field. At runtime, if the "From" field produces an output, <br />
then the event data will be received at the "To" field. <br />
<br />
So. this works universally.<br />
Basic example is if you need a sensor to activate a timer, then<br />
you rig a sensor and a timer and whatever the timer is going to <br />
control, then you connect the sensor to the timer by a<br />
Route statement that says:<br />
From Sensor.isActive To Timer.enabled<br />
and the timer can run once or continiously while the sensor<br />
is active.<br />
<br />
sidebar2<br />
* Node has fields, each with a declared data type and access type.<br />
* Event is passed between nodes using Route statement which<br />
names the From Node1.eventOut and the To Node2.eventIn.<br />
* Where necessary, supporting user code including event utilities<br />
and script is responsible for data type conversion to match the<br />
initial eventOut dataType to the target EventIn dataType.<br />
/sidebar2<br />
<br />
Now back in the early middlemeta ages, since the ascent of 'scripting'<br />
to generate live code, a machine that generated real time interactive<br />
3D using the relatively rich VRML structuring needed all the speed<br />
and convenience and memory management they could get.<br />
If there are a lot of nodes that have live fields and not all of them<br />
will be activated to produce every frame, then of course it is most<br />
simple to demand the programmer to predeclare paths of event flow,<br />
and even to predeclare paths of no event flow.<br />
In the former, this helps to optimize complex simulation because the<br />
machine can know more. Just because a Node happens to contain<br />
an eventOut, there is need to actually provide any service if there<br />
are no eventIns that care. In the latter, this may help the machine<br />
to tell you that no changes were expected for that group.<br />
<br />
So OK, that is all very nice and self contained. The Route statement<br />
has perfomed the detail of defining sources and sinks for events in a<br />
very dynamic way and human-readable way.<br />
<br />
Everything works fine when we can pass events of the same data<br />
type between different nodes.<br />
But if the data types are not the same, or need some processing,<br />
We first peruse the X3D event utilities and if we can't find something<br />
there, or the processing is too complicated, we can use a script.<br />
<br />
The Script is essentially a Sensor node which can receive and send<br />
events. Like any other node, events are passed from a<br />
SensorNode.eventOut to a ScriptNode.eventIn using a Route.<br />
Likewise, as expected, events are passed from a<br />
ScriptNode.eventOut to AnotherNode.eventIn using a Route.<br />
In the X3D standard event system the eventOuts are sent<br />
in sequence at the end of Script execution.<br />
<br />
This is just the way you want it.<br />
Known things are going to happen at known times.<br />
There is great opportunity for debug because the scene<br />
can literally document and simulate itself.<br />
<br />
But wait. Using Routes, the script can only get access to fields<br />
of other nodes. What if I want to get complete<br />
access to another node and its fields directly. Without using Route?<br />
<br />
Well, please first check your design and look for another, perhaps<br />
better integrated and structured solution that is certainly available.<br />
<br />
However, there is always using the familiar DOM-style SAI<br />
getNamedNode('AnotherNode'); <br />
interface in the body of the script.<br />
<br />
Or, you may use a Script directOut declaration.<br />
In this usage case, you can provide:<br />
inputOutput SFNode 'myNodeInTheScript' USE 'AnotherNode'<br />
in the script declaration to get a connection to AnotherNode.<br />
Now you may access the fie;ds directly using:<br />
MyNodeInTheScript.fieldName<br />
in the body of the script.<br />
<br />
In the second case, check your event timing because it may<br />
be possible that directOut event(s) may not be synchronized<br />
with the cascade that produced the current script eventIn.<br />
Although the X3D standard may be interpreted to predict<br />
standardized event cascade processing in a Script node<br />
and between other scripts and nodes involved in a cascade,<br />
this is potentially application-dependant just because it is<br />
hard to implement correctly.<br />
<br />
So it seems to me that there is actually a preferred way:<br />
* Use Routes to define event flow between all nodes, even the Script nodes.<br />
And, you may:<br />
* Use SAI getNamedNode(); to work on nodes.<br />
and/or<br />
* Use directOut to manipulate the node.<br />
or<br />
* everything at once. <br />
<br />
<pre><br />
EXAMPLE 1: Accessing Script Fields<br />
<br />
DEF SomeNode Transform { ... }<br />
<br />
Script DEF SomeScriptNode {<br />
inputOnly SFVec3f pos<br />
outputOnly SFVec3f someField<br />
url "ecmascript:<br />
function pos(value) {<br />
someField = value;<br />
}<br />
"<br />
}<br />
ROUTE SomeOtherNode.someSFVec3FField TO SomeSCriptNode.pos<br />
ROUTE SomeScriptNode.someField TO SomeNode.trans<br />
</pre><br />
<br />
Example 1 receives a routed event from SomeOtherNode.someSFVec3FField then generates an event that is routed to the Transform node SomeNode.translation. The time stamp of the input and output events is the same, the output is ready when script execution completes, and the result is evaluated as part of the current cascade. <br />
<br />
<pre><br />
EXAMPLE 2: Accessing fields of other nodes<br />
<br />
DEF SomeNode Transform { }<br />
<br />
Script DEF SomeScriptNode{<br />
inputOnly SFVec3f pos<br />
initializeOnly SFNode node USE SomeNode<br />
directOutput TRUE<br />
url "ecmascript:<br />
function pos(value) {<br />
node.translation = value;<br />
}<br />
"<br />
}<br />
ROUTE SomeOtherNode.someSFVec3FField TO SomeSCriptNode.pos<br />
</pre><br />
<br />
Example 2 receives a routed event from SomeOtherNode.someSFVec3FField then sends a set_translation event to the Transform node. Because directOutput is TRUE and the target node is included in the declaration by USE, the event is sent directly to SomeNode.translation through the direct action of the script rather than through a ROUTE. This event is processed separate from any existing or pending event cascade and shall not initiate a new cascade. <br />
<br />
<br />
Since there are so many ways to play, you will<br />
probably have to make a choice in how to do the job.<br />
When in doubt always choose the simplist solution?<br />
How you do it may not make a difference from one browser<br />
to another, or it might.<br />
Ask your favorite browser maker if their product cares.<br />
I think most applications should be better performing and easier to<br />
maintain when directOuts are refactored to use Route and to<br />
eliminate many scripts by good use of X3D event utilities.<br />
<br />
It should be reassuring that there are several ways<br />
to do it, If Luck is happening, your choice will run<br />
everywhere!<br />
<br />
<br />
Also look at some other X3D Statements like Import and Export.</div>Joedwhttps://www.web3d.org/wiki/index.php?title=About_the_X3D/VRML_ROUTE_statement&diff=1900About the X3D/VRML ROUTE statement2008-12-15T17:37:33Z<p>Joedw: typo</p>
<hr />
<div>About the X3D/VRML ROUTE statement<br />
<br />
I have heard items like:<br />
<br />
" Tracking ROUTEs is tedious tasks and error-prone.<br />
Routes have as many detractors as fans, and more when experienced<br />
HTML Javascripters first pick up VRML, They may look at ROUTE <br />
and say,"What the heck is this?"<br />
<br />
cloud1<br />
Imagine a complex highty structured hierarchy of many nodes, <br />
each with native eventOuts, eventIns, and even inputOutputs.<br />
Imagine these nodes with nothing to tell them who they can <br />
talk and listen to.<br />
Imagine being able to configure these collections of<br />
connections in a highly dynamic way that is essentially self-documenting.<br />
Fan out folks, and also Fan in...:)<br />
Give the Route a chance to breath.<br />
They are so obvious in their necessity and simplicity.<br />
And the Nodes really need 'em.<br />
/cloud1<br />
<br />
When the experienced regex or DOM script <br />
programmer looks at VRML/X3D and says:<br />
"What the heck are those ROUTE thingees" you don't<br />
need to be a 'fan' of the Route statement to add a listener<br />
and see the need to help them understand<br />
how the Node employs the Route.<br />
<br />
True, it may be possible to create and deliver very complex X3D/VRML <br />
without using the Route statement, and in fact, that is the way<br />
'they/us' probably learned to to program, But, it may not be the<br />
programmer-friendly or even browser-friendly way to create and<br />
deliver interactive Web 3D.<br />
<br />
It is not uncommon that the first "Route-like' programming 'they/us'<br />
ever used was the equal sign and even then used that as an<br />
assignment operator, not as a Route. Then, onward and upward<br />
to building a real node and then actually adding a live field to that <br />
node and building an event listener for that field of that node so<br />
that if that field is acitivated there is a target node that has a<br />
live field that can be activated to process the event and maybe<br />
pass it on to another node. Now, to import/export raw characters<br />
and data structures between live distributed web applications.<br />
After mastering all this, including XML and ECMAScript/Java DOM<br />
and maybe ActionScript, they/us come to X3D expecting order sanity<br />
and evolution. And they/us find out that you gotta use ROUTE?<br />
<br />
So, since this may be intense, it still more than likely will be<br />
better in the long-term to just go ahead an explain some facts<br />
about the Nodes and the Routes.<br />
Besides, you can leverage this learning experience because<br />
there are several other examples where X3D Nodes and<br />
X3D Statements get along together real nice.<br />
<br />
sidebar1<br />
As another besides, at the high end, please recall that the<br />
list of ROUTE statements of a particular SAI context of the<br />
X3D scene is intended to be a live list, like others possibly<br />
encountered, like maybe in the DOM. <br />
So, for X3D, at the beginning of a potential next event cascade<br />
to figure out what needs to be done to produce the next frame,<br />
this list constitutes an instantaneous map of possible event<br />
flow needed to produce that next frame.<br />
Of course the list may be changed by events of the current cascade.<br />
This is the intent in an conformant X3D browser.and should be<br />
a tool to be employed by the efficient scene content developer.<br />
(Please see Add/Delete Route SAI interfaces.)<br />
/sidebar1<br />
<br />
Some detailed facts about the Route and its relationship to the Node.<br />
<br />
We can generally discuss a Node with field content that may be a Node,<br />
and how one node's eventOut may get connected with another node's eventIn <br />
for the purpose of information exchange using the X3D VRML Route<br />
statement.<br />
<br />
In short, to connect an eventOut with an EventIn, you write an <br />
X3D statement like:<br />
<br />
Route From DEFNode1.fieldName To DEFNode2.fieldName <br />
<br />
The exact characters used for the Route depends upon the encoding, <br />
but that is it. The important items are the "From" where you define the <br />
named node's eventOut field of interest, and the "To" where you define the <br />
target named node's field. At runtime, if the "From" field produces an output, <br />
then the event data will be received at the "To" field. <br />
<br />
So. this works universally.<br />
Basic example is if you need a sensor to activate a timer, then<br />
you rig a sensor and a timer and whatever the timer is going to <br />
control, then you connect the sensor to the timer by a<br />
Route statement that says:<br />
From Sensor.isActive To Timer.enabled<br />
and the timer can run once or continiously while the sensor<br />
is active.<br />
<br />
sidebar2<br />
* Node has fields, each with a declared data type and access type.<br />
* Event is passed between nodes using Route statement which<br />
names the From Node1.eventOut and the To Node2.eventIn.<br />
* Where necessary, supporting user code including event utilities<br />
and script is responsible for data type conversion to match the<br />
initial eventOut dataType to the target EventIn dataType.<br />
/sidebar2<br />
<br />
Now back in the early middlemeta ages, since the ascent of 'scripting'<br />
to generate live code, a machine that generated real time interactive<br />
3D using the relatively rich VRML structuring needed all the speed<br />
and convenience and memory management they could get.<br />
If there are a lot of nodes that have live fields and not all of them<br />
will be activated to produce every frame, then of course it is most<br />
simple to demand the programmer to predeclare paths of event flow,<br />
and even to predeclare paths of no event flow.<br />
In the former, this helps to optimize complex simulation because the<br />
machine can know more. Just because a Node happens to contain<br />
an eventOut, there is need to actually provide any service if there<br />
are no eventIns that care. In the latter, this may help the machine<br />
to tell you that no changes were expected for that group.<br />
<br />
So OK, that is all very nice and self contained. The Route statement<br />
has perfomed the detail of defining sources and sinks for events in a<br />
very dynamic way and human-readable way.<br />
<br />
Everything works fine when we can pass events of the same data<br />
type between different nodes.<br />
But if the data types are not the same, or need some processing,<br />
We first peruse the X3D event utilities and if we can't find something<br />
there, or the processing is too complicated, we can use a script.<br />
<br />
The Script is essentially a Sensor node which can receive and send<br />
events. Like any other node, events are passed from a<br />
SensorNode.eventOut to a ScriptNode.eventIn using a Route.<br />
Likewise, as expected, events are passed from a<br />
ScriptNode.eventOut to AnotherNode.eventIn using a Route.<br />
In the X3D standard event system the eventOuts are sent<br />
in sequence at the end of Script execution.<br />
<br />
This is just the way you want it.<br />
Known things are going to happen at known times.<br />
There is great opportunity for debug because the scene<br />
can literally document and simulate itself.<br />
<br />
But wait. Using Routes, the script can only get access to fields<br />
of other nodes. What if I want to get complete<br />
access to another node and its fields directly. without using Route?<br />
<br />
Well, please first check your design and look for another, perhaps<br />
better integrated and structured solution that is certainly available.<br />
<br />
However, there is always using the familiar DOM-style SAI<br />
getNamedNode('AnotherNode'); <br />
interface in the body of the script.<br />
<br />
Or, you may use a Script directOut declaration.<br />
In this usage case, you can provide:<br />
inputOutput SFNode 'myNodeInTheScript' USE 'AnotherNode'<br />
in the script declaration to get a connection to AnotherNode.<br />
Now you may access the fie;ds directly using:<br />
MyNodeInTheScript.fieldName<br />
in the body of the script.<br />
<br />
In the second case, check your event timing because it may<br />
be possible that directOut event(s) may not be synchronized<br />
with the cascade that produced the current script eventIn.<br />
Although the X3D standard may be interpreted to predict<br />
standardized event cascade processing in a Script node<br />
and between other scripts and nodes involved in a cascade,<br />
this is potentially application-dependant just because it is<br />
hard to implement correctly.<br />
<br />
So it seems to me that there is actually a preferred way:<br />
* Use Routes to define event flow between all nodes, even the Script nodes.<br />
And, you may:<br />
* Use SAI getNamedNode(); to work on nodes.<br />
and/or<br />
* Use directOut to manipulate the node.<br />
or<br />
* everything at once. <br />
<br />
<pre><br />
EXAMPLE 1: Accessing Script Fields<br />
<br />
DEF SomeNode Transform { ... }<br />
<br />
Script DEF SomeScriptNode {<br />
inputOnly SFVec3f pos<br />
outputOnly SFVec3f someField<br />
url "ecmascript:<br />
function pos(value) {<br />
someField = value;<br />
}<br />
"<br />
}<br />
ROUTE SomeOtherNode.someSFVec3FField TO SomeSCriptNode.pos<br />
ROUTE SomeScriptNode.someField TO SomeNode.trans<br />
</pre><br />
<br />
Example 1 receives a routed event from SomeOtherNode.someSFVec3FField then generates an event that is routed to the Transform node SomeNode.translation. The time stamp of the input and output events is the same, the output is ready when script execution completes, and the result is evaluated as part of the current cascade. <br />
<br />
<pre><br />
EXAMPLE 2: Accessing fields of other nodes<br />
<br />
DEF SomeNode Transform { }<br />
<br />
Script DEF SomeScriptNode{<br />
inputOnly SFVec3f pos<br />
initializeOnly SFNode node USE SomeNode<br />
directOutput TRUE<br />
url "ecmascript:<br />
function pos(value) {<br />
node.translation = value;<br />
}<br />
"<br />
}<br />
ROUTE SomeOtherNode.someSFVec3FField TO SomeSCriptNode.pos<br />
</pre><br />
<br />
Example 2 receives a routed event from SomeOtherNode.someSFVec3FField then sends a set_translation event to the Transform node. Because directOutput is TRUE and the target node is included in the declaration by USE, the event is sent directly to SomeNode.translation through the direct action of the script rather than through a ROUTE. This event is processed separate from any existing or pending event cascade and shall not initiate a new cascade. <br />
<br />
<br />
Since there are so many ways to play, you will<br />
probably have to make a choice in how to do the job.<br />
When in doubt always choose the simplist solution?<br />
How you do it may not make a difference from one browser<br />
to another, or it might.<br />
Ask your favorite browser maker if their product cares.<br />
I think most applications should be better performing and easier to<br />
maintain when directOuts are refactored to use Route and to<br />
eliminate many scripts by good use of X3D event utilities.<br />
<br />
It should be reassuring that there are several ways<br />
to do it, If Luck is happening, your choice will run<br />
everywhere!<br />
<br />
<br />
Also look at some other X3D Statements like Import and Export.</div>Joedwhttps://www.web3d.org/wiki/index.php?title=About_the_X3D/VRML_ROUTE_statement&diff=1899About the X3D/VRML ROUTE statement2008-12-15T17:34:06Z<p>Joedw: add examples</p>
<hr />
<div>About the X3D/VRML ROUTE statement<br />
<br />
I have heard items like:<br />
<br />
" Tracking ROUTEs is tedious tasks and error-prone.<br />
Routes have as many detractors as fans, and more when experienced<br />
HTML Javascripters first pick up VRML, They may look at ROUTE <br />
and say,"What the heck is this?"<br />
<br />
cloud1<br />
Imagine a complex highty structured hierarchy of many nodes, <br />
each with native eventOuts, eventIns, and even inputOutputs.<br />
Imagine these nodes with nothing to tell them who they can <br />
talk and listen to.<br />
Imagine being able to configure these collections of<br />
connections in a highly dynamic way that is essentially self-documenting.<br />
Fan out folks, and also Fan in...:)<br />
Give the Route a chance to breath.<br />
They are so obvious in their necessity and simplicity.<br />
And the Nodes really need 'em.<br />
/cloud1<br />
<br />
When the experienced regex or DOM script <br />
programmer looks at VRML/X3D and says:<br />
"What the heck are those ROUTE thingees" you don't<br />
need to be a 'fan' of the Route statement to add a listener<br />
and see the need to help them understand<br />
how the Node employs the Route.<br />
<br />
True, it may be possible to create and deliver very complex X3D/VRML <br />
without using the Route statement, and in fact, that is the way<br />
'they/us' probably learned to to program, But, it may not be the<br />
programmer-friendly or even browser-friendly way to create and<br />
deliver interactive Web 3D.<br />
<br />
It is not uncommon that the first "Route-like' programming 'they/us'<br />
ever used was the equal sign and even then used that as an<br />
assignment operator, not as a Route. Then, onward and upward<br />
to building a real node and then actually adding a live field to that <br />
node and building an event listener for that field of that node so<br />
that if that field is acitivated there is a target node that has a<br />
live field that can be activated to process the event and maybe<br />
pass it on to another node. Now, to import/export raw characters<br />
and data structures between live distributed web applications.<br />
After mastering all this, including XML and ECMAScript/Java DOM<br />
and maybe ActionScript, they/us come to X3D expecting order sanity<br />
and evolution. And they/us find out that you gotta use ROUTE?<br />
<br />
So, since this may be intense, it still more than likely will be<br />
better in the long-term to just go ahead an explain some facts<br />
about the Nodes and the Routes.<br />
Besides, you can leverage this learning experience because<br />
there are several other examples where X3D Nodes and<br />
X3D Statements get along together real nice.<br />
<br />
sidebar1<br />
As another besides, at the high end, please recall that the<br />
list of ROUTE statements of a particular SAI context of the<br />
X3D scene is intended to be a live list, like others possibly<br />
encountered, like maybe in the DOM. <br />
So, for X3D, at the beginning of a potential next event cascade<br />
to figure out what needs to be done to produce the next frame,<br />
this list constitutes an instantaneous map of possible event<br />
flow needed to produce that next frame.<br />
Of course the list may be changed by events of the current cascade.<br />
This is the intent in an conformant X3D browser.and should be<br />
a tool to be employed by the efficient scene content developer.<br />
(Please see Add/Delete Route SAI interfaces.)<br />
/sidebar1<br />
<br />
Some detailed facts about the Route and its relationship to the Node.<br />
<br />
We can generally discuss a Node with field content that may be a Node,<br />
and how one node's eventOut may get connected with another node's eventIn <br />
for the purpose of information exchange using the X3D VRML Route<br />
statement.<br />
<br />
In short, to connect an eventOut with an EventIn, you write an <br />
X3D statement like:<br />
<br />
Route From DEFNode1.fieldName To DEFNode2.fieldName <br />
<br />
The exact characters used for the Route depends upon the encoding, <br />
but that is it. The important items are the "From" where you define the <br />
named node's eventOut field of interest, and the "To" where you define the <br />
target named node's field. At runtime, if the "From" field produces an output, <br />
then the event data will be received at the "To" field. <br />
<br />
So. this works universally.<br />
Basic example is if you need a sensor to activate a timer, then<br />
you rig a sensor and a timer and whatever the timer is going to <br />
control, then you connect the sensor to the timer by a<br />
Route statement that says:<br />
From Sensor.isActive To Timer.enabled<br />
and the timer can run once or continiously while the sensor<br />
is active.<br />
<br />
sidebar2<br />
* Node has fields, each with a declared data type and access type.<br />
* Event is passed between nodes using Route statement which<br />
names the From Node1.eventOut and the To Node2.eventIn.<br />
* Where necessary, supporting user code including event utilities<br />
and script is responsible for data type conversion to match the<br />
initial eventOut dataType to the target EventIn dataType.<br />
/sidebar2<br />
<br />
Now back in the early middlemeta ages, since the ascent of 'scripting'<br />
to generate live code, a machine that generated real time interactive<br />
3D using the relatively rich VRML structuring needed all the speed<br />
and convenience and memory management they could get.<br />
If there are a lot of nodes that have live fields and not all of them<br />
will be activated to produce every frame, then of course it is most<br />
simple to demand the programmer to predeclare paths of event flow,<br />
and even to predeclare paths of no event flow.<br />
In the former, this helps to optimize complex simulation because the<br />
machine can know more. Just because a Node happens to contain<br />
an eventOut, there is need to actually provide any service if there<br />
are no eventIns that care. In the latter, this may help the machine<br />
to tell you that no changes were expected for that group.<br />
<br />
So OK, that is all very nice and self contained. The Route statement<br />
has perfomed the detail of defining sources and sinks for events in a<br />
very dynamic way and human-readable way.<br />
<br />
Everything works fine when we can pass events of the same data<br />
type between different nodes.<br />
But if the data types are not the same, or need some processing,<br />
We first peruse the X3D event utilities and if we can't find something<br />
there, or the processing is too complicated, we can use a script.<br />
<br />
The Script is essentially a Sensor node which can receive and send<br />
events. Like any other node, events are passed from a<br />
SensorNode.eventOut to a ScriptNode.eventIn using a Route.<br />
Likewise, as expected, events are passed from a<br />
ScriptNode.eventOut to AnotherNode.eventIn using a Route.<br />
In the X3D standard event system the eventOuts are sent<br />
in sequence at the end of Script execution.<br />
<br />
This is just the way you want it.<br />
Known things are going to happen at known times.<br />
There is great opportunity for debug because the scene<br />
can literally document and simulate itself.<br />
<br />
But wait. Using Routes, the script can only get access to fields<br />
of other nodes. What if I want to get complete<br />
access to another node and its fields directly. without using Route?<br />
<br />
Well, please first check your design and look for another, perhaps<br />
better integrated and structured solution that is certainly available.<br />
<br />
However, there is always using the familiar DOM-style SAI<br />
getNamedNode('AnotherNode'); <br />
interface in the body of the script.<br />
<br />
Or, you may use a Script directOut declaration.<br />
In this usage case, you can provide:<br />
inputOutput SFNode 'myNodeInTheScript' USE 'AnotherNode'<br />
in the script declaration to get a connection to AnotherNode.<br />
Now you may access the fie;ds directly using:<br />
MyNodeInTheScript.fieldName<br />
in the body of the script.<br />
<br />
In the second case, check your event timing because it may<br />
be possible that directOut event(s) may not be synchronized<br />
with the cascade that produced the current script eventIn.<br />
Although the X3D standard may be interpreted to predict<br />
standardized event cascade processing in a Script node<br />
and between other scripts and nodes involved in a cascade,<br />
this is potentially application-dependant just because it is<br />
hard to implement correctly.<br />
<br />
So it seems to me that there is actually a preferred way:<br />
* Use Routes to define event flow between all nodes, even the Script nodes.<br />
And, you may:<br />
* Use SAI getNamedNode(); to work on nodes.<br />
and/or<br />
* Use directOut to manipulate the node.<br />
or<br />
* everything at once. <br />
<br />
<pre><br />
EXAMPLE 1: Accessing Script FIelds<br />
<br />
DEF SomeNode Transform { ... }<br />
<br />
Script DEF SomeScriptNode {<br />
inputOnly SFVec3f pos<br />
outputOnly SFVec3f someField<br />
url "ecmascript:<br />
function pos(value) {<br />
someField = value;<br />
}<br />
"<br />
}<br />
ROUTE SomeOtherNode.someSFVec3FField TO SomeSCriptNode.pos<br />
ROUTE SomeScriptNode.someField TO SomeNode.trans<br />
</pre><br />
<br />
Example 1 receives a routed event from SomeOtherNode.someSFVec3FField then generates an event that is routed to the Transform node SomeNode.translation. The time stamp of the input and output events is the same, the output is ready when script execution completes, and the result is evaluated as part of the current cascade. <br />
<br />
<pre><br />
EXAMPLE 2: Accessing fields of other nodes<br />
<br />
DEF SomeNode Transform { }<br />
<br />
Script DEF SomeScriptNode{<br />
inputOnly SFVec3f pos<br />
initializeOnly SFNode node USE SomeNode<br />
directOutput TRUE<br />
url "ecmascript:<br />
function pos(value) {<br />
node.translation = value;<br />
}<br />
"<br />
}<br />
ROUTE SomeOtherNode.someSFVec3FField TO SomeSCriptNode.pos<br />
</pre><br />
<br />
Example 2 receives a routed event from SomeOtherNode.someSFVec3FField then sends a set_translation event to the Transform node. Because directOutput is TRUE and the target node is included in the declaration by USE, the event is sent directly to SomeNode.translation through the direct action of the script rather than through a ROUTE. This event is processed separate from any existing or pending event cascade and shall not initiate a new cascade. <br />
<br />
<br />
Since there are so many ways to play, you will<br />
probably have to make a choice in how to do the job.<br />
When in doubt always choose the simplist solution?<br />
How you do it may not make a difference from one browser<br />
to another, or it might.<br />
Ask your favorite browser maker if their product cares.<br />
I think most applications should be better performing and easier to<br />
maintain when directOuts are refactored to use Route and to<br />
eliminate many scripts by good use of X3D event utilities.<br />
<br />
It should be reassuring that there are several ways<br />
to do it, If Luck is happening, your choice will run<br />
everywhere!<br />
<br />
<br />
Also look at some other X3D Statements like Import and Export.</div>Joedwhttps://www.web3d.org/wiki/index.php?title=General_X3D_Navigation_Behaviors&diff=1682General X3D Navigation Behaviors2008-07-21T05:44:35Z<p>Joedw: </p>
<hr />
<div>General X3D Navigation Behaviors<br />
<br />
X3D Navigation - Planar and Free<br />
<br />
'''Hello 3D Navigation''' <br />
<br />
This is just intended to be a basis for a recommendation to work on the ISO Standard X3D Navigation standards. As we can easily see, VRML/X3D standardized navigation deals with some very primary yet weakly specified types and utilities. Our X3D helped some with closer definitions and a defined utility LookAt. The current standard needs upgrade because it needs strengthening. Some features that are now proven simple and consistent to describe and implement are missing.<br />
<br />
When navigation was originally defined there was hesitation to specify anything too closely. Even though quite advanced navigation styles and techniques for using the available controls of mouse and keyboard were demonstrated, only general and mostly optional recommendations are made. It remains very brave for then but for example Walk type navigation seems not to absolutely require realistic terrain following and collison. This is a signal that not all paricipating players could do all those things at some time in the past, so the standard was weak. <br />
<br />
In general, we want to require names for the minimum number of types needed to navigate in 3D space using the VRML and current X3D standard 'single' input system where only one navigation type can be active at any time. Maybe too bad this is so basic but that is an interface limitation X3D recognizes, you may only be able to do one thing at a time. These basic ones, Walk, Fly, Pan, Roll, and Slide will be sufficient for many needed navigation functionalities. <br />
<br />
Next, we can consider some basic automated navigation utilities, Examine and LookAt. Both are needed to take the pain out of mouse-like navigation in the scene. <br />
<br />
Finally, with that basis X3D can approach standardization of a terrain following 'game' type navigation. This Play navigation adds capabilities because two inputs are used to define movement rather than one. For example, it is common to control the gaze and thus the general direction of motion along the terrain using the mouse, then control the actual forward, slideleft, back, slideright movements by pressing keys. This is clearly common and may work to enhance other aspects of interactive web3D.<br />
<br />
So, VRML/X3D browser vendors now can all do pretty much the same navigation effects if they want to and have generally all tried to do something innovative and generally offering much more than the standard actually requires. Only problem? Not consistent. <br />
<br />
First, there is only so much you can do with the current setup. It is totally composed to operate using a pointing system that operates on relative x,y movement only. I mean that whatever 'navigation' you pick, the movement can only describe changing the viewer position or direction with regard to the single current navigation plane. <br />
<br />
As in a movement like typical VRML/X3D 'Fly' using a normal mouse interface, it can work where +y is go forward and +x is go right, there is no way to go "up" or "down" without changing what I called the 'current navigation plane'. In X3D/VRML with the typical setup, to change the navigaton plane you switch from Fly to a mode like Pan or Roll or Examine that will allow you to set up that current plane so you can aim at where you want to go. Then switch back to Fly and go forward. <br />
<br />
'''First the fundamental movements:''' <br />
<br />
'''Walk'''<br />
<br />
- Follow terrain with collision and apparent gravity effect. <br />
<br />
- Speed 0 allows rotation of the view around the horizon. <br />
<br />
- on current surface. relative +-y controls forward and reverse along path of gaze, relative +-x controls gaze along the current navigation plane.<br />
<br />
'''Fly'''<br />
<br />
- Follow current view x,z surface with collision no gravity effect (except if applied by physics) <br />
<br />
- Same as walk, forward, back, rightyaw, leftyaw on current x,z plane. <br />
<br />
- Speed 0 allows rotation of the view in any direction.<br />
<br />
- Yaw view direction changes must not produce an effect upon the pitch or roll attitude. <br />
<br />
Specifically, the gaze direction is the movement direction. <br />
The gaze direction is limited to sweeping the current x,z navigation plane. <br />
<br />
'''More Necessary 3D Navigation'''<br />
<br />
Next, some more for what is actually needed to support basic mouse-driven x,y navigation. <br />
<br />
'''Pan'''<br />
<br />
- Free look view direction with view position fixed no collision <br />
(Fly or Walk with Speed 0<br />
<br />
- look around in any direction +y is up, +x is turn right <br />
<br />
- Changes current view 'pitch' and 'yaw' to change x,z navigation plane. <br />
<br />
_ Does not induce a 'Roll' rotation.<br />
<br />
'''Roll'''<br />
<br />
- Control viewer orientation around view z with collision <br />
<br />
- Rotate around viewer z to change current view x,z navigation plane.<br />
+x to roll viewer CW.<br />
<br />
- Does not induce 'pitch' or 'yaw'.<br />
<br />
'''Slide''' <br />
<br />
- move position relative x,z or x,y with collision <br />
<br />
- move right and left (and up, down if Fly) on current view x,y plane to displace current x,z navigation plane. <br />
<br />
With these we can actually move around on a surface and even change orientation of the navigation surface to simulate flying, if only in a clunky way. If done right, then you could Pan to pick your relative z direction and pitch, Roll some for orientation, and Fly to go forward and set your relative x,z heading, and maybe Slide to change relative x,z and x,y position. Since VRML/X3D 'fly' with a mouse should allow only yaw turns, you need to switch back and forth between these various navigation types to set your desired pitch, roll, yaw, position, and direction. <br />
<br />
So, these five Walk, Fly, Pan, Slide, Roll, are the basic movements for mouse-type surface/point movements in this type of one-input navigation control scheme. Every truely X3D Web3D browser should do all of these and call the same the same. <br />
<br />
As well as a typical looking context menu list, uniform keyboard keys must allow easy ways to select/change any navigation type. <br />
<br />
In all cases a uniform way to allow select 'mousedown' for navigation, both for movement and for LookAt, without activating underlying touchsensor/anchor nodes must be provided. <br />
<br />
The arrow keys must be defined consistently with expected mouse operation in the current mode.<br />
<br />
Universally, Shift for faster movement. <br />
<br />
It is most fun to be able to hold the mousedown while switching modes without halting and manually restarting the movement. <br />
<br />
'''Navigation Utilities'''<br />
<br />
Navigation utilities are added to ease the pains of mouse-only navigation. <br />
<br />
'''Examine'''<br />
<br />
- Change the view to orbit an object of interest with respect to a defined centerofrotation with collision.<br />
<br />
- active pointer motion causes the position and orientation of the view to move with constant radius around the centerofrotation while maintaining the gaze aimed at the centerofrotation. <br />
<br />
'''LookAt'''<br />
<br />
- Allows the user to point at and select an object of interest. <br />
<br />
- Moves the viewpoint closer to the object, sets a new centerofrotation based on the selection, and aims the gaze upon the new centerofrotation.<br />
<br />
The current navigation plane must not change its 'up' during LookAt. That is, only pitch and yaw are changed to move the view, not roll. <br />
The navigation type must not change by selecting LookAt. <br />
All sensors active during movement. <br />
<br />
Uniform method of selecting and activating the LookAt operation without changing the navigation type is required. <br />
<br />
Effective method of switching between Walk, Fly, Slide, Pan, Roll, Examine is required. <br />
<br />
Note: The spec statement with navinfo "... if content specifies both "LOOKAT" and "EXAMINE" types, any "LOOKAT" operations shall change the center of rotation for subsequent "EXAMINE" operations." is wrong, because there are no conditions. Selecting an object for LookAt should always reset the current view centerofrotation based on the latest selection.)<br />
<br />
That about does it for this kind of primary mouse-driven navigation. One opportunity? Is it still too soon to think that a standardized user would have a pointing device with at least three ways to make it active, plus at least one wheel? <br />
<br />
'''Stand Together'''<br />
<br />
I pause here only because these navigation types and utilies capture what is already proven in VRML and X3D content, cumulatively by many different browser implementations. Here the X3D browsers must stand together. There must be standard, simple, non-optional but user-settable controls for these simple yet necessary navigation features. Further, these form the basis for author control of more complex tour-type user assisted navigation. <br />
<br />
'''Now for some Actual 3D Navigation'''<br />
<br />
As a next step, realistic navigation requires that more than one of these navigation modes are active simultaneously. In a venacular, this means at least two navigation vectors are active: gaze and movement. The direction of movement is derived from the gaze direction. <br />
<br />
One great success for terrain navigation is the idea of using one set of keys for forward, back, slideleft,slideright movement and another set and/or the the Mouse for gaze and movement direction. The effective mouse pointer position provides the gaze direction, along with x and z reference for the movement directions. When you select forward, you go where you are looking, and you can slide right and left relative to your gaze. <br />
<br />
'''Play'''<br />
<br />
- Free gaze direction by mouse pointer, like Pan, +y moves gaze up and +x moves gaze right.<br />
<br />
- WASD keys provide direction control for movements forward, slideleft, back, and slideright. <br />
<br />
At this time, this type of interface is well enough proven to standardize as a Play navigation mode. Does any browser maker have a problem implementing gaze tracking the mouse? Any Problems using WASD keyboard for forward, slideright, back, slideleft? <br />
<br />
Since this mode requires several controls just for movement and because several more features may be added to accomplish other play iteractions it is unclear what to recommend concerning other shortcut controls of the X3D browser and supporting platform. <br />
This needs a write up. <br />
<br />
'''What About Free-Flight?'''<br />
<br />
X3D Standardization of free flight navigation is not necessary at this time. To change direction, we use instant combinations of pitch, roll, and yaw plus forward, back, slideleft, slideright movements. For now, this is all best done by connection of an appropriate controller. Some flight controls using multiple sets of keys and mouse are seen but are not satisfactory and thus not necessary to consider. Maybe you can steer free flight with only mouse and roll. who cares, gimme the joystick and keyboard and it is done. <br />
<br />
'''Conclusion'''<br />
<br />
Navigation is complex. Every application has differing but common requirements. When movement is required, the author must be able to offer satisfactory solutions. The above analysis and comments comes from the best I have seen and needed. These six basic movements here named Walk, Fly, Pan, Roll, Slide, and Play plus the two utilies LookAt and Examine will provide the basic tools needed to provide performant navigation and an outline for updating the X3D standard.<br />
<br />
there is a partial attempt in the x3d standard to help define some interactivity, at<br />
<br />
http://www.web3d.org/x3d/specifications/ISO-IEC-FDIS-19775-1.2-X3D-AbstractSpecification/Part01/behaviours.html</div>Joedwhttps://www.web3d.org/wiki/index.php?title=General_X3D_Navigation_Behaviors&diff=1681General X3D Navigation Behaviors2008-07-21T04:57:38Z<p>Joedw: </p>
<hr />
<div>General X3D Navigation Behaviors<br />
<br />
X3D Navigation - Planar and Free<br />
<br />
'''Hello 3D Navigation''' <br />
<br />
This is just intended to be a basis for a recommendation to work on the ISO Standard X3D Navigation standards. As we can easily see, VRML/X3D standardized navigation deals with some very primary yet weakly specified types and utilities. Our X3D helped some with closer definitions and a defined utility LookAt. The current standard needs upgrade because it needs strengthening. Some features that are now proven simple and consistent to describe and implement are missing.<br />
<br />
When navigation was originally defined there was hesitation to specify anything too closely. Even though quite advanced navigation styles and techniques for using the available controls of mouse and keyboard were demonstrated, only general and mostly optional recommendations are made. It remains very brave for then but for example Walk type navigation seems not to absolutely require realistic terrain following and collison. This is a signal that not all paricipating players could do all those things at some time in the past, so the standard was weak. <br />
<br />
In general, we want to require names for the minimum number of types needed to navigate in 3D space using the VRML and current X3D standard 'single' input system where only one navigation type can be active at any time. Maybe too bad this is so basic but that is an interface limitation X3D recognizes, you may only be able to do one thing at a time. These basic ones, Walk, Fly, Pan, Roll, and Slide will be sufficient for many needed navigation functionalities. <br />
<br />
Next, we can consider some basic automated navigation utilities, Examine and LookAt. Both are needed to take the pain out of mouse-like navigation in the scene. <br />
<br />
Finally, with that basis X3D can approach standardization of a terrain following 'game' type navigation. This Play navigation adds capabilities because two inputs are used to define movement rather than one. For example, it is common to control the gaze and thus the general direction of motion along the terrain using the mouse, then control the actual forward, slideleft, back, slideright movements by pressing keys. This is clearly common and may work to enhance other aspects of interactive web3D.<br />
<br />
So, VRML/X3D browser vendors now can all do pretty much the same navigation effects if they want to and have generally all tried to do something innovative and generally offering much more than the standard actually requires. Only problem? Not consistent. <br />
<br />
First, there is only so much you can do with the current setup. It is totally composed to operate using a pointing system that operates on relative x,y movement only. I mean that whatever 'navigation' you pick, the movement can only describe changing the viewer position or direction with regard to the single current navigation plane. <br />
<br />
As in a movement like typical VRML/X3D 'Fly' using a normal mouse interface, it can work where +y is go forward and +x is go right, there is no way to go "up" or "down" without changing what I called the 'current navigation plane'. In X3D/VRML with the typical setup, to change the navigaton plane you switch from Fly to a mode like Pan or Roll or Examine that will allow you to set up that current plane so you can aim at where you want to go. Then switch back to Fly and go forward. <br />
<br />
'''First the fundamental movements:''' <br />
<br />
'''Walk'''<br />
<br />
- Follow terrain with collision and apparent gravity effect. <br />
<br />
- Speed 0 allows rotation of the view around the horizon. <br />
<br />
- on current surface. relative +-y controls forward and reverse along path of gaze, relative +-x controls gaze along the current navigation plane.<br />
<br />
'''Fly'''<br />
<br />
- Follow current view x,z surface with collision no gravity effect (except if applied by physics) <br />
<br />
- Same as walk, forward, back, rightyaw, leftyaw on current x,z plane. <br />
<br />
- Speed 0 allows rotation of the view in any direction.<br />
<br />
- Yaw view direction changes must not produce an effect upon the pitch or roll attitude. <br />
<br />
Specifically, the gaze direction is the movement direction. <br />
The gaze direction is limited to sweeping the current x,z navigation plane. <br />
<br />
'''More Necessary 3D Navigation'''<br />
<br />
Next, some more for what is actually needed to support basic mouse-driven x,y navigation. <br />
<br />
'''Pan'''<br />
<br />
- Free look view direction with view position fixed no collision <br />
(Fly or Walk with Speed 0<br />
<br />
- look around in any direction +y is up, +x is turn right <br />
<br />
- Changes current view 'pitch' and 'yaw' to change x,z navigation plane. <br />
<br />
_ Does not induce a 'Roll' rotation.<br />
<br />
'''Roll'''<br />
<br />
- Control viewer orientation around view z with collision <br />
<br />
- Rotate around viewer z to change current view x,z navigation plane.<br />
+x to roll viewer CW.<br />
<br />
- Does not induce 'pitch' or 'yaw'.<br />
<br />
'''Slide''' <br />
<br />
- move position relative x,z or x,y with collision <br />
<br />
- move right and left (and up, down if Fly) on current view x,y plane to displace current x,z navigation plane. <br />
<br />
With these we can actually move around on a surface and even change orientation of the navigation surface to simulate flying, if only in a clunky way. If done right, then you could Pan to pick your relative z direction and pitch, Roll some for orientation, and Fly to go forward and set your relative x,z heading, and maybe Slide to change relative x,z and x,y position. Since VRML/X3D 'fly' with a mouse should allow only yaw turns, you need to switch back and forth between these various navigation types to set your desired pitch, roll, yaw, position, and direction. <br />
<br />
So, these five Walk, Fly, Pan, Slide, Roll, are the basic movements for mouse-type surface/point movements in this type of one-input navigation control scheme. Every truely X3D Web3D browser should do all of these and call the same the same. <br />
<br />
As well as a typical looking context menu list, uniform keyboard keys must allow easy ways to select/change any navigation type. <br />
<br />
In all cases a uniform way to allow select 'mousedown' for navigation, both for movement and for LookAt, without activating underlying touchsensor/anchor nodes must be provided. <br />
<br />
The arrow keys must be defined consistently with expected mouse operation in the current mode.<br />
<br />
Universally, Shift for faster movement. <br />
<br />
It is most fun to be able to hold the mousedown while switching modes without halting and manually restarting the movement. <br />
<br />
'''Navigation Utilities'''<br />
<br />
Navigation utilities are added to ease the pains of mouse-only navigation. <br />
<br />
'''Examine'''<br />
<br />
- Change the view to orbit an object of interest with respect to a defined centerofrotation with collision.<br />
<br />
- active pointer motion causes the position and orientation of the view to move with constant radius around the centerofrotation while maintaining the gaze aimed at the centerofrotation. <br />
<br />
'''LookAt'''<br />
<br />
- Allows the user to point at and select an object of interest. <br />
<br />
- Moves the viewpoint closer to the object, sets a new centerofrotation based on the selection, and aims the gaze upon the new centerofrotation.<br />
<br />
The current navigation plane must not change its 'up' during LookAt. That is, only pitch and yaw are changed to move the view, not roll. <br />
The navigation type must not change by selecting LookAt. <br />
All sensors active during movement. <br />
<br />
Uniform method of selecting and activating the LookAt operation without changing the navigation type is required. <br />
<br />
Effective method of switching between Walk, Fly, Slide, Pan, Roll, Examine is required. <br />
<br />
Note: The spec statement with navinfo "... if content specifies both "LOOKAT" and "EXAMINE" types, any "LOOKAT" operations shall change the center of rotation for subsequent "EXAMINE" operations." is wrong, because there are no conditions. Selecting an object for LookAt should always reset the current view centerofrotation based on the latest selection.)<br />
<br />
That about does it for this kind of primary mouse-driven navigation. One opportunity? Is it still too soon to think that a standardized user would have a pointing device with at least three ways to make it active, plus at least one wheel? <br />
<br />
'''Stand Together'''<br />
<br />
I pause here only because these navigation types and utilies capture what is already proven in VRML and X3D content, cumulatively by many different browser implementations. Here the X3D browsers must stand together. There must be standard, simple, non-optional but user-settable controls for these simple yet necessary navigation features. Further, these form the basis for author control of more complex tour-type user assisted navigation. <br />
<br />
'''Now for some Actual 3D Navigation'''<br />
<br />
As a next step, realistic navigation requires that more than one of these navigation modes are active simultaneously. In a venacular, this means at least two navigation vectors are active: gaze and movement. The direction of movement is derived from the gaze direction. <br />
<br />
One great success for terrain navigation is the idea of using one set of keys for forward, back, slideleft,slideright movement and another set and/or the the Mouse for gaze and movement direction. The effective mouse pointer position provides the gaze direction, along with x and z reference for the movement directions. When you select forward, you go where you are looking, and you can slide right and left relative to your gaze. <br />
<br />
'''Play'''<br />
<br />
- Free gaze direction by mouse pointer, like Pan, +y moves gaze up and +x moves gaze right.<br />
<br />
- WASD keys provide direction control for movements forward, slideleft, back, and slideright. <br />
<br />
At this time, this type of interface is well enough proven to standardize as a Play navigation mode. Does any browser maker have a problem implementing gaze tracking the mouse? Any Problems using WASD keyboard for forward, slideright, back, slideleft? <br />
<br />
Since this mode requires several controls just for movement and because several more features may be added to accomplish other play iteractions it is unclear what to recommend concerning other shortcut controls of the X3D browser and supporting platform. <br />
This needs a write up. <br />
<br />
'''What About Free-Flight?'''<br />
<br />
X3D Standardization of free flight navigation is not necessary at this time. To change direction, we use instant combinations of pitch, roll, and yaw plus forward, back, slideleft, slideright movements. For now, this is all best done by connection of an appropriate controller. Some flight controls using multiple sets of keys and mouse are seen but are not satisfactory and thus not necessary to consider. Maybe you can steer free flight with only mouse and roll. who cares, gimme the joystick and keyboard and it is done. <br />
<br />
'''Conclusion'''<br />
<br />
Navigation is complex. Every application has differing but common requirements. When movement is required, the author must be able to offer satisfactory solutions. The above analysis and comments comes from the best I have seen and needed. These six basic movements here named Walk, Fly, Pan, Roll, Slide, and Play plus the two utilies LookAt and Examine will provide the basic tools needed to provide performant navigation and an outline for updating the X3D standard.<br />
<br />
there is a partial attempt in the x3d standard to help define some interactivity, at<br />
<br />
http://www.web3d.org/x3d/specifications/ISO-IEC-19775-X3DAbstractSpecification_Revision1_to_Part1/Part01/behaviours.html</div>Joedwhttps://www.web3d.org/wiki/index.php?title=Talk:Node_Reference&diff=1630Talk:Node Reference2007-08-03T18:30:55Z<p>Joedw: </p>
<hr />
<div>20070322<br />
i'd like to see this updated to the latest submitted Rev1 or 19775-1 <br />
I think I have a good llst.<br />
joedwil@earthink.net - done, at least the nodes are listed</div>Joedwhttps://www.web3d.org/wiki/index.php?title=About_the_X3D/VRML_ROUTE_statement&diff=1629About the X3D/VRML ROUTE statement2007-07-12T02:20:30Z<p>Joedw: </p>
<hr />
<div>About the X3D/VRML ROUTE statement<br />
<br />
I have heard items like:<br />
<br />
" Tracking ROUTEs is tedious tasks and error-prone.<br />
Routes have as many detractors as fans, and more when experienced<br />
HTML Javascripters first pick up VRML, They may look at ROUTE <br />
and say,"What the heck is this?"<br />
<br />
cloud1<br />
Imagine a complex highty structured hierarchy of many nodes, <br />
each with native eventOuts, eventIns, and even inputOutputs.<br />
Imagine these nodes with nothing to tell them who they can <br />
talk and listen to.<br />
Imagine being able to configure these collections of<br />
connections in a highly dynamic way that is essentially self-documenting.<br />
Fan out folks, and also Fan in...:)<br />
Give the Route a chance to breath.<br />
They are so obvious in their necessity and simplicity.<br />
And the Nodes really need 'em.<br />
/cloud1<br />
<br />
When the experienced regex or DOM script <br />
programmer looks at VRML/X3D and says:<br />
"What the heck are those ROUTE thingees" you don't<br />
need to be a 'fan' of the Route statement to add a listener<br />
and see the need to help them understand<br />
how the Node employs the Route.<br />
<br />
True, it may be possible to create and deliver very complex X3D/VRML <br />
without using the Route statement, and in fact, that is the way<br />
'they/us' probably learned to to program, But, it may not be the<br />
programmer-friendly or even browser-friendly way to create and<br />
deliver interactive Web 3D.<br />
<br />
It is not uncommon that the first "Route-like' programming 'they/us'<br />
ever used was the equal sign and even then used that as an<br />
assignment operator, not as a Route. Then, onward and upward<br />
to building a real node and then actually adding a live field to that <br />
node and building an event listener for that field of that node so<br />
that if that field is acitivated there is a target node that has a<br />
live field that can be activated to process the event and maybe<br />
pass it on to another node. Now, to import/export raw characters<br />
and data structures between live distributed web applications.<br />
After mastering all this, including XML and ECMAScript/Java DOM<br />
and maybe ActionScript, they/us come to X3D expecting order sanity<br />
and evolution. And they/us find out that you gotta use ROUTE?<br />
<br />
So, since this may be intense, it still more than likely will be<br />
better in the long-term to just go ahead an explain some facts<br />
about the Nodes and the Routes.<br />
Besides, you can leverage this learning experience because<br />
there are several other examples where X3D Nodes and<br />
X3D Statements get along together real nice.<br />
<br />
sidebar1<br />
As another besides, at the high end, please recall that the<br />
list of ROUTE statements of a particular SAI context of the<br />
X3D scene is intended to be a live list, like others possibly<br />
encountered, like maybe in the DOM. <br />
So, for X3D, at the beginning of a potential next event cascade<br />
to figure out what needs to be done to produce the next frame,<br />
this list constitutes an instantaneous map of possible event<br />
flow needed to produce that next frame.<br />
Of course the list may be changed by events of the current cascade.<br />
This is the intent in an conformant X3D browser.and should be<br />
a tool to be employed by the efficient scene content developer.<br />
(Please see Add/Delete Route SAI interfaces.)<br />
/sidebar1<br />
<br />
Some detailed facts about the Route and its relationship to the Node.<br />
<br />
We can generally discuss a Node with field content that may be a Node,<br />
and how one node's eventOut may get connected with another node's eventIn <br />
for the purpose of information exchange using the X3D VRML Route<br />
statement.<br />
<br />
In short, to connect an eventOut with an EventIn, you write an <br />
X3D statement like:<br />
<br />
Route From DEFNode1.fieldName To DEFNode2.fieldName <br />
<br />
The exact characters used for the Route depends upon the encoding, <br />
but that is it. The important items are the "From" where you define the <br />
named node's eventOut field of interest, and the "To" where you define the <br />
target named node's field. At runtime, if the "From" field produces an output, <br />
then the event data will be received at the "To" field. <br />
<br />
So. this works universally.<br />
Basic example is if you need a sensor to activate a timer, then<br />
you rig a sensor and a timer and whatever the timer is going to <br />
control, then you connect the sensor to the timer by a<br />
Route statement that says:<br />
From Sensor.isActive To Timer.enabled<br />
and the timer can run once or continiously while the sensor<br />
is active.<br />
<br />
sidebar2<br />
* Node has fields, each with a declared data type and access type.<br />
* Event is passed between nodes using Route statement which<br />
names the From Node1.eventOut and the To Node2.eventIn.<br />
* Where necessary, supporting user code including event utilities<br />
and script is responsible for data type conversion to match the<br />
initial eventOut dataType to the target EventIn dataType.<br />
/sidebar2<br />
<br />
Now back in the early middlemeta ages, since the ascent of 'scripting'<br />
to generate live code, a machine that generated real time interactive<br />
3D using the relatively rich VRML structuring needed all the speed<br />
and convenience and memory management they could get.<br />
If there are a lot of nodes that have live fields and not all of them<br />
will be activated to produce every frame, then of course it is most<br />
simple to demand the programmer to predeclare paths of event flow,<br />
and even to predeclare paths of no event flow.<br />
In the former, this helps to optimize complex simulation because the<br />
machine can know more. Just because a Node happens to contain<br />
an eventOut, there is need to actually provide any service if there<br />
are no eventIns that care. In the latter, this may help the machine<br />
to tell you that no changes were expected for that group.<br />
<br />
So OK, that is all very nice and self contained. The Route statement<br />
has perfomed the detail of defining sources and sinks for events in a<br />
very dynamic way and human-readable way.<br />
<br />
Everything works fine when we can pass events of the same data<br />
type between different nodes.<br />
But if the data types are not the same, or need some processing,<br />
We first peruse the X3D event utilities and if we can't find something<br />
there, or the processing is too complicated, we can use a script.<br />
<br />
The Script is essentially a Sensor node which can receive and send<br />
events. Like any other node, events are passed from a<br />
SensorNode.eventOut to a ScriptNode.eventIn using a Route.<br />
Likewise, as expected, events are passed from a<br />
ScriptNode.eventOut to AnotherNode.eventIn using a Route.<br />
In the X3D standard event system the eventOuts are sent<br />
in sequence at the end of Script execution.<br />
<br />
This is just the way you want it.<br />
Known things are going to happen at known times.<br />
There is great opportunity for debug because the scene<br />
can literally document and simulate itself.<br />
<br />
But wait. Using Routes, the script can only get access to fields<br />
of other nodes. What if I want to get complete<br />
access to another node and its fields directly. without using Route?<br />
<br />
Well, please first check your design and look for another, perhaps<br />
better integrated and structured solution that is certainly available.<br />
<br />
However, there is always using the familiar DOM-style SAI<br />
getNamedNode('AnotherNode'); <br />
interface in the body of the script.<br />
<br />
Or, you may use a Script directOut declaration.<br />
In this usage case, you can provide:<br />
inputOutput SFNode 'myNodeInTheScript' USE 'AnotherNode'<br />
in the script declaration to get a connection to AnotherNode.<br />
Now you may access the fie;ds directly using:<br />
MyNodeInTheScript.fieldName<br />
in the body of the script.<br />
<br />
In the second case, check your event timing because it may<br />
be possible that directOut event(s) may not be synchronized<br />
with the cascade that produced the current script eventIn.<br />
Although the X3D standard may be interpreted to predict<br />
standardized event cascade processing in a Script node<br />
and between other scripts and nodes involved in a cascade,<br />
this is potentially application-dependant just because it is<br />
hard to implement correctly.<br />
<br />
So it seems to me that there is actually a preferred way:<br />
* Use Routes to define event flow between all nodes, even the Script nodes.<br />
And, you may:<br />
* Use SAI getNamedNode(); to work on nodes.<br />
and/or<br />
* Use directOut to manipulate the node.<br />
or<br />
* everything at once.<br />
<br />
Since there are so many ways to play, you will<br />
probably have to make a choice in how to do the job.<br />
When in doubt always choose the simplist solution?<br />
How you do it may not make a difference from one browser<br />
to another, or it might.<br />
Ask your favorite browser maker if their product cares.<br />
I think most applications should be better performing and easier to<br />
maintain when directOuts are refactored to use Route and to<br />
eliminate many scripts by good use of X3D event utilities.<br />
<br />
It should be reassuring that there are several ways<br />
to do it, If Luck is happening, your choice will run<br />
everywhere!<br />
<br />
<br />
Also look at some other X3D Statements like Import and Export.</div>Joedwhttps://www.web3d.org/wiki/index.php?title=SAI_Tutorial&diff=1488SAI Tutorial2006-02-06T18:21:51Z<p>Joedw: Link to X3D SAI using Java by Xj3D.</p>
<hr />
<div>Link to X3D Scene Access Interface programming using Java.<br />
<br />
http://www.xj3d.org/tutorials/general_sai.html</div>Joedwhttps://www.web3d.org/wiki/index.php?title=SAI_Tutorial&diff=1487SAI Tutorial2006-02-06T18:20:28Z<p>Joedw: </p>
<hr />
<div>Link to Scene Access Interface programming using Java.<br />
<br />
http://www.xj3d.org/tutorials/general_sai.html</div>Joedwhttps://www.web3d.org/wiki/index.php?title=How-To_Guides&diff=1486How-To Guides2006-02-06T18:16:36Z<p>Joedw: </p>
<hr />
<div>== How-To Guides ==<br />
<br />
* [[ConvertVRML97 To X3D]]<br />
<br />
<br />
* [[SAI Tutorial]]</div>Joedwhttps://www.web3d.org/wiki/index.php?title=SAI_Tutorial&diff=1485SAI Tutorial2006-02-06T18:14:45Z<p>Joedw: link to SAI Tutorial</p>
<hr />
<div><br />
<br />
http://www.xj3d.org/tutorials/general_sai.html</div>Joedwhttps://www.web3d.org/wiki/index.php?title=Node_Reference&diff=1342Node Reference2006-01-25T04:10:01Z<p>Joedw: </p>
<hr />
<div><h2>List of Nodes</h2><br />
<pre><br />
From <br />
ISO-IEC-19776-1-FDIS-X3DEncodings-XML/Part01/EncodingOfNodes.html<br />
<br />
Anchor <br />
Appearance <br />
Arc2D <br />
ArcClose2D <br />
AudioClip <br />
Background <br />
Billboard <br />
BooleanFilter <br />
BooleanSequencer <br />
BooleanToggle <br />
BooleanTrigger <br />
Box <br />
CADAssembly <br />
CADFace <br />
CADLayer <br />
CADPart <br />
Circle2D <br />
Collision <br />
Color <br />
ColorInterpolator <br />
ColorRGBA <br />
Composed3DTexture <br />
ComposedCubeMapTexture <br />
ComposedShader <br />
Cone <br />
Contour2D <br />
ContourPolyline2D <br />
Coordinate <br />
CoordinateDouble <br />
CoordinateInterpolator <br />
CoordinateInterpolator2D <br />
Cylinder <br />
CylinderSensor <br />
DirectionalLight <br />
Disk2D <br />
ElevationGrid <br />
EspduTransform <br />
Extrusion <br />
field <br />
fieldValue <br />
FillProperties <br />
FloatVertexAttribute <br />
Fog <br />
FogCoordinate <br />
FontStyle <br />
GeneratedCubeMapTexture <br />
GeoCoordinate <br />
GeoElevationGrid <br />
GeoLocation <br />
GeoLOD <br />
GeoMetadata <br />
GeoOrigin <br />
GeoPositionInterpolator <br />
GeoTouchSensor <br />
GeoViewpoint <br />
Group <br />
HAnimDisplacer <br />
HAnimHumanoid <br />
HAnimJoint <br />
HAnimSegment <br />
HAnimSite <br />
Image3DTexture <br />
ImageCubeMapTexture <br />
ImageTexture <br />
IndexedFaceSet <br />
IndexedLineSet <br />
IndexedQuadSet <br />
IndexedTriangleFanSet <br />
IndexedTriangleSet <br />
IndexedTriangleStripSet <br />
Inline <br />
IntegerSequencer <br />
IntegerTrigger <br />
KeySensor <br />
LineProperties <br />
LineSet <br />
LoadSensor <br />
LocalFog <br />
LOD <br />
Material <br />
Matrix3VertexAttribute <br />
Matrix4VertexAttribute <br />
MetadataDouble <br />
MetadataFloat <br />
MetadataInteger <br />
MetadataSet <br />
MetadataString <br />
MovieTexture <br />
MultiTexture <br />
MultiTextureCoordinate <br />
MultiTextureTransform <br />
NavigationInfo <br />
Normal <br />
NormalInterpolator <br />
NurbsCurve <br />
NurbsCurve2D <br />
NurbsOrientationInterpolator <br />
NurbsPatchSurface <br />
NurbsPositionInterpolator <br />
NurbsSet <br />
NurbsSurfaceInterpolator <br />
NurbsSweptSurface <br />
NurbsSwungSurface <br />
NurbsTextureCoordinate <br />
NurbsTrimmedSurface <br />
OrientationInterpolator <br />
PackagedShader <br />
Pixel3DTexture <br />
PixelTexture <br />
PlaneSensor <br />
PointLight <br />
PointSet <br />
Polyline2D <br />
Polypoint2D <br />
PositionInterpolator <br />
PositionInterpolator2D <br />
ProgramShader <br />
ProtoInstance <br />
ProximitySensor <br />
QuadSet <br />
ReceiverPdu <br />
Rectangle2D <br />
ScalarInterpolator <br />
Script <br />
ShaderPart <br />
ShaderProgram <br />
Shape <br />
SignalPdu <br />
Sound <br />
Sphere <br />
SphereSensor <br />
SpotLight <br />
StaticGroup <br />
StringSensor <br />
Switch <br />
Text <br />
TextureBackground <br />
TextureCoordinate <br />
TextureCoordinate3D <br />
TextureCoordinate4D <br />
TextureCoordinateGenerator <br />
TextureMatrixTransform <br />
TextureTransform <br />
TextureTransform3D <br />
TimeSensor <br />
TimeTrigger <br />
TouchSensor <br />
Transform <br />
TransmitterPdu <br />
TriangleFanSet <br />
TriangleSet <br />
TriangleSet2D <br />
TriangleStripSet <br />
Viewpoint <br />
VisibilitySensor <br />
WorldInfo<br />
</pre></div>Joedwhttps://www.web3d.org/wiki/index.php?title=Node_Reference&diff=1341Node Reference2006-01-25T04:08:54Z<p>Joedw: </p>
<hr />
<div><h2>List of Nodes</h2><br />
From <br />
ISO-IEC-19776-1-FDIS-X3DEncodings-XML/Part01/EncodingOfNodes.html<br />
<br />
Anchor <br />
Appearance <br />
Arc2D <br />
ArcClose2D <br />
AudioClip <br />
Background <br />
Billboard <br />
BooleanFilter <br />
BooleanSequencer <br />
BooleanToggle <br />
BooleanTrigger <br />
Box <br />
CADAssembly <br />
CADFace <br />
CADLayer <br />
CADPart <br />
Circle2D <br />
Collision <br />
Color <br />
ColorInterpolator <br />
ColorRGBA <br />
Composed3DTexture <br />
ComposedCubeMapTexture <br />
ComposedShader <br />
Cone <br />
Contour2D <br />
ContourPolyline2D <br />
Coordinate <br />
CoordinateDouble <br />
CoordinateInterpolator <br />
CoordinateInterpolator2D <br />
Cylinder <br />
CylinderSensor <br />
DirectionalLight <br />
Disk2D <br />
ElevationGrid <br />
EspduTransform <br />
Extrusion <br />
field <br />
fieldValue <br />
FillProperties <br />
FloatVertexAttribute <br />
Fog <br />
FogCoordinate <br />
FontStyle <br />
GeneratedCubeMapTexture <br />
GeoCoordinate <br />
GeoElevationGrid <br />
GeoLocation <br />
GeoLOD <br />
GeoMetadata <br />
GeoOrigin <br />
GeoPositionInterpolator <br />
GeoTouchSensor <br />
GeoViewpoint <br />
Group <br />
HAnimDisplacer <br />
HAnimHumanoid <br />
HAnimJoint <br />
HAnimSegment <br />
HAnimSite <br />
Image3DTexture <br />
ImageCubeMapTexture <br />
ImageTexture <br />
IndexedFaceSet <br />
IndexedLineSet <br />
IndexedQuadSet <br />
IndexedTriangleFanSet <br />
IndexedTriangleSet <br />
IndexedTriangleStripSet <br />
Inline <br />
IntegerSequencer <br />
IntegerTrigger <br />
KeySensor <br />
LineProperties <br />
LineSet <br />
LoadSensor <br />
LocalFog <br />
LOD <br />
Material <br />
Matrix3VertexAttribute <br />
Matrix4VertexAttribute <br />
MetadataDouble <br />
MetadataFloat <br />
MetadataInteger <br />
MetadataSet <br />
MetadataString <br />
MovieTexture <br />
MultiTexture <br />
MultiTextureCoordinate <br />
MultiTextureTransform <br />
NavigationInfo <br />
Normal <br />
NormalInterpolator <br />
NurbsCurve <br />
NurbsCurve2D <br />
NurbsOrientationInterpolator <br />
NurbsPatchSurface <br />
NurbsPositionInterpolator <br />
NurbsSet <br />
NurbsSurfaceInterpolator <br />
NurbsSweptSurface <br />
NurbsSwungSurface <br />
NurbsTextureCoordinate <br />
NurbsTrimmedSurface <br />
OrientationInterpolator <br />
PackagedShader <br />
Pixel3DTexture <br />
PixelTexture <br />
PlaneSensor <br />
PointLight <br />
PointSet <br />
Polyline2D <br />
Polypoint2D <br />
PositionInterpolator <br />
PositionInterpolator2D <br />
ProgramShader <br />
ProtoInstance <br />
ProximitySensor <br />
QuadSet <br />
ReceiverPdu <br />
Rectangle2D <br />
ScalarInterpolator <br />
Script <br />
ShaderPart <br />
ShaderProgram <br />
Shape <br />
SignalPdu <br />
Sound <br />
Sphere <br />
SphereSensor <br />
SpotLight <br />
StaticGroup <br />
StringSensor <br />
Switch <br />
Text <br />
TextureBackground <br />
TextureCoordinate <br />
TextureCoordinate3D <br />
TextureCoordinate4D <br />
TextureCoordinateGenerator <br />
TextureMatrixTransform <br />
TextureTransform <br />
TextureTransform3D <br />
TimeSensor <br />
TimeTrigger <br />
TouchSensor <br />
Transform <br />
TransmitterPdu <br />
TriangleFanSet <br />
TriangleSet <br />
TriangleSet2D <br />
TriangleStripSet <br />
Viewpoint <br />
VisibilitySensor <br />
WorldInfo</div>Joedwhttps://www.web3d.org/wiki/index.php?title=Node_Reference&diff=1340Node Reference2006-01-25T04:07:30Z<p>Joedw: Just a start with I think the latest set of spec nodes</p>
<hr />
<div>List of Nodes From <br />
ISO-IEC-19776-1-FDIS-X3DEncodings-XML/Part01/EncodingOfNodes.html<br />
<br />
Anchor <br />
Appearance <br />
Arc2D <br />
ArcClose2D <br />
AudioClip <br />
Background <br />
Billboard <br />
BooleanFilter <br />
BooleanSequencer <br />
BooleanToggle <br />
BooleanTrigger <br />
Box <br />
CADAssembly <br />
CADFace <br />
CADLayer <br />
CADPart <br />
Circle2D <br />
Collision <br />
Color <br />
ColorInterpolator <br />
ColorRGBA <br />
Composed3DTexture <br />
ComposedCubeMapTexture <br />
ComposedShader <br />
Cone <br />
Contour2D <br />
ContourPolyline2D <br />
Coordinate <br />
CoordinateDouble <br />
CoordinateInterpolator <br />
CoordinateInterpolator2D <br />
Cylinder <br />
CylinderSensor <br />
DirectionalLight <br />
Disk2D <br />
ElevationGrid <br />
EspduTransform <br />
Extrusion <br />
field <br />
fieldValue <br />
FillProperties <br />
FloatVertexAttribute <br />
Fog <br />
FogCoordinate <br />
FontStyle <br />
GeneratedCubeMapTexture <br />
GeoCoordinate <br />
GeoElevationGrid <br />
GeoLocation <br />
GeoLOD <br />
GeoMetadata <br />
GeoOrigin <br />
GeoPositionInterpolator <br />
GeoTouchSensor <br />
GeoViewpoint <br />
Group <br />
HAnimDisplacer <br />
HAnimHumanoid <br />
HAnimJoint <br />
HAnimSegment <br />
HAnimSite <br />
Image3DTexture <br />
ImageCubeMapTexture <br />
ImageTexture <br />
IndexedFaceSet <br />
IndexedLineSet <br />
IndexedQuadSet <br />
IndexedTriangleFanSet <br />
IndexedTriangleSet <br />
IndexedTriangleStripSet <br />
Inline <br />
IntegerSequencer <br />
IntegerTrigger <br />
KeySensor <br />
LineProperties <br />
LineSet <br />
LoadSensor <br />
LocalFog <br />
LOD <br />
Material <br />
Matrix3VertexAttribute <br />
Matrix4VertexAttribute <br />
MetadataDouble <br />
MetadataFloat <br />
MetadataInteger <br />
MetadataSet <br />
MetadataString <br />
MovieTexture <br />
MultiTexture <br />
MultiTextureCoordinate <br />
MultiTextureTransform <br />
NavigationInfo <br />
Normal <br />
NormalInterpolator <br />
NurbsCurve <br />
NurbsCurve2D <br />
NurbsOrientationInterpolator <br />
NurbsPatchSurface <br />
NurbsPositionInterpolator <br />
NurbsSet <br />
NurbsSurfaceInterpolator <br />
NurbsSweptSurface <br />
NurbsSwungSurface <br />
NurbsTextureCoordinate <br />
NurbsTrimmedSurface <br />
OrientationInterpolator <br />
PackagedShader <br />
Pixel3DTexture <br />
PixelTexture <br />
PlaneSensor <br />
PointLight <br />
PointSet <br />
Polyline2D <br />
Polypoint2D <br />
PositionInterpolator <br />
PositionInterpolator2D <br />
ProgramShader <br />
ProtoInstance <br />
ProximitySensor <br />
QuadSet <br />
ReceiverPdu <br />
Rectangle2D <br />
ScalarInterpolator <br />
Script <br />
ShaderPart <br />
ShaderProgram <br />
Shape <br />
SignalPdu <br />
Sound <br />
Sphere <br />
SphereSensor <br />
SpotLight <br />
StaticGroup <br />
StringSensor <br />
Switch <br />
Text <br />
TextureBackground <br />
TextureCoordinate <br />
TextureCoordinate3D <br />
TextureCoordinate4D <br />
TextureCoordinateGenerator <br />
TextureMatrixTransform <br />
TextureTransform <br />
TextureTransform3D <br />
TimeSensor <br />
TimeTrigger <br />
TouchSensor <br />
Transform <br />
TransmitterPdu <br />
TriangleFanSet <br />
TriangleSet <br />
TriangleSet2D <br />
TriangleStripSet <br />
Viewpoint <br />
VisibilitySensor <br />
WorldInfo</div>Joedw