WebGL Demo Technical Explanation

Here is a technical explanation of the WebGL demo. For a less technical explanation see WebGL Demo Non-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.

There are two common techniques of delivery from within a web browser environment which delivers an interactive 3D experience:

1. Standalone WebGL: The application is either written in JavaScript-WebGL or translated from another application environment into JavaScript-WebGL. In this case the application is run on the browser using local resources. JavaScript provides the computation capabilities and WebGL provides the 3D graphical capability.
2. Video Streaming: This technique is commonly used in cloud gaming. The application is hosted on a remote (cloud) server. Graphic rendering (pixel coloring) is performed on the remote server to create frames (still pictures). The sequence of frames is compressed with a video codec such as H264, VP9 or orORBX.js. The resulting video stream is sent via a network connection to a remote client on a web browser that uncompresses and displays the video.

Our Temple Run 2 WebGL demo is intermediate between these two techniques: the graphical rendering is done locally, while the compressed rendering command stream is transmitted.

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. This may not be true for the execution of some apps such as a contact manager, where textures may be different for different users.

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.

An examination of the WebGL demo rendering stream reveals the following:

• The most complex object drawn in the WebGL demo while the game is in "running" mode, is the menacing "gorilla", which is normally not within the viewing frustum and is culled from the rendered frame. In comparison, the H264 stream only shows what is "on camera".
• Almost all the textures used by the program are loaded before the first frame is rendered into the GPU.

(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.