@lubos As it seems nothing happens new with the UI Editor (only 2 logic nodes for it, elements to drag & drop but not usable, …) , is it something which is going to disapear in futur versions, to be replaced by another solution to make UI ?
Does Blender 2.8 have some UI system that could translate to Armory real time without too much effort ?
I have to admit that the UI is a big stumbling point for me too. I would love to see this be a emphasis soon. I think that with what Armory can do right now as it sits, a bunch of good games could be made. Saving and UI seem to be big stumbling points. I could be missing something in all that goes on in the community and would be happy to be corrected.
I think that what @Monte_Drebenstedt says is probably true, that saving and UI are some of the bigger practical obstacles to building a game of any scale. My brothers are working on a simple 2D arcade style game, but UI and saving is a bit of a blocker. They managed the UI with clickable meshes and simple text elements, and I haven’t double-checked to make sure that saving is still broken, but those are maybe the biggest singular issues that most games will need that are not fully taken care of.
For UI I think it might be a better idea to pursue trying to get HaxeUI to work for Armory. They have their own UI editor ( WIP ) and it offloads what can be a whole lot of work onto another team. Then all Armory has to manage is the integration with Kha.
For saves, I think that is a relatively simple issue that just hasn’t been tackled yet. I’m not actually 100% sure what platforms it is or isn’t working, we should probably figure that out for sure, too.
I agree @zicklag. If the best option is Haxe UI that would be great. We just need to make sure the nodes come with it. Given the ease of use that armory has we really shouldn’t have to learn code just to add a UI to a Arch Viz project or the like. I wish I had the skills to understand all the code. It just seems there isn’t the time to learn it all. The nodes add so much to the ease of use and can allow so many artists to make projects that can include interaction.
The layout builder is pretty amazing, this is so easy to create HUD.
I think he would like more logic nodes to control HAxeUI and something more usable.
HaxeUI and zui are fundamentally different approaches to UI and I’d be sad to see zui go - immediate mode UIs are great for game development when you can get used to the concept.
Also - what exactly is wrong with saving?
I don’t want to see zui go too but we are actually talking about what ui should be used in-game, of course using zui in game would be very limiting, i never seen a game using imgui for it ui, having zui for canvas is probably best but not for in-game.
(i am getting somewhat confused here, UI editor means Canvas editor right?)
I was talking about in-game uis. imguis are great for that in particular IMHO but I have to admit I do not have the magic powers to figure out whether a game ui is an immediate mode ui just by looking at it. And it very much depends on what you are used to. The other new UI thing in Haxe world is Nicolas’ DomKit which is based on html/css concepts - many people love that stuff even though to me it’s just horrible. Even Unity struggles with this diversity in tastes when it comes to UI systems.
The saving should be ok in 0.6 (as in writing into storage), if we are talking about some more advanced game save system then that’s still an issue.
Docs on the new DomKit thingy Robert mentioned:
I did not explore it yet but if someone already did - opinions on whether it would be a good (long-term) fit for armory welcome!
You loose the advantage of a graphic UI builder.
Let me correct that:
You loose the disadvantage of a graphic UI builder.
(would be totally possible to do an imgui UI builder though but I suppose the typical imgui fanboy (aka me) wouldn’t even want one)
I don’t need to link a video to how UI is done in Godot and other 3D engines, but UI editor is a must have feature.
(UI editor is available in Haxe UI, i don’t understand why choosing something else or put lot of effort making one and re invent the wheel again).
I don’t disagree with that being important for a project like Armory. Only point I’m trying to make is that different people want very different things from a UI system.
All matter to me is functionality(i.e., drop down, field that has scrolling, etc) and flexibility(i.e., round UI, textured UI, etc) of UI.
Maybe we take some feature from other UI, such as CSS styling, because this can reduce no. of button present in UI Editor to style the in-game UI, and can improve flexibility too
I want to keep ZUI because of two reason:
- Its look really cool
My concern is that thinking long-term if we want to give up ‘in-house’ game ui and offload it to another team - then heaps has the biggest man-power behind it.
As for the benefits of zui:
- easy to tackle performance issues
- easy to tweak for armory needs
- has very small codebase
- barely affects compile times & build size
On the other hand it’s still missing components to make it more game ui friendly…
I think Zui is really great for a debugging UI or if you just want an immediate mode UI, and like @BlackGoku36 says, it actually looks really cool. Still, it doesn’t lend itself as well to heavily stylized in-game UIs like something that allows for CSS styled buttons and such like that.
I think we definitely want to keep ZUI around and improve it as Armory grows, there definitely seems to be enough people who like it, and like @lubos mentioned it has its advantages for sure, but I think it would also be good to find a 3rd party library that handles more of a rich UI.
The good thing about this is that users can also make their own decisions which is part of the power and lure of Armory. We want to find something that as a community we support as a standard so that we can unite efforts without going out in all directions, but if somebody wants to integrate the UI solution that we don’t go with, they can do that.
If I get the time or somebody on my team, we will definitely look into the Domkit UI. Looks like it could be cool.
When I started this discussion with a somewhat provocative title, it was with the idea of reviving everyone’s interest in Lubos’ good work with his UI Editor.
It was more in the sense of “let’s not let the Lubos UI Editor die”
Very good work even from my point of view, because it allows a very fast link between the Logic Nodes and the UI, and gives too a fast way for non-developers to make their UI.
And in my opinion, that behind it uses this or that mechanism/library, finally no matter … what’s important is how user-friendly and easy to use it is in Armory with Logic Nodes.
Thus a clear roadmap of improvements could be seen too in conjunction with Armory versionning to see it’s alive
So why not continue on this path, by simply introducing more logic nodes to be able to use it? Or give the community documentation that leads it to produce other nodes and Canvas elements that will then be reused by all?
There is evaluation before creating logic nodes you wan, be patient lol
(I would perfer normal maps working in materials first than UI working).
I would like to have UI properties driven by timeline animation.