The design and evolution of the UberBake light baking system DARIO SEYB∗, Dartmouth College PETER-PIKE SLOAN∗, Activision Publishing ARI SILVENNOINEN, Activision Publishing MICHAŁ IWANICKI, Activision Publishing WOJCIECH JAROSZ, Dartmouth College no door light dynamic light set off final image door light only dynamic light set on Fig. 1. Our system allows for player-driven lighting changes at run-time. Above we show a scene where a door is opened during gameplay. The image on the left shows the final lighting produced by our system as seen in the game. In the middle, we show the scene without the methods described here(top).Our system enables us to efficiently precompute the associated lighting change (bottom). This functionality is built on top of a dynamic light setsystemwhich allows for levels with hundreds of lights who’s contribution to global illumination can be controlled individually at run-time (right). ©Activision Publishing, Inc. We describe the design and evolution of UberBake, a global illumination CCS Concepts: • Computing methodologies → Ray tracing; Graphics system developed by Activision, which supports limited lighting changes in systems and interfaces. response to certain player interactions. Instead of relying on a fully dynamic solution, we use a traditional static light baking pipeline and extend it with Additional Key Words and Phrases: global illumination, baked lighting, real a small set of features that allow us to dynamically update the precomputed time systems lighting at run-time with minimal performance and memory overhead. This ACM Reference Format: means that our system works on the complete set of target hardware, ranging Dario Seyb, Peter-Pike Sloan, Ari Silvennoinen, Michał Iwanicki, and Wo- from high-end PCs to previous generation gaming consoles, allowing the jciech Jarosz. 2020. The design and evolution of the UberBake light bak- use of lighting changes for gameplay purposes. In particular, we show how ing system. ACM Trans. Graph. 39, 4, Article 150 (July 2020), 13 pages. to efficiently precompute lighting changes due to individual lights being https://doi.org/10.1145/3386569.3392394 enabled and disabled and doors opening and closing. Finally, we provide a detailed performance evaluation of our system using a set of production 1 INTRODUCTION levels and discuss how to extend its dynamic capabilities in the future. AAA games today produce images at real-time frame rates (usually ∗Both authors contributed equally to this research. 30 or 60 frames per second) that can rival the realism and complexity of offline rendered movies from just a few years ago. This leaves just 16–30 ms to simulate the virtual environment, react to player Authors’ addresses: Dario Seyb, [email protected], Dartmouth Col- lege; Peter-Pike Sloan, [email protected], Activision Publishing; Ari Silven- input, and produce images showing a wide range of complex light- noinen, [email protected], Activision Publishing; Michał Iwanicki, transport phenomena. This last goal can be especially challenging, [email protected], Activision Publishing; Wojciech Jarosz, wjarosz@ dartmouth.edu, Dartmouth College. as players enjoy games on a variety of hardware platforms and comparable quality needs to be achieved on all of them, including ones less powerful than the state of the art, such as mobile devices Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed or previous generation consoles. for profit or commercial advantage and that copies bear this notice and the full citation One of the difficulties of the rendering process is computing on the first page. Copyrights for components of this work owned by others than the author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or global illumination—the component of the lighting that arrives at republish, to post on servers or to redistribute to lists, requires prior specific permission each point not directly from a light source, but after some number and/or a fee. Request permissions from [email protected]. of bounces off other surfaces in the scene. Given the limited time © 2020 Copyright held by the owner/author(s). Publication rights licensed to ACM. 0730-0301/2020/7-ART150 $15.00 budget, most modern game engines rely on some form of precompu- https://doi.org/10.1145/3386569.3392394 tation or baking. Parts of the lighting are computed offline, stored in ACM Trans. Graph., Vol. 39, No. 4, Article 150. Publication date: July 2020. 150:2 • Dario Seyb, Peter-Pike Sloan, Ari Silvennoinen, Michał Iwanicki, and Wojciech Jarosz some data structure, and efficiently retrieved at run time. This was low end platforms. For our system to run on all target plat- pioneered by the work of id Software on Quake and Quake 2 [Abrash forms, it has to have very little overhead on top of existing 2000], with the latter being the first game to feature truly indirect static lighting. lighting, precomputed and stored in textures. C.2 No additional constraints on geometry. Many global illu- While recent developments in hardware-accelerated ray trac- mination algorithms impose specific restrictions on level geom- ing [Parker et al. 2010; Wyman et al. 2018] provide hope for limited etry such as a requiring a minimum wall thickness, preferring forms of real-time global illumination, these techniques have so far axis aligned features, and more. There was already a significant remained too costly as general lighting solutions in AAA games. amount of content when we implemented our system. Since With the exception of isolated effects (e.g. mirror reflections) real- it was not feasible to rework much of the content, the system time ray tracing is unlikely to supplant current baking-based solu- had to work well while only requiring minor level changes. tions, or even be universally available, for at least the next console C.3 No major revisions to engine and tools code. We have a generation (and likely longer for mobile platforms). large amount of engineering and art resources invested in ex- The limitations of baked lighting are, however, significant. Any isting tools and cannot change them significantly. Additionally, changes to the geometry require a costly, offline update that can we do not have the resources to rewrite large parts of the en- often take multiple hours, significantly increasing the iteration time gine. We had to extend the existing baking pipeline without a for artists. Because the precomputation is performed assuming static complete overhaul, and implementation time had to be weighed level geometry, any changes at run-time have no effect on lighting. against supporting production or extending the baking pipeline For example, a player might destroy a wall, which should flood in other ways. the inside of a building with light; however, since the lighting was Meeting the above-mentioned constraints was the highest priority precomputed with the wall intact, there is no information available and narrowed down our options in the design of the system, but we about how the lighting distribution inside the room should change also strived to optimize for the following design goals. when it is no longer there. Even simple interactions like opening doors might leave the level’s lighting in an inconsistent state. G.1 Minimize artist iteration time. As opposed to run-time per- We describe the design and evolution of UberBake, a dynamic formance, we do not have any hard constraints on baking per- light baking system we developed to address these issues and which formance. Still, long bakes increase artist iteration times which we’ve since used on multiple AAA games. UberBake was developed we would like to avoid. Bake time should scale with scene over the course of multiple releases and innovation was driven complexity and the number of interactive elements per scene. mainly by gameplay and level-design requirements. Particularly, Specifically, we strived to achieve sub 10 minute bake times for we wanted to implement a system for global illumination in which preview-quality results to enable fast iteration. certain player actions can cause dynamic lighting changes. This G.2 Minimal content creation overhead. Previous systems had allows the lighting to be used not only for dramatic visuals, but content creators manually label every scene element (lights, also as part of the gameplay, for instance to drive player’s attention geometry, etc.) affected by a particular change in the lighting (e.g., flickering lamp can suggest a point of interest) or asawayto setup. Particularly, it was necessary to classify elements into solve the game’s puzzles (e.g., shooting lights out before engaging being active before, during, or after the change in lighting. This enemies will make them less likely to aim accurately). was prone to errors due to mislabeling, caused a large workload The central insight of our work is that we can choose a limited on lighting artists, and ultimately, the system not being widely subset of user interactions that affect lighting (enabling/disabling used. lights and opening/closing doors) and receive many of the benefits G.3 Maximize implementation orthogonality. We want to be of a fully dynamic global illumination solution. This made it possible able to add interactive elements and improve the baking code to 1) efficiently pre-compute lighting changes associated with each without significant changes to the run-time system. This allows interaction and 2) implement a run-time system that, on average, is us to expose new functionality to artists without the risk that no slower than our previous fully static implementation and uses engine changes pose. a minimal amount of extra memory, that scales linearly with the While these constraints and goals might seem overly restrictive number of allowed interactions.