Beginner X3D and H3DAPI


Jump to: navigation, search

The information on this page is meant for the X3D beginner. If you are already familiar with X3D, you may read the introduction to H3DAPI and proceed to explore H3D-specific nodes. The introduction provided here is meant to be a brief one that equips the beginner with sufficient background before jump starting on H3DAPI programming. More complete details on X3D can be found in suggested readings.



X3D is an abbreviation for Extensible 3D, an ISO-approved standard formulated by the Web3D Consortium for defining interactive multimedia-integrated 3D content. Rather than a language and more than a file format, X3D specifies a runtime architecture to represent 3D scenes and objects. This runtime architecture is based on a scene graph, which models the entire 3D scene in one directed acyclic graph.

X3D scenes are read (and may be written to), processed, and displayed by an X3D browser. At runtime, the X3D scene graph is traversed repeatedly. At every traversal, changes in the scene that need to be updated are rendered and displayed. For graphics rendering the frequency of this traversal normally suffices at 25Hz.

X3D uses several file encodings, the most common being the XML encoding, thus if you are familiar with other XML-based files the X3D formatting and syntax would not seem very foreign to you.

Nodes and fields

An X3D scene is composed of nodes and fields. Fields are data containers that specify properties. Nodes can be viewed as containers that group related fields together to define objects in the scene. As an example, the Background node contains among many, the fields skyColor, skyAngle, transparency and topUrl, which defines how the background of an X3D scene should look like.

Field types

Fields are typed, which means that a field can only carry data of a specified type as its value. There are two classes of field types in general: field types that contain a single value, and field types that contain an ordered list of multiple values. Field types of single value are prefixed SF, while multiple value fields are prefixed MF. The following lists the field types in X3D:

SF field type MF field type Description
SFBool MFBool Specifies boolean value true or false
Specify color values in RGB and RGBA.
Specify numerical values in double, float and integer respectively.
SFImage MFImage Specifies an image
Specify 3x3 matrices of double and float values.
Specify 4x4 matrices of double and float values.
Specify 2-, 3-, 4-component vectors of double and float values
SFRotation MFRotation Specify rotation value i.e. direction vector of rotation and angle of rotation in radians
SFString MFString Specify text
SFTime MFTime Specify time
SFNode MFNode Specify other nodes as field value

Field access

Every field has an access type that determines how its value may be accessed. There are four access types. A field that has the accessType:

  • initializeOnly may have its value set only initialization. The set value cannot be changed after a field is created
  • outputOnly can be only be accessed to obtain their values. The values cannot be set
  • inputOnly can have its value set, but cannot be accessed to obtain its value
  • inputOutput can be accessed both to set and get its value

Routes and events

A field can be connected to another field by routing. The connection between fields forms a path for data transfer, where the receiving field is alerted of value changes of the sending field. These alerts are termed "events"; an event is a time-stamped value of the sending field. Suppose if field A is routed to field B. When the value of A changes an event is sent to B. When the value of B is requested it will be updated to the value of the event with the latest timestamp. There are two points to observe in the example. First, the value of B is updated with the value of A. Since fields are typed, fields that are connected must be of the same type for data transfer to work. Second, the value of B is not updated until it is requested. This model of updating changes only when they are necessary is termed lazy-evaluation, and is the default model adopted by H3D (this can be changed, and will be explained in the H3D section).

Routes and events can be used to create dependencies and animations in X3D.

X3D specifications

The X3D specifications detail the X3D framework, components, profiles, language bindings and file encodinngs. The X3D Abstract Specification contain details on the components that make up the X3D scene, all the nodes, fields, profiles and their functionality. Notice that up until now our brief discussion has focused on the concept rather than syntax of X3D. The X3D specifications focus on defining the scene graph behaviour and properties. The medium of implementation of these specifications is up the developer. When conformed to the X3D standard, the file encodings of X3D should function as specified across implementations.


H3DAPI is an implementation of X3D that also has an extension for haptics capabilities. These additional haptics properties can be defined in the scene just as how graphics and audio properties are defined in X3D scenes: by adding nodes and fields to same scene graph. The haptics capabilities require an underlying interface to the haptics renderer and device controls, nevertheless these are taken care of by H3DAPI, so the developer working with H3DAPI using X3D could program just as he does any other X3D programs. H3DAPI also implements Python scripting capabilities to work with X3D, that allow Python scripts to be added to, and manipulate objectss in the scene graph.

Node clasification in H3DAPI.
Node clasification in H3DAPI.

H3DAPI thus composes of X3D node classes specified in the X3D Abstract Specification and H3D-specific node classes, which are the additional nodes (mostly haptics related) found in H3DAPI, as shown in the diagram above. Abstract nodes comprise node templates from which other nodes derive from, and are not themselves added to the scene graph at runtime. The list of all scene graph nodes and their descriptions are found at the H3DAPI Doxygen documentation.

H3DAPI implements the combination of graphics, audio and haptics in one unified scene graph, written in C++. It uses OpenGL for graphics rendering and HAPI for haptics rendering. Instead of working with X3D and Python developers could also choose to work with H3DAPI using C++. Since H3DAPI is also open source, the developer has the freedom to not only use H3DAPI but also to extend or modify it to his needs.

So what is H3D?

H3D is the term that refers the entire package of H3DAPI, HAPI, and the toolkits that derive from these APIs.

Suggested readings




Personal tools
go to