UMG - Text alignment & scaling issue

Hi,

After the migration to 4.8, most of the text are not anymore in the right places.
My Text are inside scalebox to manage the different client resolution and it seems that something has changed in the way it is processed.

As a side effect, the Text alignment are not good.

For example, if you set a text to be centered in 1080p resolution when downsizing to 1024*768, the text is not centered anymore inside the box.

I will try to put for screen later on but is it somethign you are aware of? Did you change soemthing in the Scaling process, font management?
For my perspective, it seems that you are adapting the font size to be able to render it correctly inside the new “text box size” but you are not applying the alignment after the font size change.

To reproduce:

Add a scalebox
Add a Sizebox in it to fill the 1080p resolution
add in it a canvas at the top of your ui.
Set a Label centered in the canvas centered horizontally (fixed postion & width & height) with TextAlinment Center
Add a default text in it that will fill out mostly the box size

Play with the different resolution so the scale box must scale down the whole UI and look at the text, it should scale properly but you will see that it’s not center aligned anymore

Are you able to reproduce this?

Thanks,

Hello,

I could not reproduce this issue on our end with the steps provided. I have a few questions for you that will help narrow down what issue it is that you are experiencing.

Quick questions:

  1. Can you reproduce this issue in a clean project?
  2. Could you provide a screen shot of your widget (please include the widget hierarchy)?
  3. Could you provide a screen shot of the issue that you are seeing (this will help insure that we are seeing the same issue)?

Here are some informations:
My global Setup:

47404-score1080.png

1080p view:

47405-score21080.png

720p view:

47406-score720.png

Time text setup:

47407-scoretimesetup.png

47408-scoretimesetup2.png

Yes I can repro the bug in a new project

Here are 2 asset to put in your project [link text][1]
In the core asset, just put the Slot Fill size to 0.16 and to 0.05 and you will see my the text moving from centered align moving to right side.

Could you please confirm the repro on your side?

Why all the extra boxes? Extra vertical boxes, horizontal boxes…etc?

Anyway, this appears to be an artifact of how you’ve configured the text’s slot in the [Sic] TExt asset. Your Size Box Slot that the text occupies should be set to Center, and not Fill. In theory Fill, with a center justification should be the same, but that appears to not be the case.

Text layout is hard.

Here you just have a part of the Full UI. This is why the extra boxes seems a lot.

If I remember properly:
if you don’t set to Fill, depanding of the time text value, the width is not constant so the text will move.
We need to have a fix Text size in order to be able to fix this.

Can we say that’s a bug?
It wasn’t the case in 4.7, so something have changed in the calculation.

Out of this, if you have a better way to manage a complex in game UI should adapt to different screen, I’m please to learn because I have no “real” example.

I’m using a lot the different container with fill percentage so it adapts automatically and manage to scale with Scalebox inside the slot.

1 Like

Hello,

Could you try using center alignment for your text block? I was able to reproduce this issue on our end. I have written up a report (UE-17530) and I have submitted it to the developers for further consideration. I will provide updates with any pertinent information as it becomes available. Thank you for your information and time.

Make it a great day

It’s an artifact of the layout caching we added in 4.8 to improve performance of text in slate. Previously it did a ton of layout calculations every frame. However the cache doesn’t (possibly can’t) include the scale that will come from the scalebox, because can only be calculated later, after the text has cached its size first. It’s a chicken and egg problem. It’s possible we can run another layout cache inside the scalebox to avoid this kind of problem, but dunno, that’s going to require some research/trial and error I suspect.

Your best bet is to keep the problems you throw at the scalebox very simple. It was never designed to solve the problem of properly scaling a deep hierarchy of child widgets. It barely handles text, because text doesn’t scale linearly due to kerning / layout hinting.

Thanks for your comment and updated on this. Now I understand the root cause.
What are Epic Best pratices to manage the scaling? What are the solution to solve this issue?
Let’s take this case:
You have a clock with a background image. You want it to take 200*100 pixel at 1080p resolution and scale uniformly on other resolutions.

I bet you have this kind of stuff on Fortnite or other game?
I don’t look at UT, as they are not using umg but just the Canvas approach with customwidget scaling.
Is it the recommended way to do InGame UI?

Thanks,

Thanks for logging the issue.
We clearly need a fix or a way to solve this simple problem for InGame UI.

That’s not what the Scale Box is for. What you’re describing is the scaling we apply to all widgets based on your DPI scale curve configured in your projects user interface settings.

The scale box is intended to solve the problem of fitting an image or text block to a predefined area, that’s generally smaller or larger than the content, but you need the content to maintain a proper fit to the available area.

Oh!! So I must have miss something.
I knew about the curve, I read again the docs but I can’t get how it works.
I mean where/how are you defining that the current content has been set for a 1080p native resolution so the curve scale on lower or higher resolution?
Could you please post a quick sample on I should have set my sample UI to get a Text center inside the Backgound image and it scales with resolution?

thanks,

You just make the UI however you want to make it; you can change the preview screen size in the designer to see what it looks like at different resolutions with your current curve. The curve plots resolution on X, and scale on Y. Edit accordingly, the default curve uses 1080p as a scale of 1, and scales linearly up and down from there.

The sizes of widgets are always in Slate Units. Which is the unit of measurement separate from pixels or scaling. At a scale of 1, a 100x100 slate unit box is 100x100 px, at a scale of 2, it’s 200x200.

I will make a pass on my UI following this comment and try to get it working.

Thanks for having taking the time to anwser me on this.
I bet it will be clearly easier to do the UI now, than putting scalebox and so on everywhere to manage this ^^

Following Nick’s comment.
We may have improvment to do on the ScaleBox, but it clearly seems also that I misunderstood how the DPI Scaling was working in UMG.

Ok it’s working.
For any reasons, I had a bad curve set in my ini file so the DPI scale stay at 1.0 for all resolutions.
But on the Config screen in the edior I was able to see the standard linear curve.

Now I fix this and everything is working as intended.
Thanks!

Hello,

I am happy to hear that you have gotten your UMG working the way that you would like. If this issue returns please feel free to update this thread

Make it a great day

Thing is, this is not a solution that will cover all the possible cases. I didn’t find this topic earlier, but I’d sure as hell bump it if I did.

The mapping that is there says: “give me the X resolution and I’ll apply the scale to both coordinates”. This does not work well. There are many resolutions that share the X size, but have different Y sizes, in which case the engine detects X and scales the Y and X not even checking what Y is.

1920x1080 and 1920x1200 (16:10) is one example. 1920x1080 and 2048x1080 is another case - Y is the same but X changes. The second one you could theoretically hack by spamming tons of points on the curve, but the first one is unavoidable.

If you really want people to stop using scaleboxes for such complex problems (which is what I’m doing all the time and have a pile of bug reports that just wait for me to have time to properly report them with examples) then maybe make the mapping like this:

“For given X resolution size scale X by XScale” && “For given Y resolution size scale Y by YScale”. This way you will cover all the possibilities. But this is also not ideal. Problem with this is that if you want to keep square a square for all resolutions, this will not work.

So, maybe “For given X:Y pair, scale by Z”. This would require a bit tweaking and wouldn’t look perfectly the same everywhere, but would preserve shape. Still, it would be impossible to ‘Fill’ the entire screen with the UI on each resolution, like in RTS games.

Thus the scaleboxes. They do manage to get the job done, although setting them up in a way that’s not bugged is painful and often impossible with more complex UI’s. If they’re so expensive then be it, but that’s the only way it works right now.

I don’t see a solution that will work with the DPI scale. Scaleboxes would cover that case if they worked well enough.

It’s unlikely that we’ll be adding non-uniform scaling to the UI. That’s definitely not the approach you’d want to take across platforms, your UI would look generally wrong on most platforms just because the user is on a cinema display (21:9), you’d end up radically stretching in the X direction.

What we need is access to the true physical pixel density of the screen, but not every device / OS can, or truthfully provides it. That would make it so that two devices with the same resolution, but vastly different physical dimensions could be scaled appropriately.

In any event - the DPI system ships with a solution for custom rules. If you’d like to implement a different solution that suits your needs, you only need to provide a subclass of UDPICustomScalingRule that overrides the GetDPIScaleBasedOnSize function and changing the scaling rule to Custom instead of Shortest Side or whatever. You’ll still be locked to uniform scaling, but other than that you’re free to check whatever you’d like on the platform to determine the right scale to use.

Hey guys, iam not sure that the issue iam facing is related to scale box or not, but my ui is designed inside the scale box, iam having an Ios app, which when runs on a device, have blurry ui (not clear images), iam using a texture file of 160x160 resolution, having ui as texture group and user interface 2d as compression settings and no mipmaps. My dpi scaling is default.
The app is tested on iPhone se and images were not sharp, while the meshes were clear and sharp.

In a new project, When we tried to create an ipa having some buttons and logos using the images from the above mentioned project, we got crystal clear ui, while the images in the ui are having same compression settings and same structure inside the UMG . This new project have default project settings.
Images are clear and sharp.
Please if anyone could guide, if my issue is related to scalebox or is it something else?
Thank you.