Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use for custom Unreal editor window? #30

Open
sunpeng1995 opened this issue Apr 27, 2020 · 7 comments
Open

Use for custom Unreal editor window? #30

sunpeng1995 opened this issue Apr 27, 2020 · 7 comments

Comments

@sunpeng1995
Copy link

Hi,
Thank you for the wonderful UE4 integration. I have created a in-game debug tool for my project. It's really convenient and easy to use, compared with Slate.
I have read some source code and tried to create a custom editor window using it. But it seems the imgui widgets can be added to game viewports only. I wonder is there a way to draw the imgui widgets on the eidtor window?

@segross
Copy link
Owner

segross commented Apr 30, 2020

Hi and sorry that you had to wait. There is a short and more complex answer to your question.

The simple answer is that unfortunately it is not supported, at least not out of the box. Staring this project I was mainly thinking about debugging and making it possibly seamless for the game code. That resulted in this per-world-oriented approach and adding some changes which I was doing while learning the engine created a bit of legacy code that right now I have no power to refactor. But I would like to invert that design and make it a bit more widget oriented, allowing multiple widgets with own contexts.

However, I think that there should be some potential to adapt it to the editor windows without changing everything. I will try to give a rough idea of what I think should be changed to get it working if not in the best then at least in the easiest way:

  1. The first problem is that we attach the widget when getting OnViewportCreated events. That is ok for game worlds but not for the editor. However, FImGuiContextManager gets all tick events. It should be possible to manage editor attachments there.
  2. Another problem is that I map PIE Indices to keys that identify world contexts. This works ok for game worlds and makes sure that we can reuse contexts between different PIE sessions, but it will not differentiate editor worlds. That would need to be addressed somehow. That is something I will want to change at some point anyway.
  3. Once 1 and 2 are sorted out, the remaining part will be to fix any possible errors in the widget. It should not expect that game viewport is there, maybe get its own context in a different way, etc.

@sunpeng1995
Copy link
Author

Thanks for the advices. I've followed your idea and read the source code in the past few days.

Then I created a new Slate Widget to decouple with Viewport, and override the OnPaint method which is just like SImGuiWidget. The imgui tick events are temporarily registered on EditorContext. The input handle and font atlas need some modifications to maintain the proper life-cycle.

It barely meet my requirements and have a lot to optimize. I will try to make a per-window context and input handler, I think it is better to pack those modification to a submodule for editor usage. I will post here if I make progress.

imgui_on_editor_window

@segross
Copy link
Owner

segross commented May 7, 2020

Hey, I'm glad that you made a progress on that.

I suppose that making the editor context was straightforward enough and the bigger issue was the widget itself and attaching process. I'm not sure why font atlas would be an issue though.

The multiple modules is quite possible road ahead. I was also thinking about splitting everything but on the first sight I expect a circular dependency. I might need to think how to avoid that nastiness.

I want this to change it and can get rid of the input handler (I truly dislike it), make it more widget-centric and allow widget sub-classing to give more override flexibility. In this picture, debug and editor widgets would be specialisations but I want to also support one other use case where ImGui is used for actual game widgets, which probably means UMG extension. But I want this to be invisible when debugging is the only use case. Other modules should become relevant only when custom widgets are needed.

I want to make some introductory changes in 1.x but because of the scope and possible changes on the user side I was more thinking about making it a version 2.x.

@VinceBret
Copy link

@sunpeng1995 that is pretty cool what you have done.
Can you share that ?

@sunpeng1995
Copy link
Author

@VinceBret sorry for the late reply and thanks for your appreciation. Because of the busy work, I only did a rough implementation few weeks ago and didn't go deep into it. I have shared my work in the editor-use branch of my forked repository and some example code here. I hope that will be helpful.

@VinceBret
Copy link

Thanks I ll take a look at that

@juaxix
Copy link

juaxix commented Sep 8, 2022

Hello @sunpeng1995 , I've tried your code, but it crashes at UImGuiInputHandler::Initialize , at:
checkf(ContextProxy, TEXT("Missing context during initialization of input handler: ContextIndex = %d"), ContextIndex);
do you have any project to test this?
Thank you for your effort!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants