Computer Graphics Workshop '96 Lecture Notes
> (define viewer (new-SoXtExaminerViewer)) > (-> viewer 'show) > (-> viewer ;show)The third line causes the Scheme interpreter to hang, and "typing numbers" at it does not cause it to recover. The reason is that the semicolon causes everything until the end of the line to be ignored, so the interpreter is still waiting for the message (i.e. show) and the right parenthesis. The missing right parenthesis causes the interpreter to wait until it sees a right parenthesis.
> (chdir "/mit/thingworld/Ivy") #tchdir returns #t if the directory change was successful, #f otherwise.
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". However, if you forgot to ref your root node in the scene graph example from the first lecture, the scene would not appear. This happens because the rendering process applies an action to the scene graph; the root node's reference count would be incremented to 1 at the start of the rendering process, and then decremented to zero at the end. This would cause the root node to be deleted, and therefore all of its children (because their reference counts would be decremented to zero, as well).
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.
There are two main reasons for doing this:
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.
Some of the more important Sb types are as follows:
Most fields are containers for scene basic data types. This means that there are consistent interfaces to the elements stored within a field; for example, most Sb data types support the setValue and getValue methods for whatever data type they store.
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 creates a pointer to this object), because in Scheme all 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.
$Id: index.html,v 1.10 1996/01/10 18:12:10 kbrussel Exp $