I’m trying to learn in a bit more detail the nuances of User Interface using Unreal Engine’s UMG. For that, I’m starting with reviewing some free content from the marketplace, such as this Inventory System. And I came up with a question I’ve been trying to answer for a while now. The project has a blueprint for item slots. Its designer tab looks like this:
As you can see, the creator doesn’t use a canvas panel, which makes sense because this widget won’t be displayed at full screen. My question is, how can you resize the top-level overlay so that it has exactly the same size as the ItemSlot image contained inside it without applying transformations to it?
I guess that a more generic way of putting this is: How can I set the size of a widget according to the size of one of its children without a Canvas Panel in sight?
You can punch the size here if you know it upfront:
This is just a preview. This widget will now behave as if it was in a slot with those dimensions.
How can I set the size of a widget according to the size of one of its children without a Canvas Panel in sight?
This is another question altogether. Once a widget sits in a slot, it reports a desired size, the parent may or may not respect that. One way to ensure the child reports a specific size is to wrap the child (or the content of the Overlay) with a size box and punch it min / max values. After this, the parent will (try to) respect those.
In the example you show, the preview is set to Desired on Screen => one of the elements in the hierarchy requested that size (probably an image), like so:
Thank you for the detailed answer, this is exactly what I was looking for. I’m marking this as the answer, but just a couple of follow-up questions, if you don’t mind. Let me know if it’s too much and I’ll create another post for them.
From what I understand from your explanation of a size box, could we say that a widget will take the full screen when none of its childs, nor itself, specifies a size?
In the case a size is specified, is this propagated upwards along the widget hierarchy? If so, I understand that, if a widget specifies a size, the size propagated by its childs will be directly ignored. Is this true? And, then, could we say that a size box is useful when there are size conflicts (e.g.: two widgets at the same hierarchy level specify different sizes)?
Yes, it will try by default but it’s more about the preview itself! It’s all in this very panel:
By default it’s set to Fill Screen… so the widget you’re working on fills the screen. But once it’s put into another slot, that slot will take over and size it accordingly, respecting the Desired Size as best as it can.
In the case a size is specified, is this propagated upwards along the widget hierarchy?
Yes, it’s called Desired Size, and the child will report it to the parent slot:
this widget (called Options) is just an image in the hierarchy and has a desired size of 128x32:
The overlay knows the desired size of Options and respects it, even though it’s filling the screen itself. If we dropped this overlay into yet another widget, the Desired Size will still be propagated.
if a widget specifies a size, the size propagated by its childs will be directly ignored. Is this true?
It will be ignored when the slot is not large enough or the parent overrides the child’s Desired Size (because it can).
this image is 256x256, if I try to cram it into a 128x64 slot, the slot will squish the child, there’s not enough space and the desired size is completely ignored:
below, the 384x384 slot has more than enough space for a 256x256 child, the desired size is respected:
similar situation below, the 384x384 slot has more than enough space for a 256x256 child but the slot decided to override the desired size of the child:
Now the 256x256 child is actually stretched to 384x384. Even if you wrapped it with a Size Box and forced arbitrary values, the parent will have the final say in all this.
You, as a designer, get to choose. You can actually choose to overflow the slot, too.
I have a 256x128 slot that is too small for a 256x256 child but I modfied the slot so it allows the child to oveflow:
Allowing us to achieve some more interesting behaviours.
And, then, could we say that a size box is useful when there are size conflicts (e.g.: two widgets at the same hierarchy level specify different sizes)?
Precisely, if you have an image that is 128x64 but want the widget to behave as if it had different dimension, a Size Box can provide a Desired Size for slots to use. But the final call of how things are laid out always belongs to the parent - to the slot the parent created for the child. Not all slots are the same - canvas creates slots with unique functionality. Wrap box does some crazy things with its slots, too.
In short:
the child says “I want to be this size”
the parent’s slot says “I understand how big you’re trying to be” and:
Or it will stamp the foot down and make a picture for ants instead…
Thanks a lot for this really amazing answer. It’s been a pleasure to read it, and you even included a short vid to demonstrate what you meant. Really awesome stuff.
I understand it now, thank you very very much for all the help!
