The Annotated VRML 97 Reference

1 Intro     Concepts     3 Nodes     4 Fields/Events    Conformance
A Grammar     B Java     C JavaScript     D Examples     E Related Info    References
Quick Java         Quick JavaScript         Quick Nodes   

  About the Book
  Copyright © 1997-99
  Purchase the book from

Chapter 3:
Node Reference


+3.8 Collision

Collision { 
  eventIn      MFNode   addChildren
  eventIn      MFNode   removeChildren
  exposedField MFNode   children   []
  exposedField SFBool   collide    TRUE
  field        SFVec3f  bboxCenter 0 0 0    # (-INF,INF)
  field        SFVec3f  bboxSize   -1 -1 -1 # (0,INF) or -1,-1,-1
  field        SFNode   proxy      NULL
  eventOut     SFTime   collideTime

The Collision node is a grouping node that specifies the collision detection properties for its children (and their descendants), specifies surrogate objects that replace its children during collision detection, and sends events signaling that a collision has occurred between the user's avatar and the Collision node's geometry or surrogate. By default, all geometric nodes in the scene are collidable with the viewer except IndexedLineSet, PointSet, and Text. Browsers shall detect geometric collisions between the user's avatar (see NavigationInfo) and the scene's geometry, and prevent the avatar from 'entering' the geometry.

If there are no Collision nodes specified in a scene, browsers shall detect collision with all objects during navigation.

Section "2.6.5 Grouping and children nodes" contains a description of the children, addChildren, and removeChildren fields and eventIns.

The Collision node's collide field enables and disables collision detection. If collide is set to FALSE, the children and all descendants of the Collision node shall not be checked for collision, even though they are drawn. This includes any descendent Collision nodes that have collide set to TRUE (i.e., setting collide to FALSE turns collision off for every node below it).

Collision nodes with the collide field set to TRUE detect the nearest collision with their descendent geometry (or proxies). Not all geometry is collidable. Each geometry node specifies its own collision characteristics. When the nearest collision is detected, the collided Collision node sends the time of the collision through its collideTime eventOut. This behaviour is recursive. If a Collision node contains a child, descendant, or proxy (see below) that is a Collision node, and both Collision nodes detect that a collision has occurred, both send a collideTime event at the same time.

TIP: The geometries that are not capable of colliding are IndexedLineSet, PointSet, and Text. Detecting collisions between 2D or 1D geometries and the 3D viewer is difficult, so they are defined to be transparent to collisions. If this is a problem, a proxy geometry (discussed later) can be specified for each IndexedLineSet, PointSet, and Text.

Surface properties (e.g., transparent textures or materials) have no affect on collisions. This isn't very realistic, but it can be very useful and makes implementation of Collision much easier. Again, Collision proxy geometry may be used if you want collision testing to match a partially transparent geometry.

The bboxCenter and bboxSize fields specify a bounding box that encloses the Collision node's children. This is a hint that may be used for optimization purposes. If the specified bounding box is smaller than the actual bounding box of the children at any time, the results are undefined. A default bboxSize value, (-1, -1, -1), implies that the bounding box is not specified and if needed must be calculated by the browser. A description of the bboxCenter and bboxSize fields may be found in "2.6.4 Bounding boxes".

The collision proxy, defined in the proxy field, is any legal children node as described in "2.6.5 Grouping and children nodes" that is used as a substitute for the Collision node's children during collision detection. The proxy is used strictly for collision detection; it is not drawn.

If the value of the collide field is FALSE, collision detection is not performed with the children or proxy descendent nodes. If the root node of a scene is a Collision node with the collide field set to FALSE, collision detection is disabled for the entire scene regardless of whether descendent Collision nodes have set collide TRUE.

If the value of the collide field is TRUE and the proxy field is non-NULL, the proxy field defines the scene on which collision detection is performed. If the proxy value is NULL, collision detection is performed against the children of the Collision node.

If proxy is specified, any descendent children of the Collision node are ignored during collision detection. If children is empty, collide is TRUE, and proxy is specified, collision detection is performed against the proxy but nothing is displayed. In this manner, invisible collision objects may be supported.

TIP: Navigating in 3D worlds can often be difficult. Whenever possible, use the Collision node with a simple, invisible proxy geometry (e.g., a force field) to constrain the avatar navigation to the regions of the world that are intended to be navigated (and to increase performance of collision detection). This technique avoids avatars from getting "stuck" in tight spots, wandering around aimlessly, or investigating portions of the scene that are not intended to be seen. Combining this with Anchors for guided tours or reference points can greatly improve world usability. When using invisible Collision objects to constrain avatars, it is recommended that a sound effect be issued on collision with the invisible geometry so that the user receives some extra feedback that the "force field" exists (route the collideTime eventOut from the Collision node to a Sound node's AudioClip startTime).

The collideTime eventOut generates an event specifying the time when the user's avatar (see NavigationInfo) intersects the collidable children or proxy of the Collision node. An ideal implementation computes the exact time of intersection. Implementations may approximate the ideal by sampling the positions of collidable objects and the user. The NavigationInfo node contains additional information for parameters that control the user's size.

There is no support for object/object collision in ISO/IEC 14772-1.

Collision node figure

Figure 3-8: Collision Node

TECHNICAL NOTE: A navigation type of NONE (see the NavigationInfo node) implies that the world author is controlling all navigation, in which case the world author can use a Collision node to detect and respond to collisions.

Note that the Collision node only handles collisions between the user and the world; it does not detect collisions between arbitrary objects in the world. General, object-to-object collision detection is not specified in VRML.

Collision detection and terrain following are often confused. Terrain following means keeping the viewer's feet on the ground and is a function of the VRML browser's user interface. The avatarSize field of the NavigationInfo node can be used to control the viewer's height above the terrain, and browsers may decide to treat objects that are invisible to collisions as also being invisible to terrain-following calculations.

EXAMPLE (click to run): The following example illustrates several uses of the Collision node. Note the use of the invisible proxy to restrict avatar navigation in the second room:

#VRML V2.0 utf8 
Group { children [ 
  Collision { children [ # 1st room - collidable
    Shape { 
      appearance DEF WHITE Appearance { 
        material DEF M Material { 
          diffuseColor 1 1 1 
          ambientIntensity .33 
      geometry Extrusion { 
        crossSection [ 23 -17, 20 -17, 20 -30,  0 -30,
                        0   0, 20   0, 20 -13, 23 -13 ] 
        spine [ 0 0 0, 0 3 0 ] 
        ccw FALSE 
    Transform { translation 5 1 -24  # Cone in 1st room
      children Collision { 
        proxy DEF BBOX Shape { geometry Box{} } 
         children DEF CONE Shape { geometry Cone {} } 
    Transform { 
      translation 15 0.3 -26 # Sphere in 1st room
      children Collision { 
        proxy USE BBOX 
        children DEF SPHERE Shape { 
          geometry Sphere {} 
    Transform {
      translation 15 0.3 -5 # Box in the 1st room
      children Collision { 
        proxy USE BBOX 
        children DEF BOX Shape { geometry Box {} }
  ]} # end of first room 
  Collision {        # Second room - uses proxy 
    proxy Shape { 
      geometry Extrusion { 
        crossSection [ 23 -17, 40 -25, 40 -5, 23 -13 ] 
        spine [ 0 0 0, 0 3 0 ] 
    children [ # These children will not be collided w/
      Shape {  # 2nd room 
        appearance USE WHITE 
        geometry Extrusion { 
          crossSection [ 23 -17, 23 -30, 43 -30, 43 0,
                         23 0, 23 -13 ] 
          spine [ 0 0 0, 0 3 0 ] 
      Transform { 
        translation 25 1 -24 
        children USE CONE 
      Transform { 
        translation 40 0.3 -2 
        children USE SPHERE 
      Transform { 
        translation 40 0.3 -28 
        children USE BOX 
  Collision { # Translucent force field - no collision
    collide FALSE
    children Shape { 
      geometry Extrusion { 
      crossSection [ 21.5 -17, 21.5 -13 ] 
      spine [ 0 0.2 0, 0 2.5 0 ] 
      solid FALSE 
  Viewpoint { position 3.0 1.6 -2 } 
  PointLight { location 22 20 -15 radius 20 }