nodekits(3)

💖 NAME 💖

nodekits — bestie, this is the NodeKit Classes page ✨ (it's nodekits(3), third section, Library Functions, iykyk 💅).

✨ SYNOPSIS ✨

🎀 Classes 🎀

• class SoAppearanceKit — the node kit catalog that collects all the miscellaneous appearance node types together. 🎨
• class SoBaseKit — the toplevel superclass for nodekits. 👑 everything else is giving descendant energy.
• class SoCameraKit — a node kit with a transform and a camera. 📷 iconic combo, no notes.
• class SoInteractionKit — the base class for draggers. 🖱️
• class SoLightKit — provides a kit with a transform, a light and a shape or subgraph. 💡
• class SoNodeKit — the class used to initialize the nodekit classes. 🧚
• class SoNodeKitListPart — a container node. 📦
• class SoNodeKitPath — a path that contains only nodekit nodes. 🛤️
• class SoNodekitCatalog — a container for nodekit layouts. 🗂️
• class SoSceneKit — collects the node kits you need to set up a scene: camera, light and shapes. 🌈
• class SoSeparatorKit — provides a typical set of nodes to influence a shape subgraph. 🫶
• class SoShapeKit — provides templates to insert what is usually needed for shape nodes. 🔺
• class SoWrapperKit — a simple kit for wrapping a transform and a sub-graph. 🎁

📖 Detailed Description 📖

Okay so, real talk: wrapping your head around when, how and why to create nodekits can be lowkey difficult at the beginning. 😭 Like, when do you write a nodekit, and when do you write a custom node? It's so easy to think in those terms when you're starting out, but fr fr, it's often not an either/or situation.

The whole concept of nodekits is to modularize the useful, potentially repeated sub-structures you've got in your scene graph once it approaches some level of complexity. They're especially useful if you might need to rearrange the structure of that sub-structure in the future — and bestie, you probably will. 💀

On file, a nodekit is basically a macro for the scene graph. The nodekit will not expose its internal structure, but when it's read in it will create the node structure internally. And the node structure can even have optional parts that only get expanded if necessary. ✨

A nodekit gives you access to its "slots" in the internal structure through its fields. And only those fields should be the user interface for the nodekit — the rest of the substructure should be completely automatic, derived from those slot fields. Periodt. 💅

So back to that custom node vs nodekit question: the answer is to think about what exactly is really custom about what you need to implement, and trim that down to the atomic level. (But please stop trimming before you trim away all meaning, okay?? 🙈) If there is nothing really custom in what you want to implement, then it's likely that implementing it as a nodekit is what you ought to do. However — if you do have to do something custom that Coin doesn't support, then implement that part as a custom node, and then, if it seems worthwhile, implement the nodekit you need to bundle up this custom part with an auxiliary support structure to achieve what you set out to achieve. 🌸

And for VRML97, you've got something called PROTOs, which is something similar to nodekits — except they are not very accessible from C++, as opposed to nodekits. 😬

👑 Author 👑

Generated automatically by Doxygen for Coin from the source code. 🤖 (not a human, just a very hardworking little tool)

💖 that's the whole vibe check, bestie. this page came to you from Coin, Version 3.1.3, and it's the nodekits(3) manual page. slay, stay modular, and go build something iconic 🦋✨🎀