Few things feel like I’m missing when using Slate to make widgets. I’m completely new to it but besides these things I have no issues making my UI.
There are dotted border lines for each object displaying the area used. That’s fine for construction but how do I turn them off to get a good preview of my widget?
If I want to change an option, for example ‘Is Enabled’ under ‘Behavior’ for multiple objects, how do I do that? Every time I change values for multiple objects I seem to have to do it one by one.
Is there a way to round the edges of a Border element? I have resorted to using images so it’s really just convenience.
None of that is possible right now, but UMG is still an infant. Give it some time for these kinds of features. Though I suspect 3 will never happen because UMG supports 9-slice sprites. An image is the way to go in that situation.
I know for a fact multi-edit is being worked on. Patience
Yeah, it’s UMG. But I only know that because I googled UMG, doesn’t seem to be called that in the engine.
3 is a convenience and I ended up using images, so that’s fine, was just being hopeful.
I hope they will also make a much more intuitive way to position widgets when they’re relevant to objects in the game world such as a name tag / health bar floating above a player. I’ve got it going but was a hassle.
Edit:
Another huge issue, or bug, is that the colors I give the elements in the editor are always considerably different in game, noticeably darker/desaturated values. I’ve removed every form of post processing.
Edit2:
Text doesn’t seem to have the ability to shrink to match it’s container?
It… wiggles on the screen. When my character walks if it’s matching his position the elements jiggle around Looks terrible.
Indeed, after 2 weekends of fighting UMG infancy problems, I went for my own gui blueprint. I attached everything to camera in pawn, and gui is full in 3d. Luckily my game is very simple and does not need complicated gui. This way I have all touch events, objects, buttons etc in one single blueprint.
I will play again with UMG when it gets more mature.
Btw. what annoyed me most in umg is fact that all blueprints (bind events) are spread all over different graphs. Cannot easily just connect some actions together, it all needs custom events or functions. Yes its good for forcing users to keep some order, but then sometimes there is a problem that requires a bit of mess, and in UMG either you have event or action, or can get variable but cannot cast event etc.
PS. material collection parameters were not correctly transfered to umg, this is also one big problem. However i could do some mistakes in that graph.
Well, UMG is based on Slate. You can think of UMG as a child of Slate in the human sense. Coders usually use Slate while visual people tend to prefer UMG, though most Slate stuff can be done in BP.
As of 4.6, there actually IS a more intuitive way to position widgets in the world. Slate uses absolute integer values for screen position in pixel-space, so there tends to be a sense of “snap” and “jiggle.” In 4.6, we were introduced to the component-based 3D UserWidget. This widget moves in world-space, so you can expect smooth motion and occlusion, but too many of these in the world can kill performance, so be careful. The last stream talks about how to use the experimental feature: https://www.youtube.com/watch?v=dsrZgmv23Yc
Colors in general seem off to me, or at least different between editor and standalone. Does it really seem UMG-specific to you or is this discoloration prevalent in your whole game?
Text’s inability to shrink to the container is a bummer, though. It’s not so bad if you’re only working in one language, but it’s pretty damning if you plan to localize. It seems like a pretty big oversight so I can’t imagine it’s not on the to-do list but I have no evidence that it is.
Thanks for all the information, definitely going to be keeping an eye on UMG’s progress.
Perhaps I am asking the wrong question especially if having a lot of world space widgets in 4.6 cause performance issues.
I am working on a game that will have a lot of monsters/players in the world and was planning to use UMG for nameplates. If having a lot of them kills performance, what would you recommend I do for these? I think perhaps I should just shove em on the pawns themselves as a plane with mat/texture.
Player doesn’t need to interact with them, they change based on the name, health, mana, level, etc so having them on the pawn makes sense anyway.
Well darn, . You and the team put together all these amazing tools and nobody knows how to use them!
I’ve used to component Widget with a whole bunch of actors and it really only started to hurt performance around the 50th instance on my old laptop. I imagine for Mobile, if it even runs on mobile, will suffer much more quickly.
The method you’re talking about will actually be very performant, but could end up being a lot of work. You can probably get away with instancing a bunch of component Widgets as long as you’re not targeting mobile or using too many.
The most performant method is to set the screen space position of the widget every frame using World to Screen Point, but you don’t get stuff like occlusion out of the box. You’ll have to do some fancy raycasting to figure out whether your player should be able to see the widget and set it to be visible/not visible depending on that, which itself can get expensive. If you don’t care about occlusion though, that’s the way to go.
This may be the best option for me because I’m already doing the ‘fancy raycasting’ for other purposes, if the player can’t see the pawn, it’s not rendered - turning off the nameplate as well would be child’s play
However, since the ‘fancy raycasting’ system isn’t set in stone, it may change and no longer be suitable. Time will tell.
Edit:
In regards to the jiggling widget, using this method wouldn’t solve that, would it?
Unfortunately not, you’re still going to incur some integer snapping. Or at least, it did for me last time I tried it. I don’t know if there’s some kind of hacky way around this, like some kind of supersampling in which the widget thinks the viewport is a much higher resolution than it is because of course with a higher resolution, you visibly snap less since you have a higher number of pixels to snap to. Maybe Mr. Darnell or another person in UMG can shed some light?
Disclaimer: It’s also possible I have no idea what I’m talking about.
Looks terrible.
