Imgui possible in jme3?

So I found this here: GitHub - kotlin-graphics/imgui: Bloat-free Immediate Mode Graphical User interface for JVM with minimal dependencies (rewrite of dear imgui)
Basically if I understand it correctly this ui library outputs a set of vertexbuffers and commandbuffers for the gpu, but does not much more. This sound (for me) like it might be easily integrateable with jme3, and sufficiently powerful compared to other solutions.

So questions are:

  1. does anyone see any actual issues with integrating this into jme? AKA what are the pitfalls I need to take a look at.
  2. did anyone already work with the c/c++ version of the engine?
  3. are there currently any other alternatives for a somewhat rich ui system (i know lemur and nifty) (I was barely active for like a year here)

Many of my coworkers who already worked with a c++ engine were using it. and seems it’s the no brainer choice when you do ui in 3D with C++.
However looks like you have not a lot of option for styles… which is ok when you do a technical application (like a graphic demo or debug ui for an engine) but for a game it can be an issue. I can be wrong but I couldn’t find a way to customize the ui much… but maybe there is.

So… for Java, is useful when you want to use LWJGL directly instead of JME3/Lemur combo? Like reinventing the wheel?

The idea would be to hook it into jme of course, as jme is really missing a solid ui library for richt ui applications. (The ones we have all scale not good to large mmo like uis)
I currently use Lemur, and for example simple things like scrolling tables are missing (kinda a base requirement for inventoy and marketplace screens)

I’m currently evaluating if implementing that ui is simpler than extending lemur enough.

FYI: the ListBox, GridPanel, scroll, model separation was designed with tables in mind. For example, I think it’s possible to have like a list box per column with a single scroll bar unifying them. Not necessarily using the ListBox class directly but that’s the design.

I think in the case with desktop, javaFX is enough :slight_smile:

I had some extensive problems with javafx performance for the tradeuis (aka several hundret of entries with images ect) :confused: Also javafx on linux is sadly in a near desolate state (software barely hardware accelerated)

Thats why i switched to lemur in the first place. Btw. have you found a way around the java9 breaking change thing i have in the back of my mind?

What do you mean?

how many years ago was it? since java 8, javaFX uses openGL under all linux systems.

you can use module exports options to solve problems with it.

I used fxml extensivly, and i had issues, that creating a ui from it required several seconds for more complex ones. Mainly because the core implementation was using a shitload of reflection during creation. The other issue so far is, that the resulting imagebuffer needs to be copied on cpu, since javafx does not nativly export the opengl texturebind.

it is not efficient approach to build UI, I create UI using only java code, it works very fast.

It is not a problem if you use tonegodgui/lemur to make some “indicators” and javaFX for more complex UI parts.

I beg to differ. If only I do stuff yes, but FXML was easily off-loadable to friends with only a little bit of introduction required. In fact this was a massive time saver. In fact this was so usefull, that I have a created a small lxml parser for lemur.

Another problem is the retaining of state. For my inventory screens I started to throw away all components each frame, as the hassle to synchronize the state over multiple thread barriers was really difficult. Just rebuilding it each frame did the trick, however this is already the mindset of a immediate mode ui library.

I could mix lemur and javafx, sure, but then I would also need to synchronize the styling that it does not look awkward, and ensure that the input handling does not create a lot of issues. And I would still ge tthe framebuffer copy as a fixed cost even if no ui is displayed.

For my current way of writing I think that a immediate mode ui is the better approach.

in the case with JavaFX, you need copy a framebuffer only when you have changes in your UI scene.

sorry, but I don’t understand your problem :frowning:

you can reuse your “FXML parts” to avoid the time :wink:

Updating an inventory screen was actually around 5-10 times as much code as creating it initially, especially since it could be changed from the ui and from other non ui based stuff, so I had to do a diff every frame between displayed and actual state. This was a real nightmare to do properly that I eventually gave up, and just recreated the entire ui every frame. This is already the concept of a immediate ui framework, so it is a better natural fit. This issue was magnified by the fact, that I cannot query my game state from the JFX thread, as it is not able to see a properly synchronized view. (game logic is multi threaded due to es), so I had to collect all state and send it to the jfx thread for the updating anyway.

hm, your UI is too much difficult maybe… I didn’t have problems like your when I worked on UI of SpaceShift game