Chapter
2 Key Concepts
2.1 Intro
2.1.1 Overview
2.1.2 TOC
2.1.3 Conventions
2.2 Overview
2.2.1 File Structure
2.2.2 Header
2.2.3 Scene graph
2.2.4 Prototypes
2.2.5 Routing
2.2.6 Generating files
2.2.7 Presentation
& Interaction
2.2.8 Profiles
2.3 UTF-8 syntax
2.3.1 Clear text
2.3.2 Statements
2.3.3 Node
2.3.4 Field
2.3.5 PROTO
2.3.6 IS
2.3.7 EXTERNPROTO
2.3.8 USE
2.3.9 ROUTE
2.4 Scene graph
2.4.1 Root nodes
2.4.2 Hierarchy
2.4.3 Descendants
& ancestors
2.4.4 Hierarchy
2.4.5 Units & coord sys
2.5 VRML & WWW
2.5.1 MIME type
2.5.2 URLs
2.5.3 Relative URLs
2.5.4 data:
2.5.5 Scripting protocols
2.5.6 URNs
2.6 Nodes
2.6.1 Intro
2.6.2 DEF/USE
2.6.3 Geometry
2.6.4 Bboxes
2.6.5 Grouping & children
2.6.6 Lights
2.6.7 Sensors
2.6.8 Interpolators
2.6.9 Time nodes
2.6.10 Bindable children
2.6.11 Textures
2.7 Field, eventIn,
& eventOut
2.8 PROTO
2.8.1 Declaration
2.8.2 Definition
2.8.3 Scoping
2.9 EXTERNPROTO
2.9.1 Interface
2.9.2 URL
2.9.3 Extensions
2.10 Events
2.10.1 Intro
2.10.2 Routes
2.10.3 Execution
2.10.4 Loops
2.10.5 Fan-in & fan-out
2.11 Time
2.11.1 Intro
2.11.2 Origin
2.11.3 Discrete/cont
2.12 Scripting
2.12.1 Intro
2.12.2 Execution
2.12.3 Initialize/shutdown
2.12.4 eventsProcessed
2.12.5 Direct outputs
2.12.6 Asynchronous
2.12.7 Languages
2.12.8 EventIns
2.12.9 fields & events
2.12.10 Browser interface
2.13 Navigation
2.13.1 Intro
2.13.2 Navigation
2.13.3 Viewing
2.13.4 Collisions
2.14 Lighting
2.14.1 Intro
2.14.2 'off'
2.14.3 'on'
2.14.4 Equations
2.14.5 References
|
The EXTERNPROTO statement defines a new node type. It is equivalent
to the PROTO statement, with two exceptions. First, the implementation
of the node type is stored externally, either in a VRML file containing
an appropriate PROTO statement or using some other implementation-dependent
mechanism. Second, default values for fields are not given since the
implementation will define appropriate defaults.
The semantics of the EXTERNPROTO are exactly the same as for a PROTO
statement, except that default field and exposedField values are not
specified locally. In addition, events sent to an instance of an externally
prototyped node may be ignored until the implementation of the node
is found.
The names and types of the fields, exposedFields, eventIns, and eventOuts
of the interface declaration must be a subset of those defined in the
implementation. Declaring a field or event with a non-matching name
is an error, as is declaring a field or event with a matching name but
a different type.
It is recommended that user-defined field or event names defined in
EXTERNPROTO interface statements follow the naming conventions described
in "2.7 Fields, eventIns, and eventOuts
semantics."
TECHNICAL
NOTE: Allowing the user to give the EXTERNPROTO a different
type name than the type name defined in the prototype definition
file makes it possible always to compose together prototypes created
by different people. For example, suppose you wanted to use two
different prototypes both named House, but defined by different
people (Helga and Jackie). The requirement that node type and
prototype names be unique in any file would be a problem if EXTERNPROTO
did not allow a renaming to occur. In this case, you could create
the following file:
# Reference to file containing PROTOHouse
EXTERNPROTO HelgaHouse [ ... ]
"http://helga.net/House.wrl"
# Reference to file containing PROTO House
EXTERNPROTO JackieHouse [ ... ]
"http://jackie.net/House.wrl"
http://helga.net/House.wrl:
PROTO House [...] { ... } # Helga DEF House proto
http://jackie.net/House.wrl:
PROTO House [...] { ... } # Jackie DEF House proto
and then
instantiate as many HelgaHouses and JackieHouses as you wish.
|
The string or strings specified after the interface
declaration give the location of the prototypes implementation. If multiple
strings are specified, the browser searches in the order of preference
(see "2.5.2 URLs").
If a URL string refers to a VRML file, the first
PROTO statement found in the file (excluding EXTERNPROTOs) is used to
define the external prototype's definition. The name of that prototype
does not need to match the name given in the EXTERNPROTO statement.
To allow the creation of libraries of small,
reusable PROTO definitions, browsers shall recognize EXTERNPROTO URLs
that end with "#name" to mean the PROTO statement
for "name" in the given file. For example, a library of standard
materials might be stored in a file called "materials.wrl"
that looks like:
#VRML V2.0 utf8
PROTO Gold [] { Material { ... } }
PROTO Silver [] { Material { ... } }
...etc.
A material from this library could be used as
follows:
#VRML V2.0 utf8
EXTERNPROTO GoldFromLibrary []
"http://.../materials.wrl#Gold"
...
Shape {
appearance Appearance { material GoldFromLibrary {} }
geometry ...
}
...
TIP:
Note that the file materials.wrl described here is a perfectly valid
VRML file, but will not render anything if loaded into a browser
directly. This is because the file contains only prototype statements
and does not instantiate any nodes. |
TECHNICAL
NOTE: Even
though you can put several PROTO definitions into one file, you
can't "#include" that entire file and have all of the
definitions available. You must have an EXTERNPROTO statement for
each prototype you use. The reasons there is no "#include"
feature for VRML are the same reasons that EXTERNPROTO requires
you to declare the fields and events of the prototype--because it
is assumed that VRML will be used on the Internet, where there are
no guarantees that auxiliary files will be available. A C compiler
can simply report an error and stop compilation if it can't find
an include file. A VRML browser must be more robust; it shouldn't
give up if some small part of a large world cannot be loaded. |
Browsers that wish to add functionality beyond
the capabilities in this standard shall do so only by creating prototypes or external prototypes.
If the new node cannot be expressed using the prototyping mechanism
(i.e., it cannot be expressed in the form of a VRML scene graph),
it shall be defined as an external prototype with a unique URN specification.
Authors who use the extended functionality may provide multiple, alternative
URLs or URNs to represent content to ensure it is viewable on all browsers.
For example, suppose a browser wants to create
a native Torus geometry node implementation:
EXTERNPROTO Torus [ field SFFloat bigR,
field SFFloat smallR ]
["urn:inet:browser.com:library:Torus",
"http://.../proto_torus.wrl" ]
This browser will recognize the URN and use
the URN resource's own private implementation of the Torus node. Other
browsers may not recognize the URN, and skip to the next entry in the
URL list and search for the specified prototype file. If no URLs are
found, the Torus is assumed to be an empty node.
The prototype name "Torus" in the
above example has no meaning whatsoever. The URN/URL uniquely and precisely
defines the name/location of the node implementation. The prototype
name is strictly a convention chosen by the author and shall not be
interpreted in any semantic manner. The following example uses both
"Ring" and "Donut" to name the torus node. However,
the URN/URL pair "urn:browser.com:library:Torus, http://.../proto_torus.wrl"
specifies the actual definitions of the Torus node:
#VRML V2.0 utf8
EXTERNPROTO Ring [ field SFFloat bigR,
field SFFloat smallR ]
[ "urn:browser.com:library:Torus",
"http://.../proto_torus.wrl" ]
EXTERNPROTO Donut [ field SFFloat bigR,
field SFFloat smallR ]
[ "urn:browser.com:library:Torus",
"http://.../proto_torus.wrl" ]
Transform { ... children Shape { geometry Ring { } } }
Transform { ... children Shape { geometry Donut { } } }
TECHNICAL
NOTE: Implementing
built-in extensions this way has several big advantages over just
"magically" recognizing a prototype node type name:
- The
URN standard defines a global namespace, eliminating potential
naming conflicts. Once the URN standard is widely adopted, there
will be an infrastructure supporting the global namespace, and
features such as transparent replication of commonly used objects
and extensions across the Internet will be possible with no
changes to the VRML file format.
- The
EXTERNPROTO mechanism allows a name remapping to occur, allowing
the long, globally unique URN names to be given shorter names.
Conflicts between the short names are easy to avoid, because
the names are under the control of the VRML file creator.
|
|