SOBASEKIT(3iv)

SoBaseKit(3IV) — base class for all node kits 💅✨

NAME 💖

SoBaseKit — bestie, it's literally the base class for all node kits. 👑

INHERITS FROM 🧬

SoBase > SoFieldContainer > SoNode > SoBaseKit

SYNOPSIS 🎀

Okay so here's the whole vibe, exactly as it comes:

       #include <Inventor/nodekits/SoBaseKit.h>

          Parts from class SoBaseKit:

     (SoNodeKitListPart)  callbackList

          Methods from class SoBaseKit:

                              SoBaseKit()
     static const SoNodekitCatalog *
                              getClassNodekitCatalog() const
     virtual const SoNodekitCatalog *
                              getNodekitCatalog() const
     virtual SoNode *         getPart(const SbName &partName, SbBool
                                   makeIfNeeded)
     SbString                 getPartString(const SoBase *part)
     virtual SoNodeKitPath *  createPathToPart(const SbName &partName, SbBool
                                   makeIfNeeded, const SoPath *pathToExtend =
                                   NULL)
     virtual SbBool           setPart(const SbName &partName, SoNode *newPart)
     SbBool                   set(char *partName, char *parameters)
     SbBool                   set(char *nameValuePairs)
     static SbBool            isSearchingChildren()
     static void              setSearchingChildren(SbBool newVal)
     static SoType            getClassTypeId()

          Methods from class SoNode:

     void                setOverride(SbBool state)
     SbBool              isOverride() const
     SoNode *            copy(SbBool copyConnections = FALSE) const
     virtual SbBool      affectsState() const
     static SoNode *     getByName(const SbName &name)
     static int          getByName(const SbName &name, SoNodeList &list)

          Methods from class SoFieldContainer:

     void                setToDefaults()
     SbBool              hasDefaultValues() const
     SbBool              fieldsAreEqual(const SoFieldContainer *fc) const
     void                copyFieldValues(const SoFieldContainer *fc, SbBool
                              copyConnections = FALSE)
     void                get(SbString &fieldDataString)
     virtual int         getFields(SoFieldList &resultList) const
     virtual SoField *   getField(const SbName &fieldName) const
     SbBool              getFieldName(const SoField *field, SbName &fieldName)
                              const
     SbBool              isNotifyEnabled() const
     SbBool              enableNotify(SbBool flag)

          Methods from class SoBase:

     void                ref()
     void                unref() const
     void                unrefNoDelete() const
     void                touch()
     virtual SoType      getTypeId() const
     SbBool              isOfType(SoType type) const
     virtual void        setName(const SbName &name)
     virtual SbName      getName() const

          Macros from class SoBaseKit:

     SO_GET_PART(kit, partName, partClass)
     SO_CHECK_PART(kit, partName, partClass)

DESCRIPTION 🦋

Okay bestie, listen. This is the base class from which all nodekit nodes are derived. 🫶

Nodekits are like the ultimate group-chat for scene graph nodes — they give you a convenient mechanism for creating groups of scene graph nodes with some larger meaning. When you create a shape node such as an indexed face set, for example, you almost always precede it with a coordinate node. You may also want to add a transform node or specify properties with material, drawing style, material binding, etc. Instead of creating each of these nodes individually and then arranging them into a subgraph, you can use a nodekit of the appropriate type (in this case, SoShapeKit). ✨

Every class of nodekit has a nodekit catalog (SoNodekitCatalog) that describes the nodes in the subgraph, referred to as parts. The catalog has an entry for each part, with information such as the partName, partType, and nullByDefault (if FALSE the constructor creates it). The catalog also describes the arrangement of parts in the subgraph. (Other information is described below; a complete description is in the SoNodekitCatalog reference page.) 📚

If we regard the scene graph arrangement as a branching tree, then the top node (root) of the arrangement is always the nodekit itself. The leaf nodes are those at the bottom (containing no children). Some leaves of the tree are defined in the catalog to be public parts, while other leaves are private. All non-leaf parts are considered internal to the nodekit structure and are marked private. Public parts are accessible; they may be requested, changed, or set by the programmer with member functions such as getPart(). Private parts are not accessible, so methods such as getPart() will have no effect on them. For example, if you call getPart() to retrieve a private part, NULL will be returned even when the part exists. 💀

Every nodekit reference page has a Parts section describing the function of each public part it adds to those inherited from its parent class. Also, a Catalog Parts section has tables of often-needed information from the catalog (part type, etc.). These tables include all public parts, both new and inherited. Only the public parts of a nodekit are described in the reference pages. Nodekits take care of the rest for you; they automatically arrange the subgraph, creating and deleting the private parts when necessary. (The SoNodekitCatalog reference page has methods for finding out the part names and arrangement of all parts, both public and private.) 🧚

The nodekit catalog is a template shared by all instances of a class. They use the shared catalog as a guide when creating parts (i.e., constructing actual nodes), but each instance stores its own parts separately. Moreover, nodekits are not SoGroup nodes, and parts are added as hidden children; you can only access parts with the methods of SoBaseKit and its derived classes. 🙈

Any public part may be retrieved with getPart(), installed with setPart(), or removed by giving a NULL argument to setPart(). Paths from the nodekit down to a part can be created by createPathToPart(). 🛤️

By default, parts are not created until the user requests or sets them. This keeps the subgraph uncluttered and efficient for traversal. Additionally, removing a part (setting it to NULL) has the extra effect of removing any internal parts that are no longer needed. 🧹

Since nodekits hide their children, any SoPath containing nodekits will end at the topmost nodekit. However, since nodekits may be nested within other nodekits, you may wish to cast an (SoPath *) into an (SoNodeKitPath *). The methods of SoNodeKitPath allow you to view all nodekits that lie on the path (see the reference page for SoNodeKitPath). 👑

Public parts in the nodekit catalog fall into three categories:

1. regular nodes 🌟
2. nodekits, or nested nodekits (which may nest recursively). Any node which is public in a nested nodekit is accessible to the higher level nodekit(s) that contains it. The description of getPart() below shows how to refer to nested parts by name (e.g., "appearance.material"). This works for any nodekit method that takes a part name for an argument. 🪆
3. lists, or list parts. These parts group together children (list elements) of a particular type or types. As with nested nodekits, you can refer to individual elements using notation described in getPart() (e.g., "childList[0]", or if the list elements are in turn nodekits, "childList[2].transform"). 📝

When the catalog denotes that a part is a list, the part itself is always a node of type SoNodeKitListPart. The catalog specifies a set of permissible listItemTypes and a listContainerType for that part. It gives this information to the SoNodeKitListPart when it creates it. From then on, the list part will enforce type checking. So even if you retrieve the SoNodeKitListPart with getPart(), you will not be able to add illegal children. (See the SoNodeKitListPart reference page for more information). As an example, the callbackList part of SoBaseKit has an SoSeparator container and allows only SoCallback and SoEventCallback nodes in the list. Children may be added, retrieved, and removed from an SoNodeKitListPart node using methods that parallel those of SoGroup. However, type-checking is strictly enforced. 🚨

Note that, although all public parts are leaves in the nodekit catalog, you are free to add children to them (assuming that they are groups, nodekits, or list parts). A part's status as a leaf in the catalog just means that the nodekit will not manage the part's children. For example, SoWrapperKit has a part called contents with a part type of SoSeparator. You can put whatever you want underneath the separator, as long as contents itself is an SoSeparator. 🎁

Thus, a nodekit only controls a section of the scene graph. Above and below that section, anything goes. 🌈

However, when nodekits are nested, they effectively create a larger known' section of the scene graph. For example, the appearancepart of theSoSeparatorKitis a leaf node in theSoSeparatorKitcatalog. Butappearanceis in turn anSoAppearanceKit, containing parts such as materialanddrawStyle. The two nodekits combine to make an even larger template, which the SoSeparatorKitcan examine by looking at the catalogs for both classes. So anSoSeparatorKitcan successfully return a part named"material"; first it finds (or creates) the appearancepart, then it gets thematerialby callinggetPart()on theappearance`. 🔍

When the catalog defines the listItemTypes of a list part to be nodekits, the name-able space expands further. For example, SoSeparatorKit has a part childList which permits only SoSeparatorKits, so each list element can be further searched. Hence the name "childList[0].childList[1].childList[2].material" is perfectly legal. 🪄

PARTS 💖

• (SoNodeKitListPart) callbackList — This is the only part that the base class SoBaseKit creates. It is a public part that is inherited by all nodekits. It provides an easy way to add callbacks for a nodekit to use during action traversal (e.g. SoHandleEventAction). It is a list part and may contain numerous SoCallback and/or SoEventCallback nodes. 🎀

✨ METHODS ✨

• SoBaseKit() — the constructor, bestie. It makes the kit. 💅
• static const SoNodekitCatalog * getClassNodekitCatalog() const — hands you the SoNodekitCatalog for the class SoBaseKit itself.
• virtual const SoNodekitCatalog * getNodekitCatalog() const — hands you the SoNodekitCatalog for this specific instance of SoBaseKit. And okay here's the tea: every instance of a given class builds its own distinct set of parts (and those parts are real, actual nodes, no cap), but every single instance shares the same catalog — because the catalog just describes the parts. It's holding zero actual node pointers. It's giving reference document energy, not storage-unit energy. 📚
• virtual SoNode * getPart(const SbName &partName, SbBool makeIfNeeded) — this is the one you'll be calling constantly. It digs through the nodekit catalog (and the catalogs of all the nested nodekits, recursively, like it's scrolling way back in the group chat 🕵️) hunting for the part named partName.

You get a pointer back to that part if three things line up:

• a match was found,
• the part is public,
• and the part has already been built.

If there's no match, or the part is private, you get NULL. Sorry. 🙈

Now if partName IS in the catalog (or in the catalog of one of its nested nodekit parts) but the part just hasn't been built yet, then the argument makeIfNeeded decides what happens next:

• makeIfNeeded is FALSE → NULL is returned.
• makeIfNeeded is TRUE → getPart() goes ahead and creates the part (plus any necessary intermediary parts), slots it into the correct place, and returns a pointer to the freshly created part. Main character move. ✨

Elements of list parts AND parts inside nested nodekits can both be retrieved with getPart(). The full syntax for legal partName arguments is right here:

Part name BNF notation:

partName = singleName | compoundName

compoundName = singleName | compoundName.singleName

singleName = singlePartName | singleListElementName

singlePartName = the name of any single part in the catalog
(including those that are lists or nodekits), or in the recursively
nested catalogs of any of its parts.

singleListElementName = singleListName[index]

singleListName = the name of any single list-type part in the
catalog, or in the recursively nested catalogs of any of its parts.

index = integer

Examples of valid part names are:

"transform", "appearance.material", "childList[2].drawStyle", "foot",
"bird.leftLeg.foot", "octopus.leg[4].suctionCup[2].material"

• SbString getPartString(const SoBase *part) — you hand it a node, or a path to a node, and it checks whether that thing exists as a part in the nodekit, in a nested nodekit, or as an element of a list part. If yes: you get back a string describing the part name. If no: you get an empty string (""). It's giving "name that part" but make it bureaucratic. 🎀
• virtual SoNodeKitPath * createPathToPart(const SbName &partName, SbBool makeIfNeeded, const SoPath *pathToExtend = NULL) — returns a path that begins at this nodekit and ends at partName. The search for the part works exactly like it does in getPart(). You get NULL if partName can't be found, or if makeIfNeeded is FALSE and the part hasn't been built yet.

If the part IS retrieved and pathToExtend is NULL, the returned path starts at this and ends at partName. If pathToExtend is not NULL, then the path created is a copy of pathToExtend with entries appended all the way down to partName. And yes, it's totally fine for pathToExtend to go beyond the nodekit — any extra nodes get popped off the tail before it continues from this down to partName. Snipped. 💇‍♀️

• virtual SbBool setPart(const SbName &partName, SoNode *newPart) — inserts the given node (not a copy, okay, we're using the actual node) as the new part specified by partName. For the syntax of partName, go look at getPart(). This method adds whatever extra nodes are needed to fit the part into the nodekit's catalog. For example, if you call:

mySepKit->setPart("childList[0]", myNewChild);

then the kit may need to create the part childList before it can install myNewChild. Run-time type checking verifies that the node type of newPart matches the type called for by partName. For example, if partName was a material for an SoSeparatorKit, but newPart was an SoTransform node, then the node would not be installed, and FALSE would be returned. Type mismatch? Denied. 💀

If newPart is NULL, then the node specified by partName is removed. And if that renders any private parts useless (which is what happens when you remove the last child of an SoGroup node), those get removed too. So nodekits never keep unnecessary nodes lying around — they are the opposite of a hoarder. 🧹

TRUE is returned on success, and FALSE upon error.

• SbBool set(char *partName, char *parameters)
• SbBool set(char *nameValuePairs)

These functions let you set field values of parts (nodes). If you use partName and parameters, then a single part is specified by partName and the field values are specified in parameters. The format of parameters is the Inventor File Format syntax. For example:

mySepKit->set("material", "diffuseColor 1 0 0 shininess 0.6");

sets the part material to the values "diffuseColor 1 0 0 shininess 0.6". The values used in parameters must of course be appropriate for the node-type that partName belongs to. In this case, the nodekit SoSeparatorKit has a part named material which is of type SoMaterial.

The nameValuePairs syntax can be used to set the field values in several different parts at the same time. In this case, the argument string nameValuePairs contains name-value pairs: "partName1 { parameters1 } ... partNameN { parametersN }".

For example:

mySepKit->set("material { diffuseColor 1 1 1 }
            transform { translation 4 3 .6 }");
mySepKit->set("childList[0].material { ambientColor .5 .5 .5 }");

• static SbBool isSearchingChildren()
• static void setSearchingChildren(SbBool newVal)

These set and query whether nodekit children get searched during SoSearchAction traversal. And the default? They do not get searched. 🚫🔍

• static SoType getClassTypeId() — returns the type identifier for this class. Iconic. 👑

---

🎀 MACROS 🎀

• SO_GET_PART(kit, partName, partClass) — calls getPart() with makeIfNeeded set to TRUE, then casts the result to the type partClass. Heads up though: in the debug library, this macro checks whether the part is actually of type partClass, while the regular library does no type checking. So like, the debug build is your friend who double-checks your outfit before you leave the house. 💖
• SO_CHECK_PART(kit, partName, partClass) — calls getPart(), but with makeIfNeeded set to FALSE, then casts the result to the type partClass. Same deal: in the debug library this macro checks if the part is of type partClass, while the regular library does no type checking.

---

🌈 ACTION BEHAVIOR 🌈

• SoGLRenderAction, SoCallbackAction, SoGetBoundingBoxAction, SoHandleEventAction — behaves like an SoGroup. Traverses each child in order. Simple, clean, does the job. ✨
• SoRayPickAction — traverses each child in order. Then, for any pick containing the kit on its path, it makes an SoNodeKitDetail like this:
  • Sets the "detailNodeKit" (retrievable with SoNodeKitDetail::getNodeKit()) to be a pointer to itself.
  • Sets the "detailPart" (retrievable with SoNodeKitDetail::getPart()) to be a pointer to the kit's leaf-most part that lies on the pickPath.
  • Sets the "detailPartName" (retrievable with SoNodeKitDetail::getPartName()) to be the part name of that part, as found in the catalog.

It does not descend into nested nodekits. Each nodekit along the path is the "detailPart" in its parent's detail. However — plot twist 🌀 — if the pick path goes through a list part, a pointer to the child is used for the "detailPart", and "detailPartName" is of the form "listName[i]".

• SoGetMatrixAction — behaves like an SoGroup. Does nothing unless the kit is in the middle of the path chain the action is being applied to. If it is, then the children up to and including the next node in the chain get traversed. Situational. We love a method with boundaries. 💅
• SoSearchAction — first, searches itself like an SoNode. Then it checks the value of isSearchingChildren(). If TRUE, it traverses the children in order. If FALSE, it returns. That's it, that's the whole thing. 🦋
• SoWriteAction — begins by writing out the regular fields, then writes out the parts. And here's the key thing: a nodekit does not write out its parts the way an SoGroup writes out its children. Instead, it writes each part as an SoSFNode field. First the part name is written, then the node being used for that part. ✍️

To keep the files terse, nodekits write out as few parts as possible. However — nodekits always write a part if another instance or a path is writing it. If that's not the case, parts get left out according to the following rules:

• [1] NULL parts only write if the catalog states they are created by default.
• [2] Empty SoGroup and SoSeparator nodes do not write.
• [3] Non-leaf parts only write if they have non-default field values.
• [4] List parts only write if they have children or if the container node has non-default field values.
• [5] Nested nodekit parts only write if they need to write one or more parts, or if they have non-default field values.

---

🫶 CATALOG PARTS 🫶

All parts — here's every part in the catalog, laid out for you bestie:

• Part Name: callbackList
• Part Type: NodeKitListPart
• Default Type: --
• NULL by Default: yes

Extra information for list parts from the table above 📋:

• Part Name: callbackList
• Container Type: Separator
• Permissible Types: Callback, EventCallback

---

🍓 FILE FORMAT/DEFAULTS 🍓

BaseKit {
   callbackList  NULL
}

---

💜 SEE ALSO 💜

SoAppearanceKit, SoCameraKit, SoLightKit, SoNodeKit, SoNodeKitDetail, SoNodeKitListPart, SoNodeKitPath, SoNodekitCatalog, SoSceneKit, SoSeparatorKit, SoShapeKit, SoWrapperKit

---

And that's the whole page, bestie — that's SoBaseKit(3IV) from the Inventor crew, fully read, no skimming, no skipping. 🎀 Go build some kits and go off. 💖✨🌸