none
HUD pains continued

Since the creation of the HUD has been causing so much pain in the past we thought: “Why this complicated?”. A simple HUD that contains no distracting elements, without the need for special cosmetic attention and easily maintainable. The HUD, witnessing our discomfort with it, decisively screamed: “Make it square!”.


And so we have. Meet the new HUD:


[embed]https://www.youtube.com/watch?v=QAQGwm9rQYI[/embed]

We were not amused. Henceforth, this individual HUD has become known under the name BADHUD and we started listening to the voice of GOODHUD (or is it even PERFECTHUD?) again. We’re not giving up that easily.


In the above video the radar items are drawn directly to the HUD canvas. It looks as though it shouldn’t be too difficult to realize the middle radar by drawing directly to the HUD, right? After all, we have moving square players and a square ball. Simply add the middle radar material and be done with it! Unfortunately, it’s not that easy. The size of the middle radar’s background material has to be accounted for so that the items in the middle radar are congruent with the actual position in the map. On top of this, it all has to be scaled with the canvas size. Pain, pain, oh yes pain indeed.


Leaving the middle radar to be continued later I decided moving on to the radar and give UMG a try. After having done the menus in UDK in Scaleform I was happy to have direct control over UMG directly from the engine’s code. Though Scaleform is much more powerful it’s been a dreadful and exhausting experience from UDK. Things often just didn’t work out the way supposed to.


So, UMG (Unreal Motion Graphics): It can resize elements automatically according to the canvas size. Great! It let’s you rotate elements that can contain multiple other elements. Splendid! Does it come with VR/Oculus support? Not really. Or maybe possible by using 3D widgets.


The middle radar has taken a reasonable amount of invested time. Drawing the material into a widget: Easy. Scaling the coordinates from the level to radar coordinates: Easy, after you discover that the size of the playfield you have determined was falsified by odd wall translations (see below, yellow framed object is the wall, white ball with arrows its location, NOT).



Then rotate the widget against the player’s rotation, et voila! Small issues remain regarding the actual fitting of the map onto the radar map. As one can see below (with the help of a magnifying glass perhaps) the player is standing on the line but his location on the radar is incorrect.



The radar claimed a bit more distress. Locations from level coordinates need to be converted into middle radar coordinates and then into the middle radar’s widget coordinates. Furthermore, the actual middle radar radius equivalent to the level has to be taken into account. It’s straightforward once the mathematical foundations are clear. But getting there was a piece of work. Defying math at these points is tempting but simply results in numerous unlucky trials. Eventually, math is the last resort. I’m not going to bother you with that, though.


Wondering whether UMG is really a good option I confronted a UMG radar with a radar drawn directly on the map. Here the result:



Can you see a difference quality-wise? The colors appear a bit different. But that can be accounted for.


Here’s the current state of the HUD:


[embed]https://www.youtube.com/watch?v=ck6dxmks8Sg[/embed]

I don't exactly have a gaming setup here. Also, my video recording software seems to dampen my FPS quite a lot... I hope you're still able to catch the core elements; namely the radar and middle radar.

By the way: This is on a Mac.

As always: Happy to hear comments & ideas.