Showcase Interface + Interface Graph - An Alternative To The UI Builder

Some months ago I started to work with UI Toolkit, but I found the way the UI Builder worked limiting in terms of dynamic and scripted content and also too different from the UGUI workflow that I had grown used to. Still, I liked the underlying concept of UI Toolkit and how well it scaled both in terms of performance and with different screen sizes as well as its similarity to how HTML and CSS worked. So, in short, I liked the underlying concept, but not so much the workflow. This is where Interface comes in.

In the picture below, you can get a brief look on how it looks like at the moment:

All elements are placed under the InterfaceCanvas. The InterfaceCanvas is the root of all your UI and works together with the UI Toolkit UI Document to show and manage everything you see on the screen. Under the canvas you have CanvasElements. These all contain an override style (similar to inline styles in HTML) and a list of styles to derive from, which will be applied in order of appearance in the list. You add modules to your styles and enable the properties you want to use/override already set properties.

With instructions from the CanvasElements, the InterfaceCanvas generates the layout which takes about 5ms on a 2 year old laptop. In other words; performance is not a problem. This generation only has to be done once at the start of the game/when a domain reload happens. Most of the time, only the element you have changed will be updated which is virtually instantaneous.

There is also the concept of SpecialElements. These elements inject content into their attached CanvasElement such as entire Graphs and Charts as well as Sliders, Toolbars and Carousels (with more to come in the future).

Now with that being said, I would like to hear from you. Do you have any questions or feedback based on what has been mentioned and do you think you would find it useful as an asset on the AssetStore?

 

I would really like to have a look at how you did all this,
I've not been able to do much except basic custom editor stuff
I really have no idea how to get anything near this

A small article or tutorial would be really helpful as there's hardly any resource covering anything advanced than the basic editor tool scripting that I found

 

There will probably be some useful information and resources in the documentation, once I get to that part. The documentation should be available on the internet once I make it, and I might make some tutorials on how to extend this.

 

Hi, there's a lot I like in this. I think it could help to bridge the way designers work currently with the old UI. There's actually a team I've worked with that I believe would find something like this useful in the Asset Store.

Here are some questions: Can it be cached? Can it be converted to a UXML based interface? On the other hand, how much can the interface change at runtime? Does it support adding and removing elements in play mode? How do you update the interface with new data if you don't have access to a panel hierarchy? Thanks.

 

Ok, so I am just going to answer your questions in chronological order:

1. Can it be cached?
Both yes and no. Unity destroys VisualElements on domain reload, meaning that VisualElements has to be regenerated when you re-enter unity after doing code changes and when you enter playmode. Apart from that, elements are cached, and the repaint event (All elements generated and hierarchy constructed) only has to be called once. When you change a CanvasElement in the editor, only its VisualElement reference is updated, which is virtually instantaneous. If you change a style asset there is no simple way of knowing what elements should be updated, so the entire canvas updates its layout (Graphs are not re-generated, but elements can change color, size etc.). The repaint event takes about 5-10 ms on my laptop with this interface while the layout update takes about 1ms.

2. Can it be converted to UXML based interface?
No, not at the moment, but you can inject VisualTrees/UXML made in the UI Builder into the interface. Unsure if I will add support for it at all as there is more to it than just static visual elements (Graphs, Carousels, Buttons etc.) that would be tricky and pointless to convert as they would lose their dynamic.

3. How much of the interface can change at runtime?
Everything in the interface can be changed at runtime.

4. Does it support adding and removing elements in play mode?
Yes. You can add, remove, hide and show elements as well as disable and enable them. One thing that is not yet supported is prefabs, but I think I know what needs to be fixed to make it work.

5. How do you update the interface if you don't have access to the panel hierarchy?
If you just want to refresh the entire canvas, then you can call a static event with no references needed. If you want to update the element associated with a CanvasElement, you only need the reference to that CanvasElement. You can also find elements based on ID, although I do need to add user overrides as the current IDs are randomly generated.

I hope this answered you questions, and if you have more questions or need some more information on one of them, then feel free to ask.

 

Small Update:
Prefabs turned out to be hard to work with, so instead of supporting them, I will make a graph based tool to create hierarchies of elements. Think I'll call it Interface Graph. Here is a small preview which is the result of an afternoon's work:

 

I like the idea of an interface graph. The ability to build procedural elements from nodes could be a powerful workflow. It would be really cool if you could give users a way to make custom nodes that produce VisualElements. Something like you make an inventory item node, then connect that to a draggable node, then connect that to a list node that generates items connected to it. Sort of like how ListView has a make item delegate.

 

Good idea. Currently it is very easy to make custom nodes. Just derive from InterfaceNode and make variables you want as input ports start with “input” and output ports “output”. The graph will take care of compatibility and neither “input” nor “output” will be visible in the displayed node.

 

Day 2 Progress Update