Developing for Nodos

Extending Nodos: plugins and subsystems that add node types, and external applications that join a graph over the network.

Start with the basics

These pages assume you can install Nodos and build a working graph. If you have not done that yet, go through Using Nodos first — in particular Your first graph, which introduces the scheduling model your nodes will run inside.

There are three ways to extend Nodos, and picking the right one matters more than anything else here. Extension model covers the choice; the short version is that a plugin is the default, and an application is what you use when the code cannot live in the engine process.

Tutorials

• Your first plugin — scaffold a plugin, define a node, implement it in C++, build it, and load it into the editor. Ends with your own node in the right-click menu. About 30 minutes, needs a C++ toolchain.

How-to guides

• Add nodes and pins — extend an existing plugin with more node classes.
• Depend on another module — declare, resolve and import another module's API.
• Write a shader-only node — a GPU node with no C++ at all.
• Use the Vulkan subsystem — record GPU commands from a C++ node.
• Connect an external application — make a separate process appear as a node using the Application SDK.
• Publish a package — push a module to the Nodos Store, publicly or privately.
• Migrate a plugin to 1.4 — move an older plugin onto the current manifest and build model.

Reference

• Plugin manifest — the .nosplugin file.
• Node definition — the .nosnode file: pins, visualizers, functions, presets.
• Plugin API (C++) — NodeContext callbacks, entry point macros, engine services.
• Node lifecycle and callbacks — which callbacks the engine calls, in what order, on which thread.
• Application SDK — the out-of-process integration API.
• Built-in data types — the types available to pins.
• Workspace layout — where modules, SDKs and generated projects live.
• Subsystems — including nos.sys.vulkan.

The nodos CLI reference documents the authoring commands (create, node, depend), the build commands (dev gen, dev build, test) and the store commands (publish, auth) alongside the rest.

Explanation

• Extension model — plugins, subsystems and applications, and how to choose between them.
• Objects and the type system — why pin data is FlatBuffers, what an object reference is, and how resources stay alive.
• Versioning and SDK lines — engine, SDK and package versions are three different things; which one has to change, and when.

Scheduling and execution is filed under Using Nodos, but it is required reading before you write ExecuteNode — it covers when your node is called, and why that is not the same as when its inputs change.

Conventions

• C++ constants are SCREAMING_SNAKE_CASE, not kCamelCase.
• Use nos::ObjectRef / nos::TypedObjectRef rather than raw nosObjectId or C resource structs.
• Adding a node means three things agreeing: the .nosnode class_name, the string passed to NOS_BIND_NODE_CLASS, and the NOS_NODE(...) entry. A mismatch is the usual reason a node does not appear.

Contributing to the modules that ship with Nodos: Contributing.