UMG 3D Widget used in Paragon?

Hey guys, I was curious what Epic used for the healthbar above the minions head in Paragon. I assume it was a 3D widget, but I recall that in a Paragon stream a brief comment was made that a new “Widget” was made to do it for performance? If so, what is this new widget and where to access it cause I haven’t found any info on it?

Maybe Nick or someone could explain more?

Thanks!

SMeshWidget. You need to be a talented technical artist, be adept at C++ and have awesome material skills / understand packing data for shaders to make use of it. We don’t use the WidgetComponent in Paragon.

The SMeshWidget is used for, the indicator over minion heads, the flame effect behind upgrade-able abilities, and the player’s health/mana bar.

Additionally - the instanced rendering feature that it’s based on, is also used on the Minimap to be able to quickly draw all the minion dots…etc.

Hehe, sounds like a challenge =)

Any beginning advice on it or pitfalls to avoid? Thanks.

TheJamsh is trying to figure out out here, SMeshWidget - Hardware Instanced Slate Meshes Thread - Rendering - Epic Developer Community Forums, i recommend people help him :slight_smile:

I put together the simplest possible example of something practical you could do with it, https://drive.google.com/open?id=0B3jI1Q523JpSYktpMVlvUFVmTWs

There’s a lot to sift through to really understand everything it’s doing. Partly understanding how the ugs SlatePixelShader is sending the data to the material is worth looking at, so you understand what uv channels will contain what data.

Again - not easy to understand, hard to use, can do cool stuff with it; maybe if others take a look they can help explain everything in the thread I linked :slight_smile:

The jist is that, the SMeshWidget takes some 2D mesh data, and uses instanced mesh rendering to execute 1 draw call to render all of something. You pack a small amount of data into the instanced mesh buffer, so each instance gets 1 FVector4 worth of data for each draw on the GPU. You then pack whatever you need in there, anything you can’t pack, you’ll need to pass down an index, and extract extra information from textures you’ve packed the data into.

Any particular reason 3D Widget wasn’t used or improved to be used ?

Thanks Nick for the info.

Because it simply wouldn’t be possible to render enough of them fast enough using that method. Even if you used the invalidation panel for every indicator over a minion head, to reduce slate prepass/tick/paint time, that costs about 10 μs per indicator on the CPU on the PS4 to draw. The maximum number of indicators that could appear on the screen was 80. Meaning worst case scenario JUST the minion bars were going to cost 800μs (0.8ms). That’s nowhere even close to the budget they need to be in and that’s if you’re able to keep the invalidation panels from updating too often. Also that’s not even counting the overhead of every widget component…etc.

So Nick, is this sort of like per particle data used for procedural instance in offline renderer?(where each instance derive it’s shader info, or which pants/shirts mesh to wear from say per particle color, pant/shirt id, etc.)
On the other hand, is the 1 FVector4 hard limit for current implementation or something people can tweak and just recompile to get more data to pass over?

Yeah, they’re like particles. Hard limit, changing it requires c++ changes and shader changes. It’s no worse to store extra data in a texture; in some ways better as it allows you to push updates a different frequency or not at all of most of the data doesn’t change.