imgui-godot: Dear ImGui inside Godot 4, and the export trap behind it

Two packages, and the difference is the native binary

The distribution splits into two downloads, and the split matters more than it first appears. If you only need C# support with basic features, the README points you at the `csharp-only` package. Everything else, including the GDExtension binaries, comes from the full package. So the plugin ships in two shapes: a managed-only path for C# projects that need nothing from the native side, and a full build that carries compiled GDExtension binaries for the other languages. The GDExtension route is what makes C++ and GDScript usage possible, since those languages cannot talk to ImGui.NET directly. The project is also listed in the Godot Asset Library, so the plugin can be installed without touching a releases page at all.

The bridge calls look exactly like plain ImGui code

Once the plugin is installed, using it takes a handful of lines in a Node's `_Process` method. In C# the calls are the familiar ImGui ones, because ImGui.NET provides them.

public partial class MyNode : Node
{
    public override void _Process(double delta)
    {
        ImGui.Begin("ImGui on Godot 4");
        ImGui.Text("hello world");
        ImGui.End();
    }
}

The GDScript route reads the same way, calling into the same window and text functions.

extends Node

func _process(delta):
    ImGui.Begin("My Window")
    ImGui.Text("hello from GDScript")
    ImGui.End()

That symmetry is the point of the plugin. The README states plainly that everything else is provided by ImGui itself through ImGui.NET, so the plugin is a transport and a lifecycle, not a second GUI framework you have to learn.

Signals exist because of Godot 4.1 process thread groups

There is a second entry point besides `_Process`, and it is not there for convenience. The plugin emits an `imgui_layout` signal, and you can connect to it and draw ImGui content inside the handler.

ImGuiGD.Connect(OnImGuiLayout);

The README calls this strongly recommended if you use process thread groups in Godot 4.1 or later, and the reasoning is about ordering rather than style. Drawing an immediate-mode interface inside a callback that the engine controls keeps the interface in step with the engine's own layout pass rather than depending on the order in which your nodes happen to process. The other API class, ImGuiGD, is described as the rest of the public API, with the note that you typically will not call those methods directly. The widget methods are restricted too: they should only be called within `_Process` or an `imgui_layout` callback, which is a real constraint if you were planning to draw from a button handler or a physics callback.

One constraint that silently breaks custom fonts and settings

Customisation goes through a resource rather than through code. To customise fonts or other settings you create an `ImGuiConfig` resource and then point at it from `Project > Project Settings > Addons > Imgui` by setting the `Config` resource path. Two widget helpers get their own notes. `Image` and `ImageButton` are described as simple wrappers for your convenience. `SubViewport` displays an interactive viewport that receives input events, and the README warns that you have to change the SubViewport's `Update Mode` to Always, because otherwise the viewport content is not refreshed and the interactive area goes stale. The font situation is worth understanding before you design around a particular typeface: the credits list the Hack font under the MIT license and the M PLUS 2 font under the SIL Open Font License 1.1, so those two are shipped with the project.

Exporting without ImGui is a separate problem with its own page

The README keeps this short and links out: the wiki page titled Export covers exporting without ImGui, such as for release builds or for mobile platforms. The existence of that page is the warning. A native plugin with a GDExtension binary is not something every export target can carry, and the interface built on top of it inherits that constraint. If you plan to ship a game to a platform where a bundled native extension will not run, the export configuration becomes part of your interface design rather than a packaging detail at the end. The repository keeps export presets in `export_presets.cfg` and two example projects, GdsGameProject and CSharpGameProject, which the README says try to demonstrate best practices particularly for setting up a typical project for export. Those two directories are the closest thing in the repository to a worked export recipe.

GodotEnv manages the addon folder for C# only setups

There is a package-manager path, and it is scoped. If you only need C# support with no GDExtension, the README says you can use GodotEnv to install and update imgui-godot, with a configuration that points at the addon folder.

{
  "addons": {
    "imgui-godot": {
      "url": "https://github.com/pkdawson/imgui-godot",
      "checkout": "6.x",
      "subfolder": "addons/imgui-godot"
    }
  }
}

The `checkout` key pins a branch line rather than a release tag, so the managed route tracks the repository rather than a published artefact. That is a reasonable trade for a C# only project that updates on a schedule you control, and a poor one for a team that wants reproducible builds, since a branch name is not a fixed point. The manual route stays available in both cases: copying the `addons` folder into the project and enabling the plugin under `Project > Project Settings > Plugins` works the same for the full package and for the csharp-only one.

Version alignment between ImGui.NET and the shipped binary

One line in the setup guide is marked IMPORTANT and is the most likely source of a confusing failure: if you are using the GDExtension, you must use a version of ImGui.NET which matches the version that the GDExtension was built with. Because the two halves of the plugin are separately versioned in practice, the managed assembly and the native binary can drift apart, and a mismatch shows up as a runtime problem rather than a compile error. The setup sequence itself is the standard Godot C# path. Create a project, and if you have not already added C# code, use `Project > Tools > C# > Create C# solution`. Copy over the `addons` folder, open the solution in Visual Studio or another IDE, allow unsafe code, install `ImGui.NET` with NuGet, and set the target framework to .NET 8 or later. Then click `Build` in the Godot editor and enable the plugin. If you prefer to edit the project file by hand, the README points at the demo csproj for the necessary modifications.

Where this plugin is the wrong choice

Three situations rule it out. First, a shipping player-facing interface: this is an immediate-mode debugging and tooling library, and the export story in the plugin's own wiki exists precisely because the interface does not belong in a mobile or release build by default. Second, a project that cannot take a native dependency, since the full package ships GDExtension binaries and the C# only path is described as covering basic features. Third, a team that wants a runtime-built editor for game UI, since Dear ImGui is drawn every frame into a framebuffer rather than composed of retained scene nodes, and the plugin does not change that model. Maintenance is worth noting separately. The newest release is v6.3.2 from 2025-04-26, preceded by v6.3.1 in February 2025 and v6.3.0 in October 2024, and the last push to the repository was on 2026-05-17, so the code has moved since the last tagged build. The licence field on the repository says MIT, and the credits record the code as written by Patrick Dawson and contributors under the MIT license.

Editorial conclusion

Use imgui-godot when you want a debug overlay or an in-game tool built with Dear ImGui inside Godot 4 and you already work in C# or GDScript, because the API surface you need is the ImGui.NET one you know and the plugin adds only the bridge. Do not plan to ship that interface to players: the wiki points to a separate export page for building without ImGui, which tells you the interface does not come along for free. Verify first that your ImGui.NET version matches the one the GDExtension was built with, that your target framework is .NET 8 or later, and whether the csharp-only package is enough for your needs before you take the full GDExtension build, since the last push to the repository was on 2026-05-17 and the newest release is v6.3.2 from 2025-04-26.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. pkdawson/imgui-godot on GitHub
4. README
5. Releases