Converging toward a principal Unreal Engine backend/binding for Dear ImGui?

[ocornut]

EDIT 2026-01-12: See @sammyfreg WIP survey in this post: #9122 (comment)

---

Too many bindings

There is a list of Unreal Engine binding at:
https://github.com/ocornut/imgui/wiki/Bindings#unreal-engine

As of the time of writing this post, the list looks like this:

• UnrealImGui:
  - original: https://github.com/segross/UnrealImGui (2017-2021)
  - fork: https://github.com/benui-dev/UnrealImGui (2022-2023)
  - fork: https://github.com/IDI-Systems/UnrealImGui (2022-2025)
  - alt: https://github.com/sleeptightAnsiC/ImGui-for-Blueprints (2022)
• VesCodes/ImGui (2023-2025) (w/ docking and multi-viewports) https://github.com/VesCodes/ImGui
• Cog (2023-2025) (w/ many ready to use tools): https://github.com/arnaud-jamin/Cog
• UnrealImGuiDocker (2023) (w/ docking and multi-viewports): https://github.com/Sharundaar/UnrealImGuiDocker
• amuTBKT/ImGuiPlugin (2025) (w/ docking and ImPlot etc.) https://github.com/amuTBKT/ImGuiPlugin
• UnrealEngine_ImGui (2017): https://github.com/sronsse/UnrealEngine_ImGui
• UnrealNetImgui (plugin for NetImgui, 2020-2024): https://github.com/sammyfreg/UnrealNetImgui
• Also see: Useful Extensions: Unreal Engine specific for: Cog, PropertyWatcher, UnrealImGuiTools etc.

If you know some missing let me know.

Honestly it is quite a problem that the list is so large. It makes it difficult for users to pick a binding, it makes it difficult for the community to support one, or for me to provide feedback to one. I've talked to dozen of studios using Dear ImGui over Unreal Engine, there is a clear trend of this happening, and I've heard frustration about small hiccups on bindings.

What Epic is doing and not doing

My sincere hope was that Epic would eventually show up and develop+maintain a binding that ticked all the boxes, make it a external / opt-in plugin and let users bring their own version Dear ImGui to it. But nope, they decided to ignore it and develop their own IMGUI API over Slate. I'm obviously not against competing technology, and it's great there's work on this topic, but the ratio of effort and their published reasoning seems a bit off.

Watch from 7:00 onward:

Creating Debug Tools with SlateIM | Unreal Fest Stockholm 2025
https://youtu.be/zilYOy1w2b0?si=-PnHZszoQtE3nr3T&t=420

• On maintenance: certainly it would be a drop in the ocean for them to develop and maintain a Dear ImGui bindings, certainly much lower maintenance that them developing a new API. It would solve the immediate issues that their users have. They wouldn't need to take responsibility of much, certainly not of providing Dear ImGui itself IMHO (best to allow users to bring their code drop). Generally they would take less responsibility allowing people to self organize and keep using what they already use.
• On consistency: I'm not sure if they tried to use matching font and colors but it would go half of the way. The purpose of Dear ImGui especially when above UE is to quickly develop debug tooling that will also work on target. If you try to 1:1 match with an existing toolkit it would come with a cost, and as a writer of tools you end up carrying extra arbitrary weight. I imagine they overlooked Dear ImGui as somehow clunky, which it is sort of, but for a good reason. Consistency is nice but if you start making efficiency/usage trade-offs in the name of visual consistency you are missing out on something. Bizarrely their current version of the poster-child code (in video above) doesn't show how to have aligned labels, which is an odd showcase for consistency.
• On tab management, easy windowing: that could be developed as part of a binding.

Other thoughts:

• For a third party studio, using Dear ImGui mean they can more likely share tools and tooling code with offline tools not developed inside UE.
• There are already tools build over Dear ImGui over UE, such as Property Watcher or Cog, or NetImGui for Unreal

Epic are currently asking some studios to evaluate SlateIM. Some private feedback I got suggested it seems impossible for many at this point to switch to SlateIM because of (1) too many lacking features and (2) code already written using Dear ImGui. Obviously SlateIM will likely improve over time (it was first pushed in UE in January 2025 and is now being promoted) and is likely to attract new users.

Regardless of how SlateIM evolves, my job today is sort of to ensure that Dear ImGui users can access the best backend for their platform of choices. It's perfectly fine if both cohabit and I see no reason to wait until they decide to better support Dear ImGui.

My prediction is that there is a possibility that in some time (e.g. a year or so) they observe adoption on AAA again and decide it is worth developing a Dear ImGui plugin to support their users, but we'll see.

Proposal

I think as a community we should aim to converge toward one principal supported plugin for Enreal Engine.

IMHO the first step would be:

• Help me update the list above if anything is missing.
• Help making a thorough comparison of all existing solutions.
• As an immediate step, if this comparison is widely publicized that would help users choose.
• If you or your team are users Dear ImGui on Unreal Engine, consider writing some feedback on this thread about what you are using, your wishes, problems, thoughts on this, etc.
• Please share this link to interested users.

Some ideas for criteria to compare backends, and to aim for an "ideal" backend:

• How simple the code/repo is.
• How simple it is to install/configure.
• Does it work on all targets.
• Does the integration creates constraints on how to use/access Dear ImGui? If so, which ones? (Compare to typical C++ app, where you can call ImGui::Begin() in the middle of a random callstack to create controls to edit local variables that are on the stack. There are many flexible ways to use the API and we want to ensure a binding doesn't restraint it excessively.
• What UE version are supported?
• What features are supported?
  • Clipboard.
  • Seamless Multi-viewports.
  • Docking
  • Embed popular extension such as ImPlot.
  • Gamepad controls
  • Cursor shapes
• Does it manages to integrate well with UE systems, e.g. dock imgui windows into slate container?

Based on this knowledge, we can try to get developers to gather and see if efforts could converge.

I don't have much resources to put into implementing UE adjacent code myself, but I could provide feedback and given that there is industry needs, if a good idea emerge I could be able to find financial support for longer maintenance.

I only very rarely do that, but I'm going to tag people who could be interested in this discussion: @segross @benui-dev @IDI-Systems @sleeptightAnsiC @VesCodes @Sharundaar @amuTBKT @sammyfreg @arnaud-jamin @guitarfreak @nakdeyes. Sorry for the spam 🙇

Random bonus pictures of stuff over Unreal:

[sammyfreg]

During the holidays, I will help wirte up a first pass of a comparison table of the various plugins mentionned above.

[VesCodes]

I'm still relatively actively maintaining VesCodes/ImGui and plan to continue doing so for the foreseeable future. Had some great feedback from multiple studios about its simplicity which makes it easy to modify (and maintain on my part). There's some outstanding issues that I'm slowly working to address and people have pitched in with various fixes which is great! There's a Dev branch with support for the new texture API from v1.92 that's not been merged since NetImGui still doesn't support it - I'm considering replacing that with a custom solution if I find the time to do so.

Apart from the segross binding (and descendants) which led me to write my own due to quirks/limitations, I've not assessed the others so can't really speak for their state. But my aim is for VesCodes/ImGui to be as fully featured as possible - to that end it supports docking and viewports from Dear ImGui's perspective, and on the UE side it supports pretty much all contexts - editor, play-in-editor, game/client, server, and standalone programs. To my knowledge, no other binding provided this feature set around the time I started.

I watched that SlateIM presentation recently and was also kind of confused about their reasoning behind not adopting ImGui, but it is what it is. I think they can very comfortably live alongside each other in a project, and can see the value in SlateIM - just depends on how much investment it gets, both from Epic and licensees.

[VesCodes]

@ocornut believe I've mentioned it a couple times on Twitter, but merging the string view branch into main/docking would be hugely beneficial for a UE binding as we can excise all of the TCHAR -> ANSI/UTF8 conversions required in usage code at the moment.

[sammyfreg]

@VesCodes In regarde to 1.92 support for NetImgui, it is coming :)
I have it working locally and need to finish finding all outstanding issues and cleanup the code. This is my #1 holidays project.

[SK83RJOSH]

@VesCodes somewhat tangential, but my main gripe with UnrealImGui and it's forks is that their input handling is rather broken and they don't participate in Slate hit testing at all.

Are these things you've solved/plan to solve? If so, I'd be in moving our studio over in the future and assisting with maintenance in the long term.

Commenting here since both relate to Omar's "does it integrate well with existing systems" point – feel free to fold this comment if it feels offtopic.

[sleeptightAnsiC]

@ocornut

• alt: https://github.com/sleeptightAnsiC/ImGui-for-Blueprints (2022)

You can ignore this one entirely. It was a small experiment of mine and I'm not so proud of it. I archived it as soon as I noticed that it was gaining stars. The idea of calling ImGui API from BPs may work, but bindings for this should be automatically generated, and the interface would need at least few custom nodes (UK2Node) to ensure safety.

EDIT: Since I have nothing to add here, I'm unsubscribing the thread, however, feel free to tag me.

[Allar]

I've used VesCodes in production, but I've had to manually upgrade it to a newer ImGui version which required some changes to how textures get loaded so things run smoothly. The docking branch is very useful. The context system that VesCodes offers is extendable into some pretty cursed setups, I have videos of showing how I extended ImGui into UMG and I can define ImGui widgets via blueprint and UMG and animate them using sequencer.

I probably won't invest in customizing SlateIM ever, because I have more than a decade of experience of working with Epic tech and it changing over time. That is to say, if SlateIM fits the usecase I'd use it, but the second you need some advanced features outside it, ImGui is very attractive.

I reimplement the Unreal side of ImGui based off of @VesCodes 9/10 times. I've tried some other forks but this gets me to where I want the fastest.

Not that anyone should take my opinion of this. My name is Michael Allar and I approve this message. I strongly desire a single ImGui source of truth. I don't really care which path is taken.

[Sharundaar]

You can also ignore my branch (UnrealImGuiDocker (2023) (w/ docking and multi-viewports): https://github.com/Sharundaar/UnrealImGuiDocker)

I've started it around the same time as Ves for the same reasons but they outperformed me and then I didn't have time/capital to invest in it.

I believe at work we use the IDI-System branch from the original Segross, it's been reliable and does the work but it doesn't support the docking branch, and is not as flexible as VesCodes pointed out (which again... was the reason I started my own).

Ultimately I think the reason ImSlate exists is because it's easier to justify making and publishing a tool plugin on FAB when it doesn't contain external dependencies (it also opens the door for better integration into UMG and the game/runtime UI pipeline but that's probably not a priority), and I think it fits the overall attitude UE have had in the past.

Other than that I'd just echo what being said here :

• Input handling is usually a bit of a mess, that's partway due to Unreal's input system being a mess (Game vs UI, and EnhancedInput on top), and partway because there's a lack of good default (which could also be attributed to UE ever evolving input stack)
• TCHAR* handling is annoying, having an official binding generator that makes a TStringView version of all const char* functions would make this easy (could probably use dear_binding, although I haven't looked into it in years personally)
• BP bindings are useful for the team to extend and make other tools more generally accessible, currently it competes with EditorWidgets (which is UMG base), and there's no real alternative in ImGui (AFAIK, haven't tested VesCodes plugin)

Anyways, I think it's a good initiative, I'd be happy to participate in testing or development where needed.

[Allar]

I want to further add that I am unsatisfied with all input solutions across all current Unreal ImGui plugins. I am also unsatisfied with Unreal Input as a whole but that is a whole other discussion.

I second @Sharundaar on improving string handling.

I wouldn't mind not exposing ImGui to blueprints, but if done so, I would prefer a model of ImGui commands are wrapped in InstancedStructs or other lightweight form of containerable thing. The world has enough UObjects in existence. I personally prefer the idea of support the paradigm of having a DataAsset with a list of ImGui commands in a flat array that you just execute, and these can be defined via blueprint subclasses or very simple native C++ funcs. This allows you to reconstruct a UMG widget with an ImGui widget within it purely off of the data available at construct time, among other benefits. That said, this is not important to me and whatever the standard solution is I'll derive my own twisted contraptions on top of it regardless.

[CA-Jon-Colverson]

We use VesCodes's plugin and are generally very happy with it. Users are very enthusiastic about the multi-viewport support.

We have made a couple of modifications for better handling of mouse input when ImGui windows overlap Slate windows (but it's still not perfect) and embedding ImGui in Slate widgets. I'm interested in getting approval to contribute those modifications back, but haven't gotten to that yet. High DPI support is another area that could use some work, which presumably means updating to latest Dear ImGui and integrating the high DPI features it provides.

We briefly evaluated SlateIM, and the lack of windows on console and lack of gamepad support are fatal for us. We're also not very keen on rewriting all our ImGui code or supporting both.

[ocornut]

Some inputs

• I have started updating the list https://github.com/ocornut/imgui/wiki/Bindings#unreal-engine to surface maintained ones and mark more as legacy. This is hopefully already a little better. I also added a link to this thread from there.
• I have been told that Cog embeds its own integration plugin, which was not clear to me until now. So it's technically another plugin. Are the Cog tools usable with other integrations?
• Someone pointed out that SlateIM is also facing issues with input/focus and there is a slight chance that this might end up pushing for changes in UE that would be favorable to Dear ImGui integrations.
• I took note of the reminder that adopting the string_view branch would be favorable. That branch is mostly ready and already maintained as a feature branch, and I'll be tempted to merge it in 2026.