This is Interesting: Free Magazines for Graphics designers and webmasters
Home > Archive > VRML > December 2003 > eventout in script within proto ?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
eventout in script within proto ?
|
|
| Robert Ludewig 2003-12-10, 10:18 pm |
| hello is there a way to get an eventout of a script (wich is within a
proto) out of the proto?
like this:
Proto timer
[
eventOut SFTime time
]
{
# here is a Scriptnode that generates a time that shall
# be the eventout of this proto
}
so I could to:
ROUTE timer.time TO MyTimeSensor.starttime
| |
| Joerg Scheurich aka MUFTI 2003-12-10, 10:18 pm |
| > hello is there a way to get an eventout of a script (wich is within aquote:
> proto) out of the proto?
quote:
> like this:
quote:
> Proto timer
> [
> eventOut SFTime time
> ]
> {
> # here is a Scriptnode that generates a time that shall
> # be the eventout of this proto
quote:
> }
quote:
> so I could to:
quote:
> ROUTE timer.time TO MyTimeSensor.starttime
simply use "IS" in the script header
#VRML V2.0 utf8
PROTO timer
[
eventOut SFTime time
]
{
DEF TimeSensor1 TimeSensor
{
loop TRUE
}
DEF Script2 Script
{
eventIn SFTime time1_in
eventOut SFTime time IS time
url
[
"java script:
// eventOut SFTime time //
function time1_in(value)
{
// value SFTime
time = value;
}
"
]
}
ROUTE TimeSensor1.time TO Script2.time1_in
}
DEF timer1 timer
{
}
DEF Script1 Script
{
eventIn SFTime time1_in
url
[
"java script:
function time1_in(value)
{
// value SFTime
print(value);
}
"
]
}
ROUTE timer1.time TO Script1.time1_in
| |
| Robert Ludewig 2003-12-11, 8:26 pm |
| That brings me to another question:
if the proto hase some exposedfields , how do I acess them within a Script?
IS doesn`t seem to work.
| |
| Jeremy Pitten 2003-12-11, 8:26 pm |
| Assuming the proto exposedFields map to some node exposedField within the
proto definition then you need to define a ROUTE statement to route an
eventOut generated by the exposedField to the eventIn in the script node.
So, for example:
proto Timer [
exposedField SFBool enable false
]{
DEF time TimerSensor { enabled IS enable }
DEF script Script {
eventIn SFBool setEnabled
url [ "javascript : function setEnabled(value){ blah blah } ]
}
ROUTE time.enabled_changed TO script.setEnabled
}
"Robert Ludewig" <schwertfischtrombose@gmx.de> wrote in message
news:683ab5d5.0312090244.a220434@posting.google.com...quote:
> That brings me to another question:
>
> if the proto hase some exposedfields , how do I acess them within a
Script?quote:
> IS doesn`t seem to work.
| |
| PrisNo6 2003-12-15, 4:36 pm |
| schwertfischtrombose@gmx.de (Robert Ludewig) wrote in message news:<683ab5d5.0312090244.a220434@posting.google.com>...
<snip> > if the proto has some exposedfields , how do I access themquote:
> within a Script? IS doesn`t seem to work.
I recently had to slog through this, so this is how I ended up
conceptualizing the problem. The following solution has only been
tested with the Cortona plug-in viewer. It does not work with the
native Microsoft IE 6.0 VRML viewer. IMHO, this problem seems to be
rarely explained with any clarity in VRML web pages and books. (P.S. -
I'm no expert at this.) This explanation assumes some rudimentary
background in object oriented programming (i.e. - the difference
between an object and an interface) and script writing with
javascript.
Think of a VRML file in terms of object oriented programing -
PROTOtype is an interface between the external world and an instance
of a VRML object.
PROTO communicates data to the properties (nodes) of an instance of a
VRML object through the "IS" statement. "IS" is reserved for
communicating data only between the PROTOtype interface and the
properties (nodes) of an VRML object. That is why you cannot use the
"IS" statement to reach a method (your script node).
VRML object is a series of properties (nodes) and methods (scripts).
Not all properties (nodes) can be changed. Only those nodes whose
properties support a "set" statement can be changed. Each of these
properties and methods can communicate via the "USE" and "ROUTE"
statements. Analogous to the "IS" statement, the "USE" and "ROUTE"
statements only communicate between properties and methods within the
instance of a VRML object. They cannot communicate with the interface
between the VRML object and the external world, i.e. - the PROTOtype.
"USE" and "ROUTE" can only communicate between a VRML objects
properties and methods, where:
1) for "USE", typically employed to send data to a method (a
javascript) or a property (another node), the sending object is given
an object name using the "DEF" statement. The DEF statement uniquely
identifies a node, so the VRML object knows which of several sphere,
font, or transform statements that you want to communicate with.
2) for "ROUTE", the sending and receiving methods or properties must
be given an object name using the "DEF" statement.
3) for "ROUTE", the receiving method or property must have a writeable
interface. For nodes, these are usually identified with the "set"
statement, e.g. the set_rotation and set_translation methods of the
Transform node.
"USE" and "ROUTE" are also used to define an interface that wraps an
external javascript application program. It functions like the PROTO,
but allows the VRML object to communicate with the external javascript
application object.
The following example illustrates these principles. I'll use external
data in a text file that contains the size of an object, loop it
through PROTO, to an external javascript program, and then use the
data in the script to position a label next to the object. The result
of the script will be used by ROUTE to set a Transform.translation on
the label.
Beginning with the text data:
SO { objName "Red Ball" objSize 0.10 0.10 0.10 objPosition 5 5 5 }
SO { objName "Green Ball" objSize 0.02 0.02 0.02 objPosition 0 0 0 }
This data is routed through the PROTO interface -
PROTO SO [
field MFString objName "Object" # object
field SFVec3f objSize 0.1 0.1 0.1 # size - radii in x,y,z
field SFVec3f objPosition 0 0 0
]
Using the "IS" statement, the object size and position transferred
from the data file to the PROTOtype interface and then on to an
instance of a VRML object to set the position and size of the object
in a Transform node:
DEF Sphere_Object Transform {
# Position of object, translated in x,y,z
translation IS objPosition
.. . . .
# Size of object, stretched in x,y,z
Transform {
scale IS objSize
children [
Shape { . . . }
geometry Sphere { }
.. . . .
This repositions and sizes the plotted sphere.
Now we'll stub the text label for the object, which we want to place
next to the plotted sphere -
DEF lblObject Transform {
translation 0.0 0.0 0.0
.. . . .
geometry DEF lblName Text {
Note the "DEF" statement is used to uniquely identify this text label
to the VRML object. Now its unique translation property
(lblObject.Transform.translation) can be accessed and changed with a
set_translation command (e.g. lblObject.Transform.set_translation ).
However the proper position of the text label for the object is
somewhere off - in objSize - units to the x-plane right of
objPosition. So objPosition and/or objSize cannot be used to directly
set the label position with the IS statement. The correct translation
for the label position (in the x plane) is objSize plus some lead
padding. This cannot be done directly from the PROTOtype or within a
VRML node. The sum must be computed first in an external script based
on data received by the VRML object from the PROTOtype, and then a
Transform node is used to move the label to the correct position -
PROTOtypes cannot communicate directly with a script node. So first
we create a "dummy" intermediate node that receives the data from the
PROTO interface. It is never displayed in your VRML world; it only
holds data within the instance of your VRML object. It needs to be of
the same field type as the PROTO, e.g. -
# to set label position on initialization
DEF tmp_objSize Transform { scale IS objSize }
"scale" is a SFVec3f variable in both the PROTOtype
(SFVec3f:objSize)and the VRML object's Transform node
(SFVec3f:tmp_objSize.Transform.scale).
Now we start the script node and define an interface between the
encapsulated javascript program and our VRML object. Note the
employment of "USE" to get the data (the object size) from the the
temporary variable node and into the javascript program -
DEF get_Initialize Script {
# Make an interface from the VRML object variables to the
# external javascript program with USE
# This moves the data in the VRML object node "tmp_objSize"
# into a javascript variable (an array) called "LabelScale
field SFNode LabelScale USE tmp_objSize
# once LabelScale is defined in this interface,
# it is available to the external javascript program.
# See also the "label_spacing" on the output side of the interface.
# Note that VRML 2.0 automatically translates the node object
# and its SFVec3f variable node (defined in the script's interface)
# into a javascript type zero-based array of three elements.
directOutput TRUE
# Here's the wrapped external javascript program
url [
"java script:
function initialize ( ) {
// the javascript function "initialize" executes only once -
// when the VRML object is first created
// take the "x" coordinate of the object's size and add some padding
label_spacing[0] = LabelScale.scale[0] + 0.1
label_spacing[1] = 0
label_spacing[2] = 0
}"
]
# Make an interface for external javascript program's output
eventOut SFVec3f label_spacing # label spacing
}
# Finally, tell VRML how to use the external javascript
# program's output to change the behavior of a VRML
# object's property (a node).
# In the example, move the label to the right of the object.
ROUTE get_Initialize.label_spacing TO lblObject.set_translation
The flow of data from the above can be summarized as, first:
Data file --> Proto --> IS --> Dummy/Temporary DEF Node
and then:
Dummy/Temp DEF --> USE --> Script In Interface --> Script Processing
--> eventOut variable --> Script Out Interface --> ROUTE
--> VRML Node set statement
This dataflow differs from the usual VRML event routing, where a VRML
object's node is the source of data sent to the script's interface,
e.g. -
DEF VRML node --> eventOut property --> ROUTE --> Script In Interface
--> eventIn variable --> Script Processing --> eventOut variable
--> Script Out Interface --> ROUTE --> VRML Node set statement
Not all VRML nodes have set statement methods. For example, while
Transform has the set_translation method; a Sphere's size cannot be
directly accessed because there is no Sphere.set_size method for a
Sphere node.
The principles discussed above apply to your set the start time on
initialization problem. A TimeSensor node also has a
TimeSensor.startTime property and a TimeSensor.set_startTime method.
Other posters have given you more specific solutions using the above
principles and the TimeSensor object.
I hope this overlength explanation of this obtuse area of VRML helps
and has not been too confusing. - Kurt
P.S. - Some links explaining the "object" and "interface" in object
oriented programming -
http://www.softwaredesign.com/objects.html
http://www.cs.ucf.edu/courses/cop33...l2003/day21.pdf Begin at p.
17
| |
| Joerg Scheurich aka MUFTI 2003-12-17, 9:42 am |
| > VRML object is a series of properties (nodes) and methods (scripts).
But without any doubt, a "script" is a "node".
http://www.web3d.org/technicalinfo/...pts.html#4.12.2
| A Script node is activated when it receives an event.
so long
MUFTI
--
6 von 5 Datei(en) erfolgreich empfangen.
Statusmeldung von Leonardo
| |
| Joerg Scheurich aka MUFTI 2003-12-17, 9:42 am |
| > PROTO communicates data to the properties (nodes) of an instance of aquote:
> VRML object through the "IS" statement. "IS" is reserved for
> communicating data only between the PROTOtype interface and the
> properties (nodes) of an VRML object.
True. And cause a script is a node, is is legal to use IS for the script
fields.
quote:
> That is why you cannot use the
> "IS" statement to reach a method (your script node).
As far as i know, the following is legal VRML.
It runs at least in cosmoplayer, blaxxun cc3dglut and openvrml lookat.
The only problem with scripts in PROTO is exposedField. Scripts do not
allow exposedField, therefore a IS is not possible in this case.
#VRML V2.0 utf8
PROTO scripting
[
eventIn SFFloat input
eventOut SFFloat output
]
{
DEF Script1 Script
{
eventIn SFFloat input IS input
eventOut SFFloat output IS output
url
[
"java script:
// eventOut SFFloat output //
function input(value)
{
// value
output = Math.sin(value*Math.PI);
}
"
]
}
}
DEF TimeSensor1 TimeSensor
{
loop TRUE
}
Transform
{
children
[
Shape
{
appearance Appearance
{
material DEF Material1 Material
{
}
}
geometry Cylinder
{
}
}
]
}
DEF scripting1 scripting
{
}
ROUTE TimeSensor1.fraction_changed TO scripting1.input
ROUTE scripting1.output TO Material1.set_transparency
| |
| Joerg Scheurich aka MUFTI 2003-12-17, 9:42 am |
| quote:
> "USE" and "ROUTE" can only communicate between a VRML objects
> properties and methods,
....quote:
> 1) for "USE", typically employed to send data to a method (a
> javascript) or a property (another node)
USE is not a communication mechanism.
USE is only a additional "not distinguishable pointer" to a node.
The principle of a "not distinguishable pointer" is also used
in the UNIX filesystem with the "hard link". It works similar.
so long
MUFTI
--
6 von 5 Datei(en) erfolgreich empfangen.
Statusmeldung von Leonardo
| |
| PrisNo6 2003-12-17, 9:42 am |
| Joerg Scheurich aka MUFTI <rusmufti@helpdesk.rus.uni-stuttgart.de> wrote in message news:<brmptq$ung$2@news.uni-stuttgart.de>...
<snip>
Thanks for your many experienced comments, particularly in
distinguishing that that scripts do not allow exposedField, therefore
a IS is not possible in this case. - Thanks Kurt
|
|
|
| | Copyright 2003 - 2008 forum4designers.com Software forum Computer Hardware reviews |
|