Research & Development

Jonathan Garrett (one of our Lead Engine Programmers) recently introduced our new realtime cinematics system to the team that a bunch of Core engine programmers have been working hard on for a while now. If you’ve been following our previous notes on our tools, you’ll know that our tools are webapps (except for the 3D scene view which is natively running our game/engine). We definitely took a lot of the lessons we’ve learned in creating previous HTML5/Javascript tools which interact with the game and our servers and applied them to this new tool. Cinematics in particular are much more complicated than anyone ever thinks to develop, and as such this is easily one of our most sophisticated tools. While the presentation slides here are short on implementation details, I hope you’ll still enjoy this inside look into one of out web-based tools built for large-scale productions.

We use Perforce for revision control at Insomniac. Most significantly, we manage a large number of large binary assets and there are very few other RCSs that would handle that well. However, we are always interested in looking at other systems and we have a few people here who are fans of git for source code control specifically. Jonathan Adamczewski (Engine Programmer) is among those and presented the following to interested programmers as an introduction to git (and comparison to Perforce).

An Introduction to the Git Revision Control System

As part of our Core team internal training, Mike Day (Sr Engine Programmer, working on our Render team) has been guiding small groups of other engine programmers (specifically those NOT on the render team) to read an academic paper and assist them with whatever background is necessary so that they can explain it. With any specialized discipline, there is a lot of domain knowledge presumed in the explaination of an idea and helping others pick up that background is part of the goal of this exercise. Academic papers in particular also tend to be extremely hard to parse, unnecessarily verbose and missing details crucial for replicating results. Filling those gaps is another goal. Finally, getting folks that don’t normally work together every day to discuss ideas which interest them but does not have an immediate impact on their work has real value.

In this installment, Mike picked the 2001 paper, An Efficient Representation for Irradiance Environment Maps (PDF) by Ravi Ramamoorthi and Pat Hanrahan.

Below is the presentation from the group on their understanding of that paper.
Mike Day Paper Exercise – An Efficient Representation for Irradiance Environment Maps

At Insomniac we’ve been using the well-known Reinhard tone mapping operator for a while now, but have found its parameterization unintuitive, and its curve shape to be lacking the useful ‘toe’ feature. Presented here is an efficiently computed alternative model which has been designed to qualitatively capture the toe and shoulder features while at the same time using intuitive parameters.

Read more: an efficient and user-friendly tone mapping operator.pdf

This document (by Mike Day) accompanies the SIGGRAPH presentation (by Mike Acton) “CSM Scrolling: An acceleration technique for the rendering of cascaded shadow maps” and will explain how a bitmap-scrolling technique can be combined with a shadow map caching scheme to significantly increase the performance of real-time cascaded shadow mapping in games. The two systems integrate well into the standard model of cascaded shadow mapping, and take advantage of temporal coherence to preserve much of the rendered shadow map information across frames. The technique is well-suited to current games consoles, and will ship in “Overstrike”, the forthcoming title by Insomniac.


Here’s a short account of an easily overlooked difficulty with vector length and vector normalization functions, together with one way of solving the problem. We’ll use 3-component vectors by way of illustration, but the idea is easily extended to longer or shorter vectors, quaternions, etc. Single-precision floating point is assumed.


This article attempts to fix a problem which came up when implementing Ken Shoemake’s Euler angle extraction in the context of a single-precision floating point library. The original Shoemake code uses double precision, which presumably maintains sufficient precision for the problem not to arise.

euler angles.pdf (Updated 2/24/2014 with typo noted by John-Michael Fischer below fixed.)

A ‘spotlight cone’ can be pictured as an ordinary right circular cone, the base of which has been inflated outwards to form part of a spherical surface centred on the cone’s apex. This shape is useful in lighting systems for finding all the objects which could be influenced by a given spotlight. This document shows a stripped-down calculation for testing whether a given spotlight cone overlaps a sphere, typically the bounding sphere of an object which may be lit. The calculation can be used as the basis for an optimized SIMD test for checking a batch of several spheres against a given spotlight cone.


We follow the method of separating axes, optimized for the case at hand. The assumed scenario is a looping SIMD implementation, where it is often beneficial to perform the full calculation for each test unconditionally. In other situations, it may be preferable to early-out as soon as a separating axis is found. Also, the usual approach of preceding the test with a quick and conservative one to prune out easily classified cases, using bounding spheres for example, applies.

Read: obb vs obb.pdf