Jump to content
  • Advertisement

This topic is 909 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi,

IMGUI becomes populare but is it good for everything (game, debug, editor) ?

What is your opinion about it ?

Thanks

Edited by Alundra

Share this post


Link to post
Share on other sites
Advertisement

A few forum members around here stated they're going to build embed Webkit rather than going rolling their own UI solution!

I haven't been following IMGUI in years after it blasted a couple of months of my effort for no benefit at all.

Following thread.

Share this post


Link to post
Share on other sites

Hi,

IMGUI becomes populare but is it good for everything (game, debug, editor) ?

What is your opinion about it ?

Thanks

 

Nothing is good for 'everything', which is why there is so many choices. tongue.png

Imgui is an immediate mode gui that can be dropped in anywhere in the code.  It isn't designed to be a full blown GUI system, but something to make quick tools.  I have used it in the past few months, and it seems really stable and easy to use.

Share this post


Link to post
Share on other sites

IMGUI becomes populare but is it good for everything (game, debug, editor) ?

What is your opinion about it ?

 

My speculation is that the more complex my UI needs, the less IMGUI would be useful.

Basically, I think the more simple the UI, the more hoops (boilerplate) you have to jump through to make RMGUI useful, and the more complex the UI, the more hoops you have to jump through to make IMGUI work well. That's just a hunch.

 

So you could use it in an editor if your editor is simple, otherwise I'd use the traditional RMGUI paradigm, but game UIs are usually simple, so I'd default to a IMGUI for those.

Share this post


Link to post
Share on other sites

My speculation is that the more complex my UI needs, the less IMGUI would be useful.

Basically, I think the more simple the UI, the more hoops (boilerplate) you have to jump through to make RMGUI useful, and the more complex the UI, the more hoops you have to jump through to make IMGUI work well. That's just a hunch.

So you could use it in an editor if your editor is simple, otherwise I'd use the traditional RMGUI paradigm,

 

First and as Glass_Knife said, nothing is good for everything! Regardless of being IMGUI or RMGUI I don't think you'll find a library that is both satisfactory for tools AND for in-game if you expect in-game to look all super visually fancy and super customized. Unless your game wants to look like an OS, you are probably better off writing something custom for your game, IMGUI/RMGUI won't matter much. Game ui are generally simple. Then when it comes to tool it really depends what your aim is, who and how many people are going to make the tools and use the tools, how complex is the tool, etc. There are as many solutions as they are situations.

 

We need to differentiate USING the library and WRITING the library.

It is probably easier to write a very simple IMGUI yourself but probably easier to write a little more elaborate RMGUI yourself.

However from the users perspective I believe IMGUI are always easier and more efficient to use.

If your editor is complex, you don't want an UI library that makes things tedious.. And the typical off the shelves RMGUI tends to be tedious.

 

The biggest difference that weights in the mind of people in the RMGUI<>IMGUI debate is that gigantic companies with lots of resources have developed competent, gigantic and full-featured RMGUI API (QT,GTK,Win32,all the stuff DotNet have, etc.) whereas no-one has attempted to develop an IMGUI at a scale that big. And a single attempt wouldn't be enough to make a fair comparison. So we just cannot make a fair comparison. The best and reference RMGUI libraries are huge complex beast. The best IMGUI librairies are pretty simple. We don't have a hugely complex and full-featured IMGUI available (even if I don't favor complexity, it would be nice to have one).

 

My ImGui library (very recently renamed to "dear imgui" to reduce ambiguity) which has been the "popular one" this year is probably the most developed freely available implementation of an IMGUI but even so it still only support a very small fraction of what established libraries support. Also it is a one-pass IMGUI that was developed for convenience and tools and it has its own shortcomings. So it's probably not a fit for all cases. If you are writing authoring, visualisation and debugging tools for a game the library might be great for you. It is a library that was designed by taking some shortcuts to make things easier. You'll encounter some issues but they'll probably be simple to understand and fix/workaround.

 

So the question here isn't just about IMGUI vs RMGUI but probably and mainly about Simple vs Complex. Writing complex tools with a simple and competent library can be a pleasure imho, feels very fast. Fighting against a big opaque mess can be very frustrating.

 

The person who wrote Lumix Engine has been switching from QT to ImGui and wrote a comment here: https://github.com/ocornut/imgui/issues/123#issuecomment-142700775

 

Cons:

- I am still afraid I will not be able to do some things with ImGui I can do with retain mode GUI. However I have not found anything impossible yet.
- Less options for skinning compared to Qt. I am not even sure whether this is a disadvantage, since I am satisfied with default skin, but maybe some users will want it.
- The biggest issue for me is that some basic gui elements are missing, e.g. some equivalent to Qt ListView with several columns (I had to do it in a quite complicated way), progress bar, advanced color picker, ... Maybe these can be plugins to keep the core ImGui slim.
- No docking - second biggest issue
- Multiple monitor support - this is questionable
- Not possible to select values from histogram, or at least render one of the items in a different way so I can select it with a slider

Pros:

- Pleasure to use, when I go to sleep I can't wait to wake up to work with ImGui :)
- Faster to do things than with Qt. Literally 100x faster.
- App in ImGui tends to end up much more polished, because it's easier and faster.
- Most of the missing features are very easy to add. This is extremely hard in Qt and I would never try that.
- Basic widgets (drag float, ...) work in fact better in ImGui than in Qt, e.g. in Qt, if I have a float value e.g. 1.23 in an input limited to 2 decimal places and I want to change it to 1.24, I can not just enter 1.243, I have to delete 3 to get 1.2 and than I can enter 4 to get 1.24. This is extremely annoying in Qt.
- ImGui is a GREAT way to do property grids. In Qt I had to connect milions of signals/slots and I always miss some. In ImGui, this just works.
- There is 20MB dll just for UTF in Qt :(, It can take several seconds to start Qt app. ImGui is extremely small and ImGui app starts immediately.
Edited by ocornut

Share this post


Link to post
Share on other sites

I've been looking into Dear ImGui for a pet project; since it's quite popular, in active development, very stable, fast, lightweight and easy to use. I didn't like its default look at first but cmftStudio is proof that it can look good. I couldn't have asked for anything better.
But there were two issues that were blocking for me:

 

1. Mouse/cursor centric. I'm trying to make an UI that can also be traversed with a gamepad (or keyboard) and no mouse. Like console games.

Dear ImGui doesn't seem to offer this, and it suggests to use Synergy instead. I don't know how hard it would be to add support for it, but ImGui's codebase is large (and a single file!); which doesn't make it easy to evaluate if adding this kind of support by hand would be easy.

 

2. "Threading". Not in the usual way. TBH this is more of a problem with IMGUI in general. Due to how my system works, the user interface is setup from scripts which run in the logic thread; while the actual UI runs in the Graphics thread and then passes messages to the logic thread for the script to process important events (like "user clicked button X") but not the trivial ones unless specifically requested during setup (like "user pressed down arrow to go to the next widget").

Obviously this is an RMGUI way of doing things and doesn't translate well to IMGUIs. I could try to refactor my engine to allow the Graphics thread to run simple scripts and workaround the issue. But this is kind of a big time investment which isn't a deal breaker, but when you add the previous point to consider, then I get grumpy.

 

So in the end I'll probably end up writing my own RMGUI system to suite my needs. It's not that hard for me anyways (for games). I may or may not reuse code from Dear ImGui (after all.. it's damn good) or borrow ideas from it.

Edited by Matias Goldberg

Share this post


Link to post
Share on other sites

0. You are hitting on the very reason why I renamed it ImGui : the library used in cmftStudio is a different one with same name except from casing =) that one is based on an older imgui library extracted from Recast. I suppose the dark color scheme is more pleasant. The library isn't as full-featured and has pretty much stopped definitively unfortunately (but you can look at it). If it is about the color scheme, I'm sure you can get the same scheme with mine as well, and the rendering is very close in the first place. I'm fully aware that a better visual/color scheme is a commonly asked feature but I'm tackling that very cautiously because there are countless subtle side-effects to productivity, software design and performances and I can't just nilly-willy make those changes. Looking pretty is Dear ImGui isn't firstly designed to be pretty but to handle large software easily and efficiently. Prettiness is evolving little by little and help is welcome. (I also have a personal roadmap/agenda of mine, that the library is already taking too much of my time and I don't want to attract too many people on it too fast before I am done with more essential features, and I know revamping the theme will attract more people, but it is coming).

*EDIT* Here's with a different color scheme https://cloud.githubusercontent.com/assets/8225057/7023421/f47d7f3c-dd2c-11e4-9d27-937a37b3e9b3.PNG

 

1. Mouse/cursor centric. Agreed. It is one of the major feature that has yet to be developed in mine. It'd be a rather big task and in my list, but when, I don't know.

That said, using Synergy+mouse/keyboard on consoles is really really great for efficiency. Bite the bullet of setting up the system (half a day?) and you really won't consider having people using tools with a gamepad. Another possibility on PS4 is to use the touch pad for mouse cursor, it works relatively ok for that. Productivity tools aren't great with a gamepad.

 

2. Not sure to understand the nature of your problem. That sentence "the user interface is setup from scripts which run in the logic thread; while the actual UI runs in the Graphics thread" doesn't even seem to translate to IMGUI. Whoever wants UI call the UI functions (you'll have to lock for concurrent access). ImGui doesn't touch any graphic state. Once your are done with logic you can request your graphic thread to render the triangles.

Edited by ocornut

Share this post


Link to post
Share on other sites

0. You are hitting on the very reason why I renamed it ImGui : the library used in cmftStudio is a different one with same name except from casing =) that one is based on an older imgui library extracted from Recast. I suppose the dark color scheme is more pleasant.

Oops. I was quite certain it was using Dear Imgui. Ok...

1. Mouse/cursor centric. Agreed. It is one of the major feature that has yet to be developed in mine. It'd be a rather big task and in my list, but when, I don't know.
That said, using Synergy+mouse/keyboard on consoles is really really great for efficiency. Bite the bullet of setting up the system (half a day?) and you really won't consider having people using tools with a gamepad. Another possibility on PS4 is to use the touch pad for mouse cursor, it works relatively ok for that. Productivity tools aren't great with a gamepad.

Well, I was speaking from a "use ImGui for games" perspective, so gamepad traversal makes sense.
When you look at it from the "use it for debugging tools / internal UIs" perspective (its original goal), Syngergy makes perfect sense.
 

2. Not sure to understand the nature of your problem. That sentence "the user interface is setup from scripts which run in the logic thread; while the actual UI runs in the Graphics thread" doesn't even seem to translate to IMGUI.

Indeed. Basically that's what I meant. There was already work done with some wannabie GUI I pulled together, and it definitely was thought for RMGUI systems.
Note: the Graphics thread captures input due to OS restrictions. Trivial logic (e.g. navigating through the UI) is handled there to reduce latency. Sending to the Logic thread may between 0 and 2 frames of latency (depending on thread timings) and getting a result back from Logic can take another 0-2 frames of latency.
Considering 3D rendering is already triple buffered, handling everything in the Logic thread means a final latency of 1-7 frames (16ms to 116ms at 60FPS).

ImGui doesn't touch any graphic state. Once your are done with logic you can request your graphic thread to render the triangles.

That's something I didn't account. I suppose I could handle the whole UI in the logic and then send a copy or to the graphics thread to render (ignoring any possible latency issues).

Share this post


Link to post
Share on other sites

I don't really understand why you would have any frame of latency passing data from one thread to another, but then I don't know the restrictions your own code/engine have.

Anyway Dear ImGui is definitively not designed for in-game end-user UI primarily because it doesn't look like anything you'd want your game to look it. It's definitively a library for tools.

 

Back to OP, if you were to design a game UI, the IMGUI idea of submitting items every frame would apply as well. Regardless of UI it is generally sane to avoid state duplication.

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!