imnodes: an immediate-mode node editor for dear imgui

What imnodes is for, and who it is not for

The README describes imnodes as "a small, dependency-free node editor extension for dear imgui". The word extension matters. This is not a standalone application, and it is not a graph framework with a data model. It draws nodes, pins and links inside an ImGui window and reports back the events it observed during the frame. Everything else, meaning what a node means, what a link carries, and what happens when a link is created, belongs to the caller.

That makes it a good fit for tools inside an existing C++ application: a shader graph, a material editor, a visual scripting panel, a build pipeline view. The topics listed on the repository are cpp, gamedev, imgui, node-editor, tool and ui, which matches that audience. If you are writing a browser-based editor, or you want a graph library that owns its own data structures and serialization, this is the wrong starting point, and the README does not pretend otherwise.

How the immediate-mode graph actually works

The mechanism follows dear imgui closely. You create a context once, then each frame you declare the editor, declare each node, declare each attribute inside it, and declare each link. Nothing is retained by the library between frames except its own internal bookkeeping for interaction. The README states plainly that "the user controls all the state".

Identification is by integer, not by name. The README explains why: node titles cannot be used because "it should be possible to have many nodes of the same name in the workspace". Nodes, attributes and links each need a unique integer id that you supply. In the README's link example, the array index of the link is reused as its identifier, which is a reasonable default but means link ids shift when you remove an element from the middle of the vector.

Attributes are the UI content of a node and carry the pins. Input pins sit on the left edge, output pins on the right, and the README notes that the library "doesn't really care what is in the attribute". You can put ordinary ImGui widgets between the Begin and End calls. The title bar is a separate pair of calls, and it has an ordering constraint: it must come before attributes or other widgets, because the node layout is built top to bottom in call order.

Events are polled after EndNodeEditor. IsLinkCreated fills two integers with the attribute ids at either end of a new link. IsNodeHovered reports the hovered node id. NumSelectedNodes and GetSelectedNodes handle multi-selection, which requires querying the count first and then allocating a buffer of that size. There is also a mini-map overlay, which the README says must be called right before EndNodeEditor, and which tracks panning between the overlay and the editor.

Getting imnodes into a build and drawing a first node

Distribution is deliberately manual. The README says to copy imnodes.h, imnodes_internal.h and imnodes.cpp into your project alongside ImGui. There is no package to install and no generated build step for the library itself. Note that imnodes_internal.h is part of that set, so a three-file copy is the documented path rather than a single header drop-in.

If you want to build the bundled examples instead, the README gives a CMake route that initializes the vcpkg submodule first. The same section warns that this "has not been tested on Linux and is likely to fail on the platform", so treat the example build as a Windows-oriented convenience. The two commands below initialize the submodule and then configure and build the examples in Release mode with the vcpkg toolchain file.

# Initialize the vcpkg submodule
git submodule update --init
# Run the generation step and build
cmake -B build-release/ -S . -DCMAKE_BUILD_TYPE=Release -DCMAKE_TOOLCHAIN_FILE=vcpkg/scripts/buildsystems/vcpkg.cmake
cmake --build build-release -- -j

After the build finishes, the example binaries land in the build-release directory. If the configure step fails on Linux, that is the platform limitation the README already flags, not a mistake in the commands.

A minimal editor: context, workspace, node, pin

The README walks through the same sequence in four steps. First, initialize the imnodes context next to the ImGui context, and destroy it in the same place you destroy ImGui. Second, open an ImGui window and bracket the editor with BeginNodeEditor and EndNodeEditor. At that point the README says you should see "a workspace with a grid visible in the window".

The third step is a node with a hardcoded integer id. The fourth is an output attribute, which renders a pin on the right side of the node and lets the user start dragging a link from it.

ImGui::CreateContext();
ImNodes::CreateContext();

// elsewhere in the code...
ImNodes::DestroyContext();
ImGui::DestroyContext();

ImNodes::BeginNode(hardcoded_node_id);

const int output_attr_id = 2;
ImNodes::BeginOutputAttribute(output_attr_id);
ImGui::Text("output pin");
ImNodes::EndOutputAttribute();

ImNodes::EndNode();

int start_attr, end_attr;
if (ImNodes::IsLinkCreated(&start_attr, &end_attr))
{
  links.push_back(std::make_pair(start_attr, end_attr));
}

The link check runs after EndNodeEditor. If it returns true, the README's example pushes the pair of attribute ids into a vector that the application owns, and on the next frame that vector is iterated to call ImNodes::Link for each entry. Nothing is stored inside imnodes, so if you forget to push the pair, the link disappears on the next frame.

The state model is the main limitation

Because the library retains no graph, every feature that depends on remembering something is yours to build. Serialization is the clearest case. The repository ships example/save_load.cpp, which indicates the maintainers consider saving and loading a thing you implement, not a service the library provides. The README does not document any built-in file format, undo stack, or copy-paste of node groups.

There is a second consequence that is easy to miss on a first read. Ids are integers you choose, and the README's link example derives them from vector indices. Delete a link from the middle of that vector and every later link changes id. If you persist links by their index-derived id, a reload after a deletion can attach links to the wrong pins. A stable id scheme is on you.

Layout is also call-order dependent. The README is explicit that BeginNodeTitleBar has to come before attributes, because the node is laid out top to bottom as you call. Insert a widget in the wrong place and the visual result changes silently.

Finally, the release history is thin. The most recent release listed is v0.5 from 2022-03-09, and the last push to the default branch was on 2026-05-13. The README also carries a build-status badge for GitHub Actions. None of that tells you how the library behaves under a workload you have not built yet, which is why the examples matter more here than they would for a project with a long changelog.

Alternatives and where the approach differs

The closest comparisons people search for are ImNodeFlow, Cimnodes, ImGuizmo and ImPlot, and the differences are structural rather than cosmetic. ImGuizmo is a set of manipulation gizmos for transforms, not a graph renderer; it solves a different problem in the same ImGui ecosystem. ImPlot draws plots and axes, again a different primitive. Neither is a substitute if what you need is pins and links.

ImNodeFlow and Cimnodes sit closer to imnodes in purpose, and the meaningful question to ask of each is who owns the graph. imnodes is explicit that the caller owns it. A library that stores nodes and links internally will save you the bookkeeping and the stable-id problem, at the cost of fitting your data model into its structures. If your application already has a scene graph, an asset database, or a compiler IR that the editor is a view onto, imnodes' split is the one that avoids duplicating state. If the editor is the primary data store, the internal-state approach removes a class of bug you would otherwise write yourself.

Licence, maintenance and upgrade cost

The repository is MIT licensed, with LICENSE.md at the top level. MIT is permissive: it allows use in closed-source products provided the copyright notice and permission notice are retained. That is a description of the licence text, not legal advice, and your own counsel should confirm how it interacts with your distribution model.

Upgrade cost is unusually low for a C++ library, and that is a direct result of the distribution model. There is no ABI to keep stable across a shared object, because you compile imnodes.cpp into your own target. Copying a newer imnodes.h, imnodes_internal.h and imnodes.cpp over the old ones is the whole upgrade. The risk sits in the API surface you use: the README documents PushColorStyle and PopColorStyle for per-node styling and GetStyle for global style, and the style array is indexed by ImNodesCol_* enumerators. Code that touches those enumerators or the style struct is the code most likely to need edits when you move to a newer revision. The README points to imnodes.h for the full set of UI event functions, which is the file to diff before you upgrade.

Editorial conclusion

Adopt imnodes if your application already renders its tools with dear imgui and you want a node graph to sit inside that same window without adding a second UI stack. Do not adopt it if you need a finished editor: there is no built-in serialization, no undo, and no node type registry, so every one of those is your code. Before committing, verify that the three-file copy-paste distribution matches your build layout, and check the example files under example/ to see whether the interaction model fits your graph.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Nelarius/imnodes on GitHub
4. README
5. Releases