If it weren't for extensibility, all actions could have been implemented simply as virtual functions on nodes. For example, GL rendering could have been a virtual function on the SoNode^{( C++ | Java | .NET )} class. Adding a new node class would require implementing virtual functions for those actions that could not be inherited from the base class.

However, adding a new action would be considerably harder. It is impossible for you to add a new virtual function to the SoNode^{( C++ | Java | .NET )} class or to any of the existing Inventor node classes. The only way to add a new action would be to derive classes from all nodes that would support it and to define the new method for those classes.

Figure 1.1.  Summary of SoEXTENDER Classes

Inventor implements actions as separate classes to solve this problem. Each action maintains a list of static methods, one for each node class (see Figure 1.2, “ Method List ”). When an action is applied to the root of a scene graph, Inventor uses the method list to look up the method for each node in the scene graph, based on the type identifier for the node class. See Section 1.5, “Runtime Types” for more information on class type identifiers.

Figure 1.2.  Method List

For convenience, the base SoNode^{( C++ | Java | .NET )} class registers static methods for all built-in Inventor actions; each of these methods calls a corresponding virtual function for that action. For example, SoNode^{( C++ | Java | .NET )} registers a static method for SoGetBoundingBoxAction^{( C++ | Java | .NET )} that calls the virtual getBoundingBox() method. All classes derived from SoNode^{( C++ | Java | .NET )} can redefine getBoundingBox() in standard object-oriented fashion. If a class does not redefine a method, it inherits the method from its parent class

Most of the virtual methods on SoNode^{( C++ | Java | .NET )} do nothing and must be redefined by the individual node classes. A few, however, such as the SoNode^{( C++ | Java | .NET )} virtual methods for search() and write() , actually implement the action, since most nodes perform the action in the same way. In most cases, nodes can simply inherit these methods without redefining them.

Details on how to add a new node class are given in Chapter 2. Adding a new field class is described in Chapter 3.

If you add a new action class to Inventor, you need to set up the list of methods for the nodes that support the action (shown in Figure 1.2, “ Method List ”). This list contains one pointer to the static action method for each node class that supports the action. Adding a new action is described in Chapter 4.