4 ms·

I was totally sold on this and already preparing to try this out on a simple game using OpenGL I'm working on as a pet project, until I saw the code examples. T

by w0utert 12y ago

I was totally sold on this and already preparing to try this out on a simple game using OpenGL I'm working on as a pet project, until I saw the code examples. The amount of highly-specific OpenGL code that's apparently needed to embed an ImgUI popover is completely prohibitive to my use case, the GLEW and GLFW examples literally have 3 times the number of OpenGL calls my own rendering function has, I see custom shaders used just for the UI, setting up clipping rectangles, loading font textures, etc. And that's just to manage renderer state, not even to setup the popover itself. I can understand that it's an advantage to have something like this renderer-agnostic, and embeddable anywhere in your render flow, but the way you have to use this completely defeats its purpose IMO. I would love a higher-level abstraction layer on top of this that deals with all the render state setup, so I only have to setup the UI itself and populate it, and can throw in a one-liner somewhere in my render function that draws it. In this case, I would happily trade the fact that this would break render-independence and would clobber render state, for ease of integration. That said, the end result looks immensely useful and very-well done, it's just too involved to setup and use I think...

ocornut 12y ago
Hello, Thanks for your feedback (I am the author). The example applications probably haven't received enough love. They are standalone apps and there is only so much you can shrink the code. If you are using your own engine it is likely that you've already done initialisation and you have helpers to load shaders easily. Imgui.cpp/Imgui.h themselves are render agnostic to enable portability on embedded systems and consoles where OpenGL is unavailable so it is important it stays this way. However it is perfectly possible that we could rework the sample applications to become more like "drop-in" for a given architecture (OpenGL+glfw coming to mind as being a common case). It also appears that I could make the OpenGL sample simplier by using the fixed function pipeline and the glScissor() function so I will try that. This is a first release and it hasn't been used or touched by more than half a dozen people so it may take a few patches until I can make the sample application simpler. Best. O.
- w0utert 12y ago
  Thanks for the explanation :-) A stripped-down minimal example would be very helpful to show how to use the library, just a simple popover with a single control and the absolute minimum required render calls for example. I agree that the fact that this is render-agnostic by the way, and like you mentioned yourself: if you need this you probably have most of the initialisation and shader compilation stuff covered, I wrote some simple wrapper classes for ES2 myself. But a really thin OpenGL (ES) or DirectX specific layer on top of the core functionality would also be great to make the tool a little more accessible of course ;-) Great work nonetheless, maybe I'll play around with it anyway to see how much work it actually is to embed this in my (at this stage extremely bare-bones) renderer.
  - ocornut 12y ago
    The thing with how rendering work is that a "complex UI" vs a "single control" will use the same and only rendering feature required, aka: "render triangle list given a scissoring rectangle". There's no middle ground. I will provide an example app that use glScissor() and the fixed pipeline so no custom shaders will be required. However I am not sure how the performance will behave with widgets that frequently change the clipping rectangle. At the moment the system is optimised to minimize draw calls (I would like a typical "complex" tool to take under 0.5/1.0 milliseconds to build and render). I was actually considering moving the clipping rectangle within the vertex buffer so everything could be rendered in 1 draw call, which would simplify the code and be faster, but requires a custom shader. That is to say, it is an open ended problem and there's not one single solution. I already pushed some tweaks and comments in the sample applications. Your criticism is perfectly legit and I aiming to simplify integration as much as possible so please don't hesitate to comment further if you had another go at it.
ocornut 12y ago
If you update to latest I have reworked the OpenGL sample to now use the fixed-pipeline. It is a little less efficient but simplier to understand.
- w0utert 12y ago
  Thanks, maybe I'll have a look this weekend if I can find some time, and let you know how I fare. I don't think I can actually use the simplified version though, as I'm using OpenGL ES 2.0, but I should be able to figure it out I think :-)

by w0utert 12y ago

ocornut 12y ago

Hello, Thanks for your feedback (I am the author). The example applications probably haven't received enough love. They are standalone apps and there is only so much you can shrink the code. If you are using your own engine it is likely that you've already done initialisation and you have helpers to load shaders easily. Imgui.cpp/Imgui.h themselves are render agnostic to enable portability on embedded systems and consoles where OpenGL is unavailable so it is important it stays this way. However it is perfectly possible that we could rework the sample applications to become more like "drop-in" for a given architecture (OpenGL+glfw coming to mind as being a common case). It also appears that I could make the OpenGL sample simplier by using the fixed function pipeline and the glScissor() function so I will try that. This is a first release and it hasn't been used or touched by more than half a dozen people so it may take a few patches until I can make the sample application simpler. Best. O.

w0utert 12y ago
Thanks for the explanation :-) A stripped-down minimal example would be very helpful to show how to use the library, just a simple popover with a single control and the absolute minimum required render calls for example. I agree that the fact that this is render-agnostic by the way, and like you mentioned yourself: if you need this you probably have most of the initialisation and shader compilation stuff covered, I wrote some simple wrapper classes for ES2 myself. But a really thin OpenGL (ES) or DirectX specific layer on top of the core functionality would also be great to make the tool a little more accessible of course ;-) Great work nonetheless, maybe I'll play around with it anyway to see how much work it actually is to embed this in my (at this stage extremely bare-bones) renderer.
- ocornut 12y ago
  The thing with how rendering work is that a "complex UI" vs a "single control" will use the same and only rendering feature required, aka: "render triangle list given a scissoring rectangle". There's no middle ground. I will provide an example app that use glScissor() and the fixed pipeline so no custom shaders will be required. However I am not sure how the performance will behave with widgets that frequently change the clipping rectangle. At the moment the system is optimised to minimize draw calls (I would like a typical "complex" tool to take under 0.5/1.0 milliseconds to build and render). I was actually considering moving the clipping rectangle within the vertex buffer so everything could be rendered in 1 draw call, which would simplify the code and be faster, but requires a custom shader. That is to say, it is an open ended problem and there's not one single solution. I already pushed some tweaks and comments in the sample applications. Your criticism is perfectly legit and I aiming to simplify integration as much as possible so please don't hesitate to comment further if you had another go at it.

ocornut 12y ago

If you update to latest I have reworked the OpenGL sample to now use the fixed-pipeline. It is a little less efficient but simplier to understand.

w0utert 12y ago
Thanks, maybe I'll have a look this weekend if I can find some time, and let you know how I fare. I don't think I can actually use the simplified version though, as I'm using OpenGL ES 2.0, but I should be able to figure it out I think :-)