Intended Usage of Button Styles, Text Styles and Material Animations

Development Programming & Scripting UI
, ,
1

Hello, we’re trying to understand the best practices for using Button Styles, Text Styles, and Material Animations. We’re looking to do the bulk of our animation on buttons via material parameters.

We’re referencing the Lyra project and when looking at it, button styles and text styles are at a minimum, with button styles not being used for the bulk of widgets that rely on material animations.

  1. We want to use the Common Button Widgets since they have more events and work with Common Input, but it requires a style. If one isn’t provided, UMG draws a gray background for the button by default. Is the intended behavior to set a “transparent” button style when you don’t want to use the style system (what Lyra does)?
  2. Should we be using Button Styles if we intend to do Material Parameter animations? We ran into difficulties accessing material parameters within the style vs traditional material setup, and noticed that Lyra skips the Button Style system entirely in these cases.
  3. If we should be using Text Styles, how should we approach dynamically updating properties of a Text Style, like color, when we want to modify it for a particular widget? We would like to avoid creating a new text style every time we need a set a new color if possible.
    1. Ex: We have a Button where our Text color should change based on the Hover State - With the color embedded into the Text Style, this looks like it requires us to set up separate styles with duplicate info except for the color value change, which then needs to be changed either in the animation timeline or the blueprint.
  4. What is the intended use for Text Styles within the Button Styles since there doesn’t seem to be any binded behavior that links this style to the button label. Is this meant to just be an accessible property in the style, that is manipulated via the button widget’s blueprint?
2

Steps to Reproduce

3

Hi,

The Lyra approach is similar to how we handle this in Fortnite, where we use an empty style for widgets that will be animated via materials. We’ll typically use materials for continuous, performance critical animations (like button animations) while using the traditional Sequencer-based animations for larger transitions involving multiple widgets.

Styles aren’t particularly dynamic as you’ve mentioned, and are intended to be swapped out instead of directly accessing properties to change them at runtime. Our designers tend to use overlays and include image widgets to inject materials with parameters that they want to animate via Sequencer. You can think of the style (if you choose to use one) as the base state of the button, with image widgets within the hierarchy used to display materials that will be animated for the different states.

Similar to buttons styles, it’ll likely be easiest to avoid using text styles if you need to directly animate those properties. As you mentioned, the main idea there was just to be able to make something available (typically in a C++ base class) for derived blueprints to access and use as needed, though I don’t know that we use that approach too often.

Best,

Cody