UMG vs Slate vs Canvas

Honestly which is the best option to use to make a HUD? Looking for best customization.

1 Like

Umg is your way to go

Bit of a strange question. A canvas is just one small component of the UMG which, in turn, is a visual editor for Slate.

What do you mean by best customisation? UMG has its limits, once/if you hit them, you can start messing about with Slate.

For something very simplistic, the HUD class might be enough; UMG can be fairly powerful if you can live with its quirks; Slate documentation was incomplete last time I checked. Haven’t checked in a while, though.

1 Like

Going a little necro on this post :roll_eyes:

@Everynone I think the Canvas @ZackReganSounds is talking about is UCanvas (not related to UMG or Slate), while you are referring to UCanvasPanel (the panel you see in the UMG editor). There’s also SPanel (the base class of container widgets in Slate) and SCanvas (an SPanel sub-class that implements arbitrary layout for each of its collection items).

@Mootjuh, if you’re just learning Unreal or don’t know C++, I agree UMG is the best choice. However, I don’t think there is a best choice for all situations. Rather, it depends on what you’re trying to do and how you are integrating the UI with the rest of the game.

UMG (Blueprints or C++) and Slate (C++ only) are both widget toolkits. They give you objects that don’t just draw, but provide UI functionality like text edit boxes, grid layout, canvas layout, spinners/throbbers, etc. Both frameworks have an opinionated way to arrange and draw items, which creates a consistent (relatively easy) way to develop a new UMG/Slate widget and have it work along side your other UMG/Slate widgets. Many Slate items are wrapped by UWidget (the C++ class for UMG widgets). It’s also easy to wrap your own Slate C++ widgets in a UWidget to expose it to UMG. UMG is built directly on top of Slate. In fact, one of the primary things a UMG widget has to do is override the UWidget::RebuildWidget function to construct the underlying Slate widget.

UCanvas, on the other hand, is like a painting program. You can do things like draw text and images. UCanvas is used by the AHUD actor, but it’s also used other places in the engine to provide debug graph overlays. It’s easy to understand, but as your UI code grows you will have to coordinate all your drawing code, and, if you don’t give it enough thought, you’ll probably end up coming up with something like a poor man’s version of Slate/UMG.

My recommendations are:

  • If your game is primarily blueprints, use UMG.
  • If your game has a lot of C++, use UMG and write custom Slate components exposed to UMG as needed.
  • Create a UMG widget called HUD that you use as the top level container for all your widgets so you can use the UMG editor to layout all your widgets.
  • For each widget you build:
    • Implement a widget in UMG if everything the widget needs is already exposed to Blueprints and is simple (in terms of blueprint graph node count).
    • Implement a widget in Slate if it needs to call a into a lot of C++ code that isn’t exposed to blueprints, or is complex (in terms of blueprint graph node count). The complexity thing is a personal preference of mine as I find it easier to manage many lines of C++ code than managing many Blueprint graph nodes.

Also:

  • If you want to layout your UI completely in C++, use Slate. In this situation, you’re probably not going to use UMG at all.
  • If you want to layout your UI visually in an editor, use UMG. In this situation, you can still write your own custom Slate widgets in C++, but you’ll also need to wrap them in UWidgets.
  • If you don’t know UMG or Slate and your UI is very simple and you know your UI isn’t going to change much, maybe use UCanvas. This recommendation is only to save you time from unnecessarily having to learn UMG or Slate.
46 Likes

That’s a slamming summary of the use cases, thank you!

1 Like

Thank you for the detailed explanation!

I struggled to get a bird’s eye view of the relationship between UMG and Slate, your post really clear things up for me! :slight_smile:

1 Like

One last option (I don’t think its covered UCanvas?) is drawing text and images directly in the HUD class by C++.

HUD->DrawMaterial()
HUD->DrawTexture()
HUD->DrawText()

If you really want you can create your own UI system with just those.

You can do it in BPs, too. There’s some unique functionality hidden in the HUD. Hit Boxes, for example. Drawing triangles. And many more.

1 Like

Think of this as your opportunity to shine even brighter! :wink: The best part is that this amazing answer was triggered by a rather generic post:

the best option to use to make a HUD? Looking for best customization.

So yeah, more Doug, please.

4 Likes

Yes Please, more Doug!

2 Likes

Those are convenience wrappers around the AHUD’s internal UCanvas. For example, here’s the implementation of AHUD::DrawMaterial as of 4.26.2:

void AHUD::DrawMaterial(UMaterialInterface* Material, float ScreenX, float ScreenY, float ScreenW, float ScreenH, float MaterialU, float MaterialV, float MaterialUWidth, float MaterialVHeight, float Scale, bool bScalePosition, float Rotation, FVector2D RotPivot)
{
	if (IsCanvasValid_WarnIfNot() && Material)
	{
		FCanvasTileItem TileItem(FVector2D(ScreenX, ScreenY), Material->GetRenderProxy(), FVector2D(ScreenW, ScreenH) * Scale, FVector2D(MaterialU, MaterialV), FVector2D(MaterialU + MaterialUWidth, MaterialV + MaterialVHeight));
		TileItem.Rotation = FRotator(0, Rotation, 0);
		TileItem.PivotPoint = RotPivot;
		if (bScalePosition)
		{
			TileItem.Position *= Scale;
		}
		Canvas->DrawItem(TileItem);
	}
}

2 Likes

Unfortunately, this is a side effect of a rapidly growing community. It might look like a lemon, but maybe it’s actually supplies to make lemonade…