WebGL Demo Non-Technical Explanation

For a general understanding of the WebGL demo and how it is different from other techniques, read below. For a more technical explanation, see WebGL Demo Technical Explanation.

The Temple Run 2 WebGL demo delivers a high frame-rate 3D experience that is similar to a high quality video hosted on the internet. The production details, however, are quite different from that of streaming video.

The WebGL demo will be explained by the analogy with the production of a movie. Think of Netflix's production of House of Cards.

The fact that Netflix currently uses 32.3% of the Internet bandwidth for digital video distribution should cause one to consider adapting more efficient distribution models for computer generated content. Our graphical content distribution techniques use a fraction of the bandwidth currently used for applications such as cloud gaming. This is one of many technological rationales motivating our work.

Production of a movie is complex and multi-level. Productions start with writing a script, hiring actors, finding locations, designing costumes, building sets, filming, post-production editing and distribution. All these stages have their parallels in video game projects.

The main difference between movie and game production, is that in the case of games, the script is not completely written, but rather the user determines the progression of the game.

There are two common delivery techniques of streaming video images (games) on computers.

1. Standalone: The complete movie-production (3-D game) stack is transferred to the end-user computer. All the production stages are executed on the end-user device. This is normally not an option for movies, but is common for computer games. The video stream is internal to the local client and is never compressed.
2. Video Streaming: This technique is commonly used in streaming video content. The movies is stored (generated in the case of a 3-d game) on a remote cloud server. The distribution stage is split between the cloud, which compresses the video stream, and local client, which decompresses the video stream. The compression is done with a video codec such as H264, VP9 or ORBX.js. The resulting video stream is sent via a network connection to a remote client on a web browser or to a movie player that decompresses and displays the video.

The delivery technique for our Temple Run 2 WebGL demo is intermediate between these two techniques: the graphical rendering is done locally, while the compressed movie "direction" (rendering) command stream is generated in the cloud. All assets such as locations (3-D textures), costumes (character texture skin), sets (3-D models), motion capture (dynamic vertices) are transferred to the local client. Filming, post-production, distribution are also performed on the local client. The display of the graphics is performed locally with no compression.

WebGL Game Demo

Since this is a computer game, it is to be expected that the server will execute the program many times so that previous game executions can be used to optimize subsequent game play. The textures (images) and vertices (geometry) encountered in a game will generally be encountered on each invocation of the game.

For the Temple Run 2 WebGL demo, a file of textures and vertices has been extracted from running the game, and compressed into an 18 MByte file. This file is pre-loaded before the game is started. The graphical expression of game play is encoded into a compressed stream of rendering (OpenGL) commands. These commands will repeatably reference textures and vertices that were pre-loaded. Textures and vertices that have not been previously encountered will be loaded in the compressed rendering stream.

The WebGL demo runs for about 90 seconds: as longer portions of the game are played, the pre-loaded file is expected to grow slowly. A more careful pre-processing and more aggressive compression should halve the size of the pre-loaded file. It is expected that the pre-loaded file will be under 20 Mbytes for the complete game play, a reasonable assumption since the downloaded Android app is 31 MBytes, putting a bound on the size of textures and vertices.

At 30 fps, the game play uses 20 KBytes per second. Note that the bandwidth of an equivalent cloud gaming H264 stream is 400-600 KBytes per second, more than 20 times the WebGL bandwidth¹. The H264 video stream also degrades the visual appearance caused by the lossy compression.

(1) The reason that the compressed video streams take so much more bandwidth is that the same textures are effectively sent repeatably in the compressed video stream. This inefficiency is exacerbated by the need to minimize the latency introduced by the video codec which forces a small number of frames in the GOP (Group Of Pictures), which is the window of inter-frame compression.