Computer Graphics Workshop '97 Lecture Notes
In this lecture we will explore some of the reasons behind this organization to help you get a better feel for what the toolkit is capable of. We will also describe some of the other data types commonly used in Open Inventor, and how to use these data types from within Scheme.
All nodes are derived from the base type SoBase. This means they are specializations of this data type; a node can do everything an object of type SoBase could do, and more.
When a node is first created, its reference count is zero. The following manipulations increment a node's reference count by 1:
The following manipulations decrement a node's reference count by 1:
A node is deleted when its reference count is decremented to zero. This is why a newly created node does not immediately "disappear".
Most of the time, you will not have to worry about reference counts. Just make sure you ref your root node, and ref any node you want to keep around for a while. For example, let's say we define a new Ship data type in Scheme, which has an internal scene graph looking like this:
ship-root | ----------------------------- | | | Translation RotationXYZ (ship-geometry...)The translation and rotation nodes allow us to position each ship independently in the world; when we create a new ship, we add its scene graph to the global one. If we want to make several ships, we can re-use the same ship-geometry subgraph for each one. However, when a ship is destroyed, ship-root will be removed from the global scene graph, and all of the nodes below it will be unref'ed. Unless we explicitly ref'ed the root node of the ship-geometry subgraph, it would be deleted when the last ship was removed from the scene graph. (Note that this might be okay, depending on the design of your application; perhaps there is always at least one ship present.)
Warning: If you attempt to use a node which has been deleted, the Scheme interpreter will probably crash. Such severe errors are usually due to nodes being silently deleted by Inventor when you expect them to remain around.
There are three main reasons for doing this:
Let's look at a demonstration illustrating the second point. This code disables the automatic redraw mechanism (which unfortunately breaks the 3D manipulation functions) and replaces it with a nearly-equivalent one which prints a line every time the scene is re-rendered. When the material's diffuse color is changed, the scene is automatically redrawn.
There are two primary types of fields; single-valued and multiple-valued. A multiple-valued field, as the name implies, can store multiple values of a certain data type. Single-valued fields start with the prefix "SoSF"; multiple-values fields have the prefix "SoMF". For example, a field which could contain multiple floating point values is called an SoMFFloat. One which holds multiple (x,y,z) floating-point triplets is called an SoMFVec3f.
We will see an example of field-to-field connections and the use of engines in the second problem set, although we won't officially discuss engines until later.
Warning: you should never create a field which is not connected to a node (for example, by calling new-SoMFVec3f). If you want to store data outside of a node (like a list of coordinates), you should create multiple SbVec3fs (see below) and store them in a Scheme list or vector.
Sb data types usually have setValue and getValue methods. However, they do not have the notification mechanism (see the description of fields, above) which fields have. This means that when the setValue method is called on a basic data type, there is never any automatic propagation of that value anywhere else in the scene graph; that is, Sb data types are "simple" data types, while fields are containers for these data types. Nodes are field containers.
Some of the more important Sb types are as follows:
To start reading the manual pages, it is probably most convenient to start xman, a graphical utility for reading the manual. Type xman & at an Athena prompt to start it. If you are not using the standard Athena SGI setup, you will need to execute the following line in an xterm before typing xman:
The manual pages are under the (3) Subroutines (Inventor) section.
Let's look at the (abbreviated) man page for SbVec3f as an example. This basic data type encapsulates a vector of three floating point values.
The "synopsis" section is what we are concerned with. The first three lines of that section indicate that there are three ways of creating a new SbVec3f: one with no arguments, one with a Scheme vector of three floating point values, and one with three separate floating point values:
The next line indicates that the "right way" (there is another, but we're ignoring it for now) to get the values stored in an SbVec3f is by calling its getValue method. This method returns a Scheme vector of three floats, which can be deconstructed using the standard Scheme vector-ref function.
Let's define our new transform and try to access the translation field:
If we wanted to modify the contents of this node's translation field, therefore, we have to call the setValue method of this field:
We have already used this method extensively. The argument must be of type SoNode (that is, some specialization of the class, or subclass of, SoNode). You can ignore the "*" (which indicates a pointer to an object), because in Scheme all C pointers are handled by the interpreter.
Special cases for data types are as follows:
> (define my-vec (new-SbVec3f 1.0 2.0 3.0)) > (-> my-vec 'getValue) #(1.0 2.0 3.0) > (define my-vec (new-SbVec3f 1 2 3)) > (-> my-vec 'getValue) #(1.0 2.0 3.0)
More information about the Scheme interface to Inventor is located in the file
You should now be able to understand the general format of the manual pages for Open Inventor and be able to understand how to access at least the basic methods and fields from Scheme. The second problem set will involve using some of the unused fields from the first problem set to further modify your scene graph.
Some good Inventor Mentor examples to look at are 02.3.Trackball, 03.1.Molecule, 03.2.Robot, and 02.2.EngineSpin.
$Id: index.html,v 1.16 1997/01/08 19:29:24 kbrussel Exp $