How to draw on an ImGui window?

[morizotter]

Do you know how to draw gl in the ImGui window?

https://github.com/ocornut/imgui/releases

I'd like to do like above.

[ocornut]

You can:

1- Render your scene in a texture and then render the texture in imgui. For the second part read about comments related to ImTextureId and check the code in your imgui_impl_xxxx.cpp renderer. Check the Image() functions, and ImDrawList::AddImage() etc.

2- Add a Callback to the current window ImDrawList and perform your full rendering within this callback at the right point during rendering.

The first one is simple and convenient and this is what most people would do.
The second one can be useful if you need to save 1 render pass but it is rarely a real problem.

[morizotter]

Thanks I'll try to do it!

Isn't it possible to draw in the default framebuffer?? Because I create a rendering pipeline to the drawing default framebuffer myself.

[ocornut]

Isn't it possible to draw in the default framebuffer?? Because I create a rendering pipeline to the drawing default framebuffer myself.

You can draw wherever you want to draw, at is all under the control of your application.

If you want to avoid intermediate buffers you can use ImDrawList::AddCallback().

[morizotter]

Thanks again! I'll try to do it later!

[citruslee]

@morizotter in my engine I create a plus one more buffer for my engine and I let ImGui draw on backbuffer. So this one more buffer is actually the "backbuffer" for my engine, since then I do postprocessing over the image, so it makes sense to make it like this. So just make your engine backbuffer a RenderTargetView or FBO (or whatever you fancy) and pass it to ImGui control as image. Easy, no hassle and quite clean solution

[morizotter]

I'm also new to C++... I's a bit difficult for me..

// 2. Show another simple window, this time using an explicit Begin/End pair
if (show_another_window) {
    ImGui::SetNextWindowSize(ImVec2(200, 100), ImGuiSetCond_FirstUseEver);
    ImGui::Begin("Another Window", &show_another_window);

    ImGui::GetWindowDrawList()->AddCallback(draw_callback, NULL);

    ImGui::End();
}

and,

static void draw_callback(const ImDrawList* parent_list, const ImDrawCmd* cmd)
{
    printf("hello!\n");
    {
        static GLuint programID = LoadShaders( "/Users/moritanaoki/Desktop/rendering-in-imgui/SimpleVertexShader.vert", "/Users/moritanaoki/Desktop/rendering-in-imgui/SimpleFragmentShader.frag" );
        glViewport(0, 0, 300, 300);

        glUseProgram(programID);

        GLuint VertexArrayID;
        glGenVertexArrays(1, &VertexArrayID);
        glBindVertexArray(VertexArrayID);

        static const GLfloat g_vertex_buffer_data[] = {
                -1.0f, -1.0f, 0.0f,
                1.0f, -1.0f, 0.0f,
                0.0f, 1.0f, 0.0f,
        };

        GLuint vertexbuffer;
        glGenBuffers(1, &vertexbuffer);
        glBindBuffer(GL_ARRAY_BUFFER, vertexbuffer);
        glBufferData(GL_ARRAY_BUFFER, sizeof(g_vertex_buffer_data), g_vertex_buffer_data, GL_STATIC_DRAW);

        glEnableVertexAttribArray(0);
        glBindBuffer(GL_ARRAY_BUFFER, vertexbuffer);
        glVertexAttribPointer(
                0,                  // attribute 0. No particular reason for 0, but must match the layout in the shader.
                3,                  // size
                GL_FLOAT,           // type
                GL_FALSE,           // normalized?
                0,                  // stride
                (void *) 0            // array buffer offset
        );
        glDrawArrays(GL_TRIANGLES, 0, 3); // Starting from vertex 0; 3 vertices total -> 1 triangle
        glDisableVertexAttribArray(0);
    }
}

produces:

I want to a draw red triangle in the window..

Sorry for easy question..

[ocornut]

The callback won't know anything about windows. If you want to draw at a certain screen position you may use eg GetCursorScreenPos() and transfer that information into your callback.

[morizotter]

I could pass window info to callback.

I have problems. Something wrong with my way..

• The triangle is flickering.
• The triangle is transparent.
• When tapping other view, the view disappears.

If you have a simple demo code 😅 . Anyway, thank you for your help! I'll try to do it..

[ocornut]

This is not an imgui problem anymore but a problem with your OpenGL rendering state. It may be easier/healthier to support render targets, but either way to will need to evolve your code/engine to setup all render state correctly.

[ocornut]

Note you might use the ImDrawList api as a primitive renderer if you can rely on using the ImDrawVert type for all your vertices. You can then change shaders/uniform/constantbuffers using callback. Of course this is only a solution if your rendering needs are simple and you can't/don't want to create a full fledge renderer.

[morizotter]

This is not an imgui problem anymore but a problem with your OpenGL rendering state.

I know it. I try to brush up my knowledge about OpenGL and ImGui! 😺

[citruslee]

@morizotter you need to brush up C++/OpenGL not ImGui. Sorry to be harsh sounding, but ImGui is 99% not the reason why your rendering is bad. Also, don't care about imgui yet, you don't need it. We switched to ImGui after like 7 months of engine development, where we figured that let's say editing XML files don't cut it anymore

[ocornut]

@citruslee I partly disagree - there's no reason you shouldn't use ImGui from Day 1 of engine development. Engine = tools, auditing, debugging, tests, interactions, they all need some form of UI, why waiting 7 months!

[citruslee]

@ocornut valid point, but he should learn programming in the language and graphic API first, then bother about UI

[citruslee]

also for the very reason, it was quicker to edit the XML file directly, and yeah, we had this hot reload of built code and assets, including XML-s, which made content management quite a breeze, but then we incorporated 3D artists and designers so we suddenly needed a UI

[ocornut]

@citruslee UI can help people learn programming by visualizing and understanding what they are doing better (e.g visualizing algorithms). Either way it is a tool, there's no rule of thumb but if its worthwhile for you no reason of delaying its use. I also have similar systems (except without xml, because I respect my eyes ;)) as I think editing text files is super convenient. I personally mostly use dear imgui for visualization, testing, debugging tooling more than actual content authoring. Some of my in-engine tools are here #772 (comment)

[citruslee]

yes, they can, but I still think, if you are not familiar with the language or the api, it won't help you that much, because if you can't visualize the data by yourself, you would not do it even with ImGui. Also, to make UI actually work for you and not the other way around takes practice, even if it is ImGui, which is my favourite UI library (yaaaay! :D), but still, first IMHO he should learn vanilla C++ and then if he is comfy with the language should use ImGui.

A few words to end my seemingly passive agressive and harsh dialogue, I encourage everyone to program, because programming is fun, and the result is greatly rewarding. I also teach programming for university students, but I find one thing recurring year by year. Everyone just wants to suddenly make games, or they are digging their head into stuff they don't understand at all. While if someone's IQ is above the speed of light and he had a programming experience before, they can get things up pretty quickly, but usually it takes time to do advanced stuff. And until then you should stick to simple things. This is why I developed Minerva with no GUI and with XML's. Because I have my own pretty damn kickass xml lib and I had routines built into the engine which helped me to reduce the number of builds and increase the content creation. And probably I still don't need any UI libs, neither ImGui, because I can change the code during the runtime (hotreloadable plugins) and also the data (change xml, bam). Of course since then we began to use console inside Minerva and that is damn comfy, but still nothing what you couldn't do with your fiat windows console.

Still, hope ImGui will be growing steadily and it won't go away, because this lib is the only usable lib where I can make fast prototypes for our designers and graphicians, so thank you @ocornut for Dear ImGui, keep up the good work and get docking into ImGui API ASAP! :D

[colesnicov]

May be you can create a different viewport to 3D scene and set its position and size as your ImWindow? Customize they background as transparent and its be look as 3D scene inside ImWindow?

[ocornut]

@morizotter Have you solved this problem?
I strongly suggest you should aim for the first solution that I posted in my initial answer, aka render to a different render target and render this render target as a texture in imgui.

Using callbacks and rendering without an intermediary target is harder to get right.

[rixthor]

If you render after ImGui::Render(); you will overwrite any ImGui window without transparencies ;)

[xor2k]

I may have found a solution, at least for the OpenGL 3 examples, see my pull request #1639.

[marvpaul]

Better late than never @morizotter

Found a reason for flickering! In my fragment shader I used a vec3 output color. I changed it to vec4 and set alpha to 1, this resolved flickering in my case.
My simple fragment shader looks like this:
#version 330 core
out vec4 color;
void main(){
color = vec4(1,1,0, 1);
}

Thanks for your code, it helped a lot!