Can we talk about UMG?

Hi guys,

Been using UE4 to do an enterprise project over the last couple of weeks and the whole things is great. Everything is as powerful as you need it yet you can throw together simple things stupidly quick. Blueprints make code writing just easier for anything that isn’t speed critical and it tends to be more bug free on the first runthrough.

And there is UMG.

It just feels aweful to use. I’m not sure if I just don’t get it, but I’ve used a few IDE’s to make Windows GUI Applications and they’re just so much better. Even Eclipse and that has to try and work around Java (ok this one took a bit of getting used too).

Can’t you copy / improve upon any other IDE’s method of making GUI’s? They’re basically identical in function (from my limited knowledge).

I’m sure UMG is powerful and la-di-da but you should be able to pick it up and use it. You’re designing a UI, not writing spaceship code. And most of the tutorials I’ve seen are somewhat poor and I’m struggling to pickup UMG’s grouping etc. from any of them. Why can I place a horizontal bar, and then put buttons in it, and then the buttons are 3 px wide. Why cant I then make the buttons all a uniform size inside this horizontal bar. I can scale an individual button, but have absolutely no idea how to make the buttons all the same size when their size seems to be based on the text in them and funnily enough the text in each of my buttons is different. So now I’m using an absolute layout but nothing seems to snap into location. There doesn’t seem to be any grid at all so now the buttons all look like **** because they’re all wonky. So now you copy a button and put it down, great they’re aligned. How the **** do I now make anything else the same size without manually editing the size of the buttons. Now I’ve got to manually change the button size everytime I want to change them. I just wanted to make the image I put in below. And now looking at it, it still looks wrong.

And to make the image below, I had a good hour looking at tutorials to try and get everything in the panels but they just don’t seem to make sense and none of the tutorials seem to be using them? Probably because they’re ****ing impossible to use. If I was to load up even Delphi I could throw something that looked semi-legit in about 30 seconds. I could get someone that’s never used Delphi to watch a tutorial and do it in 5 or even 10. And the end product has the exact same functionality so don’t try telling me “Oh hahah it’s Delphi” if it works it ****ing works.

Sorry, I’m just still frustrated that it took me so long to do that. Maybe I’m just stupid.

PS the post icons on the forum are slightly wrong. Mousing over the thumbs down gives a “thumbs up” context menu and the thumbs up one doesn’t have any. All the others seem ok

UMG is definitely frustrating, tedius to use, and at first confusing. It’s more complex than it ought to be, it feels like. Stuff like make a controller select the next node takes forever to design. I hate it lol.

One thing you can’t call umg is intuitive. Also there are still issues with buttons messing with virtual joystick values on mobile since the beginning.

I agree that it could use some love, but probably the most useful things for Epic to hear would be specific features/steps that could be used to make it better.

For me, I think that abstracting draw order by using the ‘layer’ paradigm would be easier for most people to understand.

I think I might have made some sort of progress on working out this labyrinth of design.

To put a button inside a Horizontal Box, and to be able to control the buttons size, I must put the button inside a size box inside a horizontal box? Is this the correct way of doing this? Actually everything seems significantly better now that I’ve found this size box.

Also does anyone know what the “Safe Zone” under panel does? I’m assuming it doesn’t load up tumblr on your UI but does something useful (there’s no tooltip)

Ask me all you need to know about UMG. It helps when you begin to understand the core concepts (which are the same as Slate), which aren’t obvious at first. UMG isn’t very intuitive because it’s an UI for creating Slate widgets. Slate, on the other hand, is a declarative way to build UI elements in code. Since you don’t want to be manually setting pixel locations and dimensions in code, Slate is built nearly entirely on automatic adaptable layouts, and that carried over to UMG as well. It’s bewildering at first, yes, but it’s quite powerful when you get you head around how it actually works.

To get a grasp at the whole widget sizing thing you first need to learn about Slots. In UMG, widgets that can have children provide Slots to “host” children widgets. When you create an HorizontalBox and add other widgets to it, a slot is automatically allocated to hold each child. Some widgets like the SizeBox, for example, only have a single slot and therefore only accept one child.

So, what do those slots do? Basically, they are the ones responsible for laying out the widgets. They determine where these widgets will be placed in relation to their parent and how much space they will occupy. Widgets, by themselves, have no such properties like position and size (they can report a “desired size” to their parent, we’ll get to that in a bit), it’s the slot that decides that. As you found out, for example, a widget like the SizeBox widget can control (and override) the size of it’s child widget. A Canvas widget allows manual placement of a number of widgets inside them with flexible anchoring logic. An Overlay widget, on the contrary, has much simpler positioning controls (only alignment), so it’s useful when you just need a few overlapped widgets. The horizontal and vertical boxes allows multiple widgets to be stacked against each other. And so on. When you select a widget, the first section in the details panel (called “Slot”) is actually showing the properties of the slot that contains the widget. You can see that they are different depending on the parent type: the slot properties for a Canvas are very different than the ones for an HorizontalBox.

Getting back to size: I mentioned before a widget can report a desired size to it’s parent. The Image and Text widgets are the ones that do this inherently. Image widgets will report their brush image size as their desired size, while text widgets will calculate their size based on their text content. Then the parent widget will decide what to do with that information. The Button widget will use that size to adjust it’s brush, add it’s content padding value and bubble the result up to it’s parent. If the parent is an horizontal box, it will use that size to stack its children horizontally (or not, if you set the child’s slot “size” property to “fill”, in which case that widget will be forced to fill whatever space is left after stacking).

The SizeBox, for example, can override the child’s desired size completely, or be told to clamp it to a minimum and/or maximum value. The result will be bubbled up to the next parent.

A very useful too to work with UMG is to create your own reusable widgets. For example, you can create your own button that has a fixed size so you don’t have to keep adding SizeBoxes all over the place. It also allows you to be able to change all button’s images in a single place, or to add animations to all of them. You do this using the NamedSlot feature. Here’s an example:

First I created a button, then I right-clicked it and “wrapped” it around the size box, which I set to 250x75. Then I added a NamedSlot to the button and named it “Content”. To make things more convenient, I wrapped the NamedSlot around a ScaleBox so it will downscale the button’s content to fit the button. I also wrapped everything around an Overlay to make the SizeBox center itself instead of expanding to fill it’s container.

This is how it looks when used:
The text blocks inside both buttons have the same font size, but the one in the right was automatically resized to fit the button because of the large image next to it.

I never used it, but I am pretty sure it’s to add a “TV overscan” safe zone around it’s content. Probably goes in the root of your widgets to make sure nothing touches the TV borders and risks getting cut if overscan is enabled.

I’ve been messing around in UMG and it’s starting to make a lot more sense, especially once you stop thinking about it as a GUI editor (which is likely where I was going wrong). It should probably be renamed, just so it’s blatantly obvious when you’re starting that everything is scalable. That seems to be the biggest missconception (I had at least).

Anchors are strange and take up way too much screen space, but once I started to get what they meant I like it a lot more. I’m amazed there’s no way to toggle anchor visibility (again from what I’ve seen) so I can actually see what I’m trying to place.

I’m looking at making an interactable UI where objects are draggable among other things. I take it this is done by binding the onclick and moving the object with the mouse? Seems archaic but it works I guess. The object will be draggable along a timeline, so it shouldn’t be too hard to get the relevant co-ordinates and move it along.

One thing I’m curious about is attaching objects to the mouse - say I pickup an object in one widget, and want to move it around the screen, into another widget, and then drop it into a sub-box of a second widget (at runtime). Now that I’m saying this it sounds much harder than I expected. I’m guessing doing mouse co-ordinate magic again should solve most problems. The main question here is how to attach a widget to the mouse when moving it arbitrarily around the screen, especially when it starts off as a child(?) of another widget. I get that placing it is difficult but I think I can manage that. Please note that I can’t just destroy / create the widget again easily, as they are all dynamic and different each runtime based off of saved data from previous runs of the program.

What I’m trying to do would be much easier in a more specialist program but then I’d lose a lot of the functionality that I want from UE4, so I’m trying to hack it together and am not really using the engine how it was intended but it’s looking like it’ll work. Eventually.

Thanks for your time anyway

PS Could anchors have two modes - one for on the object and one for on the screen. I know you can modify the alignment between 0-1 but it would be so much easier if I could drag the anchor or click a button so I can click on the object where I want the anchor to centre on the object instead of the screen. This is only important because I’m using text which is updating itself so the anchor position would be off (I want it to be centered) when the text updates

Once you “get” UMG you will be a lot happier working with it and see you can do a lot with it. I had the same problem with it, since it’s not as well documented as other things.

Layout and sizing is pretty annoying, I agree! Also, trying to snap multiple things into a canvas with same-width, same-center, and equal spacing, is not well supported, and getting the center-flower to be aligned for a number of widgets means having to type in numbers in the property sheet.

So, concrete things to improve:

  1. Make some smart default sizes for objects, even if they are empty. An empty button might always be at least 40 pixels wide, by default, and only go smaller if you change some “minimum width” property on it. Collapsing widgets just aren’t useful.

  2. Make aligning left/center/right of objects, and aligning top/center/bottom of objects, automatic while dragging any one object. Check out how Illustrator does this, for example! (Or just Visual Studio Forms editor)

  3. Make distributing the alignment flower/star/widget through the mouse possible. Centering it to a particular widget should have a positive “click” while dragging. Centering to a bunch of (already aligned) widgets should be selecting the widgets and pressing some key.

  4. Hotkeys for the common cases of “move the sizer flower widget to the center and collapsed” and “split the sizer flower widget into four and put them at the corners of this widget.”

if you want premade dialogue box (open file, confirm, info, select box, etc…), yep thats not included in UMG (look in the marketplace there is one, perhaps 2 assets available to deal with that).

so the start is a bit harsh, all need to be homemade, but for the rest it offers much freedom.

Thanks for pointing out about named slots. But my problem with this is that it still doesn’t help with making the text style of the button reusable, since the parent attaches the text with whatever style the parent wants.

So to make its style reusable, I had to make the whole button widget, including the text, my own widget. The parent can then set the text from outside and events are added via event dispatchers (delegation).

The only inconvience that I found (which can be a big deal while designing UI), is that the text that I set from the parent is not visible in the editor, only while playing. Any idea to get around this issue?