Hey Everybody, CCP MC Peanut here--new to the forums (and this is my first post). I'm a Technical Artist here in Shanghai and was mostly involved in the HUD upgrade for the Project Legion Prototype you saw at Fanfest. I'm excited you guys noticed the work and are discussing it. The feedback is super awesome too (so awesome I forwarded the post to a lot of other devs). I thought I would jump in and give a little further explanation about what we did and potentially where we can go from here.

The HUD that you see in the Project Legion Prototype showed at Fanfest is now being rendered inside the 3D Scene. This is a significant change. While what you saw in the demo isn't incredibly different to what was there before, I want to emphasize that we have completely changed the underlying system for creating HUDs and have built a pipeline that puts the artist and designers much closer to the implementation. What you saw was the first implementation with the new system. And while the demo doesn't demonstrate it all--everything is working. In a very short time (a few weeks maybe), a few of us rebuilt the HUD, recreated all the logic, and tuned it to a slightly new visual design.

I'd love to go a little more in depth and explain some of the cooler benefits we are finding with this change:

Artist and Designers can iterate like crazy:
Unreal already has a lot of robust tools available to it, so why not take advantage of them. One of the things the artist love the most is being able to play the game with the editor open and update their material parameters in real-time. The 3D HUD is heavily utilizing the Unreal Material system. For example, all the 'bars' stem from the same base material, which has parameters to control the scale of the ticks, space between, color (including switching the color over position), flashing (speed and color). Tuning these parameters in-game is pretty awesome and very easy. Another example, the most obvious one probably, is that since it is 3D, we can change the position and layout very easily--it is as simple as moving it in the 3D package (Maya) and re-importing the geometry.

Logic outside of code
This was an interesting choice, but I believe it was the right one. We are exposing game data to the artist/designer through events in the visual scripting system, called Kismet (if you aren't familiar with Kismet, it is a node based scripting tool provided within Unreal that allows artists and designers to do more 'programmatic' things). With this change, much of the logic is in the hands of the content creators--the programmers are only responsible for providing the information when applicable. This sounds like it could become overwhelming, and we have been careful about not suddenly dumping everything in their laps. I can give one example. When your shield value changes, an event will be fired (a kismet event inside the HUD map file). This event will expose the current and max shield value. Luckily, our bar material has a max and current parameter input, so we just update the values (using a Kismet action) and all is good. While this is something that sounds like it could be completely programmatic, it is so much nicer to give the content creators the flexibility. If we wanted to, we could trigger a distortion animation every time the armor value changed, and as the armor got lower, the distortion could be more significant. This would require zero programmer support.

Lots of technology to utilize
Because we are in 3D we have access to all the rendering technology as other 3D stuff (suits, weapons, environments). We can also utilize the same tools (materials, modeling, an animation) that our 3D artists are familiar with, so the transition for workflow, was not so bad.

Capacity to be Dynamic
I can't make any promises about racial HUDs, but we are definitely in a much better position to be able to do them. It is very easy to create new 'visual' components without needing to rework the data hookup--and they would be lightweight and low cost.

There is more, and I could go on, but perhaps that is better for follow up posts. Our hope is that we have built a system the is flexible enough to give us more options to do the kinds of things you guys are asking for. Regarding these requests, I can definitely weigh in on their possibility within the system, but I am unable to comment on the likelihood (that is someone else's call). Please keep the feedback coming, and feel free to post follow up questions.

thanks!

Wow. You make me feel way cooler than I should. There should be an official dev spotlight happening soon that should cover the information you want, but I'm happy to answer specific questions if you think they won't be covered in the dev spotlight.

CCP MC Peanut has a youtube channel now

I got permission to upload some footage of the compass. The texture is still a work in progress and will be updated later by artists, but you can see it moving with the camera.

https://www.youtube.com/watch?v=rTk3C5HPoZs

The Militia AR has 48.
I am assuming that's what he's using.

Since someone noticed the backwards rotation, gotta update, or risk losing coolness points: http://youtu.be/mumOikxPNjs

Yes absolutely. I agree--I didn't even know it was moving backwards with the numbers. It would have been more obvious if I turned right and suddenly I'm facing West. I'm pretty sure the artists, when they update the texture for this, will add some markers, but I can't say for sure.

As for displaying objectives and such on the compass (an earlier question asked this). This is a little more complicated than the compass itself, as the position is related to the objective position and your position/orientation. Actually, when I first thought about it, I thought this was hard, but then after a day I realized it isn't. You just need a normalized vector to the objective and the players facing vector--then you can figure out the angle (same way with the compass--arctan2). This could actually be done with a shader, but you would need texture sampler for each objective. Also you could create a different polygon ring for each objective and let them sit slightly on top (so close you couldn't tell). The hardest part is getting the position of the objective--this wouldn't be immediately available in the shader, but it could be set with an event, as objectives don't change position (but if we wanted to track other things that do change position that may need to use a different way).
Wow--this is cool--totally do-able. Thanks for making me think about it. I'll propose it to the team.

Actually it is ok if it switches infrequently. I was more referring to marking positions of things that could be frequently (like every frame) moving, such as a player.

Some HUD features I would like for immersion.

HUD boot-up when we spawn. The various HUD elements should turn like 1 seconds after you spawn.

Head-shot damage visual distortion effects. Sensors & cameras for vision are located in helmet, so when shields are down and you are hit by headshot, the cameras' vision should be effected. This could make the HUD flash off briefly.

Thank you

Yea we already do that and are doing it in a 2D system and generally it works fine. If we moved this to a 3D system we would be able to better control (on the content side) the visual rendering of these icons. We would also be able to add more complex /dynamic information, such as animations, dynamic text, visual states, and shaders (like a health bar on an icon). It may also give us more flexibility to expand on it since it becomes more content driven. However, we would likely only move to a 3D system if we felt the benefits were worth the cost of moving. In the case of the HUD, the benefits were worth the cost.

As for doing this on the compass--this can't use the existing system because the compass exists in the 3D world while the current icons are drawn in 2D (using 3D positions and converting to screen position). Also we probably can't track the player position on the compass using the method I described above because it would require constant updating, and kismet is not great for that--this would be better to be done on a custom actor class and controlled within the class itself (faster).

Or am I missing your question again. I am actually not incredibly familiar with the workings of squad interaction so I may be missing the point.

Thanks for the assist. Nailed it.

Since we are on the topic of screen effects... I've posted a very early prototype of doing one. This is so early, you will see the 3D HUD is still mostly un-textured polygons (it was probably going through a makeover at that point). So please excuse the ugliness there, but I thought it would be cool to show off at least a little proof that this type of thing is possible. The fog effect is a translucent material (with a color of white). There is also a little bit of blurring going on, but the blur control has since been improved, so I know we could achieve an even more realistic effect here. Of course, as discussed, an effect like this is questionable if it really follows the fiction of the suits having screens and cameras. Still, the technique remains the same: visor mesh + shader with access to the screen texture.

http://youtu.be/-TUr4W9vOG4

Could you give the player an option (maybe on the tactical map) to view the map in orthographic or perspective mode? In orthographic you could overlay a 3D grid over the map with no warping.
I personally think the radar/hopefully soon to be mini map, should always be orthographic.

For those who might not know,
"Orthographic projection (or orthogonal projection) is a means of representing a three-dimensional object in two dimensions."

Via http://en.m.wikipedia.org/wiki/Orthographic_projection