The IGUANA architecture must know something about the objects it interacts with. More specifically, the application objects that are to be visualised must inherit from IgRepresentable and they must be described through the extended type information system. There is no need to implement any methods, these are outside the classes as described in the following how-to. However, we do not recommend inheriting the real application objects from our base class. Instead, you would normally use proxies so that visualisation does not alter the core application class design. You may use more than one proxy for the same object in different contexts. We often use proxies inheriting from IgTwig. However you do it, these are the basic steps:

• Select a packge or create a new one as explained in the guide to create a new package.
• Declare the proxy class.
• Define the proxy class.
• Add interface/xtypeinfo.h.
• Add src/plugin.cc
• Modify BuildFile

Define your proxy class as any other class. You must inherit from IgRepresentable, or if this is going to be a tree node in the hierarchical 3D visualisation controller, from IgTwig. IGUANA will create representations lazily on demand, and removes all representations when the object destructor runs. Typically object update browser methods (see rep mapping how-to) force the update of all other representations the object. Your class must update the representations using the IgRepSet methods if the object changes for any other reason. If your object is a proxy class, this may mean that you will have to design some additional services to listen for changes made elsewhere in the application.

Implement your class in a .cc file as usual.

Declare the extended type information as explained in the plug-in creation how-to.

Describe the extended type information as explained in the plug-in creation how-to. You do not need to define any plug-in properties.

Follow the instructions in the package creation how-to.