segross / UnrealImGui

Unreal plug-in that integrates Dear ImGui framework into Unreal Engine 4.
MIT License
666 stars 211 forks source link

How to change Viewport/Canvas size settings ? #37

Closed Froyok closed 4 years ago

Froyok commented 4 years ago

It looks like by default the viewport and canvas size don't match, making some widget appear out of frame if your window is smaller than the screen. It looks intentional when looking at ImGui/Private/Widgets/SImGuiWidget.cpp, seeing there is a switch on an enum inside SetCanvasSizeInfo() than handle different behaviors leading to different sizes later in UpdateCanvasSize().

My question is how do I access the FImGuiModuleSettings module to be able to call the various Get/Set function and change this enum value ? I have looked around but didn't find the point of entry for me from outside of the plugin. I'm also having some include errors when trying to reference ImGuiModuleManager.h, so any input is welcome on that as well.

Right now I have to hack the UpdateCanvasSize() to answer my needs, which is not great for later mainteance.

segross commented 4 years ago

The setup panel is described here https://github.com/segross/UnrealImGui#settings. It requires an update to mention Canvas Size and DPI Scaling but when you hover you should get tooltips with comments. Let me know when you find it, so I can close the issue.

If you would like to access it from code then it is a different story. The FImGuiModuleSettings is intended to be private. But I would be interested to hear the use case as everything is always for discussion. But normally properties are meant to be dynamic and therefore exposed through the module interface and settings are meant to be controlled from config (through the settings panel).

When it comes to navigation, since I use it for debugging, I prefer a bigger canvas + this https://github.com/segross/UnrealImGui#navigating-around-imgui-canvas

Froyok commented 4 years ago

Ha interesting, didn't think about the plugin settings (I guess I didn't read the code far enough). Given we can change some properties at runtime, I assumed the plugin would work the same way for all the other modules.

In my case I'm just looking for a way to fix in place some windows to have always visible debug info. So I prefer to do that based on the corners of the viewport. I don't think I would need an hybrid mode where some window would be free to move and other fixed on the screen (but that might be useful to some ?).

I you don't mind me saying this: I would suggest clarifying a bit more the readme then. Even after reading what you pointed out, I didn't find it super clear, and without looking at the code I would not have assumed this behavior would be the default. Especially since in UE4 Slate and Canvas fit the viewport size. I don't know ImGui well enough to know if that should be the default setting in practice however.

(Thank you for your time by the way ! I really appreciate how fast and how detailed your answers are.)

Bonus, here is the kind of debug UI I'm doing in Canvas/Slate and I'm trying to move to ImGui:

segross commented 4 years ago

No, of course, I don't mind feedback. But I'm not sure whether I'm fully getting your point, though.

So let me write how it works:

As far as I understand you, you might want to use adaptive size. But keep in mind that if you do that, then in editor it will change whenever you change the size of your PIE window. And when you change the canvas size it can rearrange your widgets. I don't like it and that is why I keep it always larger. And if you want to have some layout management that will be part of your debug code. If you use adaptive size it will match then you will be able to get that size from ImGui. If not you can get it from the viewport.

In the end, you may sometimes need to change the plugin here and there but the idea is that the game code is shielded. There are delegates for convenience, texture registration and properties exposed to partially control the plugin and in the future I might expose more to allow easier adaptation for other needs, but ideally the game code should knows about it as less as possible and mainly use the ImGui itself.

And on the side note. I would recommend looking and playing a bit with the ImGui. There might be some learning curve and for some people it may be sometimes frustrating. But I noticed that in my last studio me and a few other people could sometimes sink for a few days building debug tools, so it can be highly addictive.

Froyok commented 4 years ago

Thanks for the details, that clarifies things up !

My intended usage with ImGui is more similar to docked widgets rather than floating windows, so that's why following the viewport resolution works better for my use-case. I get your point however.

I work (and design) UIs/workflows for a living, so I can confirm that building tools can be addictive indeed. ;D