# \[Twitch\] Support Stream - Unreal Motion Graphics (UMG) UI - Oct. 21, 2014 **URL:** \ **Category:** Announcements\ **Tags:** unreal-engine, Event\ **Created:** [October 7, 2014, 9:53pm UTC](https://forums.unrealengine.com/t/twitch-support-stream-unreal-motion-graphics-umg-ui-oct-21-2014/12787 "2014-10-07T21:53:45Z")\ **Posts on this page:** 5\ **Page:** 3
**Author:** ![NickDarnell](https://d3kjluh73b9h9o.cloudfront.net/original/4X/2/8/5/28502927f1d97ba1051b3b47ccfe17233bf41ef0.png) [@NickDarnell](https://forums.unrealengine.com/u/NickDarnell)\ **Post date:** [October 22, 2014, 6:06pm UTC](https://forums.unrealengine.com/t/twitch-support-stream-unreal-motion-graphics-umg-ui-oct-21-2014/12787/41 "2014-10-22T18:06:57Z")
's the tutorial I said I would do a quick write up on in the stream on making widgets appear over actors in the world (but in screenspace). [https://forums.unrealengine.com/showthread.php?50130-UMG-Tutorial-Placing-Widgets-Over-Actors-In-Screenspace&p=167853](https://forums.unrealengine.com/showthread.php?50130-UMG-Tutorial-Placing-Widgets-Over-Actors-In-Screenspace&p=167853) ---
**Author:** ![RPotter](https://d3kjluh73b9h9o.cloudfront.net/original/4X/2/8/5/28502927f1d97ba1051b3b47ccfe17233bf41ef0.png) [@RPotter](https://forums.unrealengine.com/u/RPotter)\ **Post date:** [October 23, 2014, 2:12am UTC](https://forums.unrealengine.com/t/twitch-support-stream-unreal-motion-graphics-umg-ui-oct-21-2014/12787/42 "2014-10-23T02:12:06Z")
@NickDarnell Thanks for the stream, it’s good to see these things happening on a semi-regular basis. You mentioned on the stream about elaborating on some of the longer questions in the thread (including mine) after the stream, so I was wondering if you were still planning to do that. ---
**Author:** ![NickDarnell](https://d3kjluh73b9h9o.cloudfront.net/original/4X/2/8/5/28502927f1d97ba1051b3b47ccfe17233bf41ef0.png) [@NickDarnell](https://forums.unrealengine.com/u/NickDarnell)\ **Post date:** [October 23, 2014, 1:32pm UTC](https://forums.unrealengine.com/t/twitch-support-stream-unreal-motion-graphics-umg-ui-oct-21-2014/12787/43 "2014-10-23T13:32:34Z")
> [@RPotter](#): > > Why is binding on the widget class itself? It would be nice to be able to offer an alternate data source, in a more MVVM-style pattern. Furthermore, it would be nice to limit the actual evaluation of the data to only when it changes (or an event says to refresh it’s local value), as the evaluation might be expensive. You can certainly approximate this by adding a gate and resetting it when changes occur, but the main reason I want this is to reduce the amount of logic a UI artist has to implement themselves, as well as keep as much logic out of the widget BP (that doesn’t directly control what the widget is doing) as possible. Especially since these are binary assets, and right now a UI artist and engineer can’t effectively work on the same widget at the same time (not without a lot of pain, and a lot of boilerplate hookup: create a variable that is the data source, and create a function for _every_ data item that simply gets the data). The binding is on the widget itself because it’s easy to understand. Where it goes from there is up to you. Several people have chosen to define the logic inside a UUserWidget subclass in C++, then they simply bind the logic to themselves after reparenting the widget, keeps the logic in C++ and away from the UI designer. Others have chosen to pass a Model object into the widget that they sample in their bindings. Both of those routes require a C++ developer because Blueprints do not permit constructing arbitrary UObjects yet, but that’s likely to change soon. Future versions will probably allow bindings to be specified on a member object’s members to reduce having to make the extra step you mentioned. Evaluating only when data changes is a difficult thing to automatically determine. There’s the KnockoutJS approach which takes all bindings and simulates running them to determine all values accessed to determine the tree of possible values that could change and invalidate the UI. While that method is super slick - we don’t have any system in UE4 for doing anything like that. It’s also not how Slate works. Slate has TAttributes for generally any value on a widget to allow you to bind it to a function to massage the data for the UI, and always provide the latest data. Or to simply pass it a literal value to prevent calling a delegate. The whole UE4 editor is written with that approach. If you’d like to not have bindings run every frame it’s up to you, you can choose to use the Set\_\_\_\_\_\_ functions instead to assign the value when you’ve detected it has changed. We may come up with something slicker in the future that allows more customization about how the bindings work. If it’s expensive to evaluate, you could also build the cache into your View Model that you’re binding to the UI. > [@RPotter](#): > > I’m also a fan of defining resources (dictionaries of values) that can be bound to directly, allowing easier style switching. Styles right now seem specific to a widget hierarchy, which makes them not nearly as useful. Why aren’t the styles more modular? Why can’t you bind elements to shared parameters? Time. The plan is to build a modular system, in the mean time we’ll take steps to make things more reusable, like the named slot feature I mentioned in the stream. > [@RPotter](#): > > Less important, but still useful is the Visual State Manager, as seen in WPF. Being able to define states on a control (in a loose fashion), override those states, or add new ones on existing controls, and have the system auto generate transition animations is a _great_ productivity booster. You utilize similar state machines in other areas of the engine, would it be possible to utilize that for this? Maybe, but not any time soon. > [@RPotter](#): > > I’d also like to see vector support come in at some point. Although you can make items that _resize_ using things like N-slices, they don’t work for changing resolutions (the regions end up scaled down). Basically, every resolution you support needs its own asset, increasing the package size. It would be nice to have proper resolution-independent UI using vectors: if rasterizing them is considered a performance problem, why not just cache the results? Takes up the same memory the texture itself would need, and you can apply the cache to static sub-hierarchies (reducing total draw time overall). Selective retention is a great why to balance performance and visual quality. Just caching the result only works good for static UIs. I think it will be a lot of work to find a nice balance of caching vs. live rendering vs. lerping between generated mips during animations. I also think you’d encounter a lot of problems finding a good way to not cache too much, large full screen backgrounds on UIs - you wouldn’t want to cache the entire surface area, you’d actually want to N-Slice the sections of the vector graphics so that you don’t have to cache large sections of just a flat color. > [@RPotter](#): > > I know you guys have WPF experience over there, so I assume you must have at least considered all of these features at some point. As such, I am curious as to why you opted against them. Some of it’s philosophy differences, but a lot of it is time and resource constraints. ---
**Author:** ![Chooka](https://d3kjluh73b9h9o.cloudfront.net/original/4X/2/8/5/28502927f1d97ba1051b3b47ccfe17233bf41ef0.png) [@Chooka](https://forums.unrealengine.com/u/Chooka)\ **Post date:** [October 23, 2014, 1:55pm UTC](https://forums.unrealengine.com/t/twitch-support-stream-unreal-motion-graphics-umg-ui-oct-21-2014/12787/44 "2014-10-23T13:55:44Z")
> [@NickDarnell;168255](#): > > Both of those routes require a C++ developer because Blueprints do not permit constructing arbitrary UObjects yet, but that’s likely to change soon. i’m usually working with c++ and its not an issue but constructing UObjects from Blueprints would be very useful. can we have that asap. ---
**Author:** ![anonymous\_user\_4fe9f58b1](https://d3kjluh73b9h9o.cloudfront.net/original/4X/2/8/5/28502927f1d97ba1051b3b47ccfe17233bf41ef0.png) [@anonymous\_user\_4fe9f58b1](https://forums.unrealengine.com/u/anonymous_user_4fe9f58b1)\ **Post date:** [October 26, 2014, 8:15pm UTC](https://forums.unrealengine.com/t/twitch-support-stream-unreal-motion-graphics-umg-ui-oct-21-2014/12787/45 "2014-10-26T20:15:29Z")
I just finished watching the archived stream and there is one subject I’d like to expand on that was briefly mentioned. Matt mentions one eventual performance improvement would be to automatically atlas textures. What about premade atlas textures? Most of our HUD elements are already atlas’d and delimited through FCanvasIcons defined in our AHUD actor. But I couldn’t find a way to recreate the equivalent in UMG using either an asset type or a widget. [Previous page](https://forums.unrealengine.com/t/twitch-support-stream-unreal-motion-graphics-umg-ui-oct-21-2014/12787.md?page=2)