Lots of eSports Data, One Map and Two Renderers

How we built PUBG’s AR analysis map graphic

With interest in eSports continuing to grow we thought we’d take a deep dive into one of our projects and look at how we built an AR map to work on two different graphics renderers with the same control interface.

This was only our second project using Ross Video's XPression

We've been working with Viz Engine since 2010

Ignition

We used our Ignition software to handle the data integration and operator GUI

Remote

The system was built and supported remotely by us in UK with the client in the USA

Fanview

It was great working with Fanview Media, our partner on this project

We’ll cover some key takeaways at the end but first let’s look at the video game itself. PUBG makes for dramatic viewing. It’s a battle royale style game where teams parachute on to an island and have to find weapons, grenades and bandages whilst fighting off other players, all while a destructive ring reduces the playable area or "safe zone". Teams are forced together, and the last team standing is the winner.

The project presented two challenges:

• Take complicated in-game data and turn it into an engaging AR based analysis graphic
• Take the same concept but now use a different graphics renderer and add some new features!

Challenge 2

Take the same concept but now use a different graphics renderer and add some new features!

Stick with the same control interface, but rebuild the graphics on the new platform.

Data

Learning from the previous shows the client wanted to take advantage of the “in game time” data. This would allow them to recreate any moment from a match with a time stamp, moving to that position in the map for analysis. They wanted to see where and what each team was doing at any point in the game.

Graphics

At the client's request the graphics rendering was changed to Vizrt. This meant rebuilding the map and associated 3D objects and animations.

The map and the plane resources were Cinema 4D files so that part was easy - they could be directly imported - however the rest of the objects and animations had to be rebuilt. We used the cylinder primitive with a texture for the safe zones, and the Viz spline strip tool allowed our script to draw the team routes in real time.

Also, for the previous show they were only using two of the game maps - Erangel and Miramar. For this iteration Sanhok had to be added, so we had to import another map geometry. This map was half the width and half the height of the other two (thus four times smaller) so all the positions had to be scaled up because they wanted the map to take up the same amount of real space in the studio.

Scripting

Once again script was needed to achieve the complexity of animations and objects. The XPression script was ported to Viz script, adding the adding the time based functionality in the process.

In order to improve performance, we changed the way we sent data to the render engines. With XPression we were sending data every time the operator clicked live. This time Ignition calculated a timeline of events and created a Director in Viz with all the chosen teams points pre-loaded at the beginning of any sequence. This meant the data was sent once at the beginning rather than for each step. Now there was less chance of effecting performance whilst the graphics were in the middle of a camera move or animation.

If you do a lot of working in Viz Script you may find some of our tooling useful to help streamline your development processes.

Workflow

Ignition is renderer agnostic, so transferring that part of the tooling across took less than an hour. When operators sat down for the show they were presented with the very same interface they had used to drive XPression, but with added functionality around the “in game time” feature (the sequence builder was intelligent in that it wouldn’t let you add phase 2 after you’d added phase 3, but you could easily jump from phase 2 to phase 7).

Tom Chafer Cook, Senior Developer, said: “Working remotely on this project was a challenge. Little did we know how useful this experience would be in 2020! As we were not physically in the studio, we gave them as much flexibility as possible. For example, an Admin view that allowed them to set whether the logos faced the camera or not. Also, we built the plane to be the correct scale for the map but on TV it didn’t look great, so we provided the ability to scale the plane from our interface without them needing any Viz graphics expertise on site.”

Full forms and lower thirds

Both AR and on-screen

Before we wind up it’s worth pointing out that maps weren’t the only use for the AR: we also built match result graphics and leaderboards.

That’s not forgetting on-screen full form and lower third graphics, all driven from live data and the same Ignition control interface.

Conclusion

Having since worked on other eSports projects we’ve found that Ignition is perfectly suited for this genre, especially in the current climate of remote working and cloud support. Having this experience has helped us to tool for the new normal. Building graphics and testing them from a long distance has its challenges but can be done!

Key Learnings

• It’s not easy to transfer between two graphics systems – planning and rebuilding is required
• Data and control can be agnostic to the graphics if planned correctly
• The earlier in the process you are engaged, the more you can improve performance and functionality
• Having the same control interface regardless of graphics rendering technology is a massive benefit to the client’s workflows and productivity