ImGuizmo: 3D transform gizmos for Dear ImGui applications

What CedricGuillemet/ImGuizmo actually provides

Dear ImGui gives you immediate mode controls: buttons, sliders, text fields. It has no concept of a 3D object, a transform, or a viewport. ImGuizmo fills that gap. The core widget takes a 4x4 float matrix and renders interactive handles on top of it, so a user can drag an object through world or local space without you writing picking code, axis constraints or drag math yourself.

The README describes the project as "a collection of Dear ImGui widgets for 3D manipulation and more", and the repository layout backs that up. The src/ directory holds several standalone .h/.cpp pairs, and the README states each widget "can be used independently". The set includes ImGuizmo itself (the transform gizmo), ImViewGizmo for view orientation, ImSequencer for frame range timelines, GraphEditor for node graphs with a delegate system, ImVectorEditor for 2D path geometry, plus ImCurveEdit and ImGradient, which appear in the Makefile object list even though the README does not give them their own subsections.

The audience is narrow and specific: C++ developers building in-house level editors, animation tools, CAD front ends or debug overlays who have already chosen Dear ImGui for their UI and now need object manipulation inside a 3D viewport. If you are writing a game with no editor, or a tool in C# or Python, this library is not aimed at you.

How the transform gizmo handles matrices and coordinate space

The mechanism is immediate mode throughout. There is no retained scene graph, no object registry, no callback registration. On each frame you call the manipulation function and pass it the current matrix, the camera's view and projection matrices, the operation mode (translate, rotate or scale) and the coordinate space (world or local). The function draws the handles and, if the user is dragging, writes the modified matrix back into the one you passed. Your own data structure remains the single source of truth, which is consistent with how the rest of Dear ImGui works.

Because the library only touches a 4x4 float matrix, it does not care what that matrix represents. It can be an object transform, a camera, a light, or a bone in a skeleton. The README's emphasis on "no additional dependencies" matters here: the library does not pull in a math library, so it works with whatever matrix convention your engine already uses, as long as you hand it the data in the expected layout.

The repository's Makefile shows the intended build shape. The library objects are src/ImGuizmo.o, src/GraphEditor.o, src/ImCurveEdit.o, src/ImGradient.o and src/ImSequencer.o, compiled with CXXFLAGS set to -std=c++11. The example objects are compiled separately, with example/main.o overriding CXXFLAGS to -std=c++17. That split is worth noticing: the widgets themselves target C++11, while the demo application needs C++17. If your project is pinned to an older standard, the library is the safer half to depend on.

Installing ImGuizmo with vcpkg and building the example

The README gives exactly one installation path, and it is vcpkg. The command is a single line, and the README points to the vcpkg-example/ directory for details.

vcpkg install imguizmo

After that command completes, the port places the headers and the compiled library in your vcpkg installation, and the vcpkg-example/ directory shows how a consumer project links against it. The README does not list a package for any other package manager, so if you do not use vcpkg you are expected to copy the .h/.cpp pairs from src/ into your own build, which the README explicitly allows since each widget is standalone.

For a first real use, the repository ships a full working application rather than a snippet. The example/ directory contains main.cpp, ImApp.h and its own CMakeLists.txt, and the top-level Makefile builds it. On a Windows toolchain the Makefile links -limm32 -lopengl32 -lgdi32 and produces example.exe, so the demo renders through OpenGL with the Win32 backend.

make

Running that target compiles the library objects and the example objects and links example.exe. What you should see is a window containing the ImGuizmo demo scene, with a manipulable object and the widget panels the README illustrates in images/sample.png. For a non-Windows build, the example/CMakeLists.txt is the entry point, and the README's build badges cover Windows MSVC, Linux GCC, Linux Clang and macOS Apple Clang, so the CI matrix confirms those four configurations are exercised.

Where ImGuizmo stops and your own code has to start

The most common wrong expectation is that ImGuizmo is an editor. It is not. The README never claims selection, undo, serialization or hierarchy management, and none of those appear in the widget list. You get the handles and the matrix write-back. Everything around that, including which object is selected, how the selection is stored, how a drag is undone, and how the result is saved to disk, is your responsibility.

The second limitation is coupling to Dear ImGui's frame loop. Because the widget draws and mutates state during the frame, it assumes the ImGui context is live and that you call it at the right point in your rendering order. If you are embedding this in a renderer that batches UI separately from scene drawing, or one that runs ImGui on a different thread, you have integration work to do that the README does not address.

A third point is documentation depth. The README routes API questions to docs/documentation.md and says "For API reference and usage examples, see the documentation", which means the README itself is a widget catalogue, not a reference. The README also does not document rollback behaviour, error handling, or what happens if you pass degenerate matrices. If your use case depends on any of those, plan to read the source in src/ rather than the prose.

ImGuizmo versus ImNodes and other node graph options

Several of the related searches pair ImGuizmo with Imnodes, which is reasonable because both are Dear ImGui extensions, but they solve different problems. Imnodes is a dedicated node graph library. ImGuizmo's GraphEditor widget, described in the README as "a node graph editor with connections and a delegate system for custom rendering inside nodes", covers the same territory from inside this repository.

The difference in approach is packaging. Choosing GraphEditor means one dependency, one build, and node rendering that shares the same source tree as your gizmos and sequencer. Choosing a separate node library means two dependencies to track and two release cadences to reconcile, but a component that is developed around node graphs specifically rather than as one widget among several. The README does not compare the two, and it does not document GraphEditor's feature boundaries beyond the delegate system, so the honest position is that this is a judgement call you make by reading src/GraphEditor.h.

The same logic applies to the sequencer. If all you need is frame range editing, ImSequencer is a small, self-contained answer. If you need a general timeline with keyframe interpolation and curve editing, ImSequencer plus ImCurveEdit is the combination this repository offers, and the README's one-line description of ImSequencer as "a timeline sequencer for editing frame start/end ranges across multiple events" sets the expectation deliberately low.

Licence, maintenance and the cost of tracking upstream

ImGuizmo is MIT licensed, and the README states this plainly with a pointer to the LICENSE file. For most commercial and open source projects that is the permissive end of the spectrum, but the usual caveat applies: MIT requires that the copyright notice and permission notice travel with the source or binary distribution. Vendoring the .h/.cpp pairs into your tree, which the standalone-widget design encourages, means those files and their notices become part of your repository. This is a description of the licence text, not legal advice; read LICENSE yourself.

The repository is not archived, and the last push was on 2026-08-08. Two releases landed in 2026: ImGuizmo 1.10 on 2026-05-11 and ImGuizmo 1.9 on 2026-05-02. Before those, the previous release was v1.83 on 2021-07-20, so the release history is not uniform. The upgrade cost depends on which consumption path you take. If you use vcpkg, upgrades arrive when the port is updated, and you are insulated from API churn but also delayed by it. If you vendor the source, you control the version and you also own the merge.

There is no versioning statement in the README, no changelog referenced, and no deprecation policy. The practical consequence is that a vendored copy can drift silently. Pinning to a commit hash and recording it is the only reliable way to know what you are running.

Editorial conclusion

Adopt ImGuizmo if you already render a Dear ImGui interface in C++ and need to edit 4x4 matrices directly inside it, and you are willing to vendor the .h/.cpp pairs or take the CMake static library. Do not adopt it if you need a full scene editor with undo history, selection management or a serialization format; ImGuizmo is a widget layer, not an application framework. Before committing, verify that the widget you actually need is in the repository rather than only in the documentation, check the C++ standard your toolchain uses against the -std=c++11 and -std=c++17 split in the Makefile, and confirm whether the vcpkg port tracks the 1.10 release.

Frequently asked questions

Official sources

1. CedricGuillemet/ImGuizmo on GitHub
2. Issues
3. License: MIT
4. README
5. Releases