OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: The Power of Groves: The VRML View

[ Lists Home | Date Index | Thread Index ]
  • From: Len Bullard <cbullard@hiwaay.net>
  • To: "W. Eliot Kimber" <eliot@isogen.com>
  • Date: Thu, 10 Feb 2000 19:18:31 -0600

Because it is always hard to get started from an existing language 
and its meta-definitions, then map to another meta-language or 
framework of definitions, I am presenting an abbreviated version 
of the VRML language as described in Late Night VRML 2.0 with 
Java (Couch, Ballreich, Roehl and Brown).  Typically, many users 
start with such books and descriptions, so this a fair challenge 
and a convenient source for a condensed description.  That is 
why the following is in quotations although it is not a direct 
quote.  If we need more precision, we can use the VRML97 
specification online.  Some of my inline comments are in 
[NOTE ...].

"VRML has two data structures:  nodes and fields.  A node is the 
equivalent of a Java class.  A field is almost the equivalent of a 
variable and a method in one.

Nodes collect a series of fields that define the properties of that 
node.  A node is a standalone data structure and a file can declare 
a single node.  A file cannot contain a single field.  Node names 
must being each word with a capital letter and cannot contain 
underscores (eg, IndexedFaceSet).

VRML defines 54 nodes categorized into nine groups by function; 
Grouping nodes, Special Groups, Common nodes, Sensor nodes, Geometry 
nodes, Geometric property nodes, Appearance, Interpolator nodes, and 
Bindable nodes.

Fields are typed and named.  Types are of two kinds:  single (SF- eg,
SFFloat) as in a single variable and multi(MF - eg, MFFloat) as in an
array of singles (note:
not having arrays makes using Xschemas nasty and a candidate for
rejection).  Field 
names start with a lower case letter and use uppercase for each word
thereafter (eg, cycleTime).  Fields are semantically named for the
access type:  

field (no external access)
eventIn (writeOnly)
eventOut (readOnly)
exposedField(read and write)

To pass events among fields, the nodes must be named (DEFd see below) 
and the declaration of the connection is via the ROUTE keyword between 
fields of the same type.  ROUTE statements name the node.field from and 
node.field to.  

ROUTE fromNode.eventOutField TO toNode.eventInField

The logical structure of the VRML is called a scene graph.  It refers 
to the relationships of the visible scene.

Syntax:  The scope of a node definition is denoted by matching curly 
brackets (same as Java).  Nodes are nodeType, open curly bracket,
fields, 
closed curly bracket.  VRML files must begin with a VRML header of the
form 
filetype, version, encoding.  Therefore:

#VRML V2.0 utf8

Field declaration is the field name followed by its value.  Vectors are
whitespace separated numbers.  Eg

Material { diffuseColor 0 0.2 0.1 }

Multivalued fields enclose values with square brackets and use commas or
whitespace as separators.

Grouping nodes contain other nodes in the children field. [NOTE: 
a nasty thing, we have to use the children wrapper.  Note, fields 
can be of type MFNode.]

Each node can contain other nodes in a parent child relationship. 
[NOTE:  A DTD for this which is precise and restricts illegal 
combinations has content models which are very very big and 
hard to read.]

Nodes can be reused by associating a name with a node.  The syntax 
is to use the DEF keyword followed by the name.  When used elsewhere, a 
USE keyword followed by the name DEFd earlier is provided.  So

Transform { translation -1 0 0 
            children  Shape {
                 geometry  DEF thisBox Box {
                                 size 2 1 3 }
                 }
          }

Transform { translation 2 0 0 
            children  Shape {
                 geometry  USE thisBox
              }
           }

Names are scoped to the file and can only be referenced 
within the file.  An inlined file is a closed scope.  A 
prototyped node is a closed scope.  A prototype (usually 
called simply proto) is a customized node that can be 
added to a scene.  It is a black box and is treated like 
a standard node in the scene.  Proto nodes are the extensibility 
feature of VRML.  It is a canned object that once declared, 
can be used to create multiple independent copies.  A 
DEFd node which is USEd is not independent.  If any affective 
field property value is changed in the original, it changes 
in all the copies. For example, if a Shape node has a Material 
value whose color is red, and red is changed to brown, all 
USEd copies change to brown.  If a proto is changed, only 
the local copy changes.

The declaration rules for protos are different.  A proto 
has a name, field definition, and implementation."

We'll stop here for now.  This is probably enough to get 
started.  Protos are interesting beasties because the enable 
inline extensibility such that one can create a proto for 
a new kind of shape (say a torus) that is not defined as a 
primitive in VRML, then use it as if it were one.  Further, 
because scripts can be part of the implementation, it is 
an object that behaves in response to routed events, or 
it can just be a behavior container for wrapping other 
nodes.
  
Protos and Externprotos can be referred to externally 
so you can use them to build parts libraries and in fact, 
that is precisely how the VRML community shares a lot of 
functional code through the VRML Proto Repository.


Len Bullard
Intergraph Public Safety
clbullar@ingr.com
http://fly.hiwaay.net/~cbullard/lensongs.ram

Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h





 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS