Q2VKPT: Completely rewritten Quake II with realistic lighting

Q2VKPT is the first playable game with full raytracing, effectively simulating fully dynamic real-time lighting using the same state-of-the-art technologies used in the film industry (see Disney's practical guide to path tracing ).

The recent release of GPU models with ray tracing functions (raytracing) has opened up completely new possibilities for the future of game graphics, but the proper use of ray tracing is not a trivial task. While some game developers began exploring the emerging possibilities in rendering shadows and reflections, Q2VKPT was the first project to implement an effective overall solution for all types of light transport: direct, diffuse, and reflected lighting (see the Media section). In the film industry, this unification has led to a significant improvement in flexibility and productivity.. It is likely that this development of technology in games promises a similar improvement in visual accuracy and realism of graphics over the next few years. This project should serve as a proof of concept for the field of computer graphics research and the gaming industry; besides, it allows game fans to look at the potential future of game graphics. In addition to using hardware accelerated raytracing, Q2VKPT basically ensures its effectiveness thanks to an adaptive image filtering technique that intelligently tracks changes in the illumination of the scene in order to reuse as much information from previous calculations as possible.

about the project

The project is released as open source on GitHub . He integrates our Vulkan ray tracer into a Q2PRO client . The project arose from the need for computer graphics research on fast-running test content. It is motivated by the first intriguing results of the path trace renderer, written in 2016 .

Story

VKPT Q2VKPT and were created as a hobby project by Christoph Shidom ( by Christoph Schied ) to check the computer graphics research results in this game. At the moment, the project includes 12 thousand lines of code and completely replaces the original graphic code Quake II. Initially, his prototype was written in OpenGL with the participation of Johannes tantly ( by Johannes Hanika ) (experimental raytracing, shaders, GL / Vulkan correction), Addis Dittebrandtom (hierarchy of illumination, visualization debugging), Tobias cirri ( by Tobias Zirr ) (sampling light, hacking guide website, information texts) and Florian Rybold (original lighting hierarchy). Additional assistance was provided by Stefan Bergmann, Emanuel Schrade, Alice Jung and Christoph Peters (a bit of noise ).

Downloadable materials

• Github repository
• Windows binary on Github
• Quake 2 Demo (for playing q2vkpt you need .pak files from the demo or full version of the game)

Video

Failed frames in development: video with glitches 1 , video with glitches 2 .

Screenshots

We advise you to watch the video or play the game yourself, because fully dynamic lighting is much better felt in motion.



Output path tracer (left) and applied noise reduction filter (right)

Technology

Q2VKPT is implemented on the Vulkan API, in order to be able to use the new hardware raytracing functions that appeared last year. Thanks to them, the game can get close to 60 FPS (2560x1440, RTX2080Ti) with full raytracing and dynamic shading with realistic models of global illumination, calculated in real time. Using path tracing for fully dynamic lighting allows you to greatly enhance the shading detail of game scenes, naturally creating a complex interaction of sharp and smooth shadows, brilliant materials, and perspective correct reflections. Moreover, the light can naturally propagate everywhere, linking the scenes as it does in the real world.

Technical details

Q2VKPT uses a variety of techniques that allow you to adapt computationally costly methods to games that were previously used only in the film industry. Their core is an adaptive time filter that intelligently reuses the results of calculations from previous frames (this is a previous research project by Christophe). This filter is used on top of the already widespread temporal anti-aliasing and extends the process of tracking temporal changes from a simple image space to a high-dimensional space of light paths. Tracking path changes is necessary because path tracing is a randomized algorithm, which is its strengths and weaknesses: it can process all types of light propagation in a generalized form, but it can take a long time, too long for one to make the results reliable. frame in a real time game. A simple solution in image space (for example, temporal anti-aliasing) cannot cope with this level of uncertainty.

Above the time filtering, we explored several techniques for finding the sources of light that affect each surface in the game. Choosing the right light sources is crucial for picture quality, because if you make the wrong choice, we will get very unreliable output of the path scanner, which will force the time filter to remove all the beautiful details that the path scanner should have created. The original prototype used a complete hierarchy of sources of illumination common in the film industry: dividing sources of illumination across the hierarchy, we can simultaneously calculate the influence of several sources, which allows us to quickly exclude distant and weak sources from the calculation, as well as sources that are in the wrong direction. However, it turned out that such calculations are difficult to make accurate, and the computational cost of bypassing the hierarchy is difficult to control. Since the original Quake II used sets of potentially visible spaces (Potentially-Visible-Set) to cut off the invisible parts of the scene, we decided to avoid extracting from these sets lists of potentially visible sources for each part of the scene. In the current version, we have implemented a partially accurate calculation of the influence of each source in the list, randomly selecting the appropriate subset of these lists in each frame. Therefore, the renderer quickly finds all sources of illumination, and we can perform all calculations of the influence of illumination over controlled, constant periods of time. we decided to avoid extracting from these sets lists of potentially visible sources for each part of the scene. In the current version, we have implemented a partially accurate calculation of the influence of each source in the list, randomly selecting the appropriate subset of these lists in each frame. Therefore, the renderer quickly finds all sources of illumination, and we can perform all calculations of the influence of illumination over controlled, constant periods of time. we decided to avoid extracting from these sets lists of potentially visible sources for each part of the scene. In the current version, we have implemented a partially accurate calculation of the influence of each source in the list, randomly selecting the appropriate subset of these lists in each frame. Therefore, the renderer quickly finds all sources of illumination, and we can perform all calculations of the influence of illumination over controlled, constant periods of time.

Questions and answers

Why does my game crash?

We are engaged in this project in our spare time, so we do not have enough strength for careful quality control. Please post a bug in the issue tracker of our GitHub repository!

Why are there no particles? I need flies and sparks from railgun!

Unfortunately, we didn’t have enough time to add lighting sources to railgun. As for other particles, the decision we made to perform raytracing only slightly complicated the process of rendering particles. If we find time, we will fix it in the future!

Nowadays, games and so look realistic! Why use path tracing?

Modern games have greatly expanded the capabilities of traditional, rasterized graphics. However, these improvements have to pay their price: the rendering engines of modern games have become extremely intricate sets of narrowly focused techniques. To achieve an acceptable image without artifacts, lighting, shadows and reflections must be calculated separately in many resolutions and scales. Path tracing and other Monte Carlo rendering techniques make it possible to find a way out of this ever more complex system. In fact, they have already solved this problem in the film industry . Our prototype is the first answer to the question of how to achieve this in the video game industry.

Quake II is an ancient game! If these technologies had some future, then today it would work with a frequency of 6000 FPS!

Yes, Quake II is a fairly old game with fairly low geometry complexity, but the main limiting factor for tracing a path is not ray tracing or geometry complexity. In fact, the current prototype can trace much more rays without a noticeable reduction in the frame rate. The computational cost of the technician used in the Q2VKPT prototype mainly depends on the amount of computation of (indirect) light scattering and the number of light sources. Quake II initially had many sources of lighting, and in this respect it is still a fairly modern game. In addition, the number of light scattering events does not depend on the complexity of the scene. Therefore, we can assume that the techniques used by us are well suited for more modern games.

Why quake II?

Because the sources of Quake II are publicly available, and the game itself has a long history of modding. This is an excellent sandbox for real-world scientific research. In particular, the game has an active and controversial gameplay, which sets high demands on the performance and reliability of the rendered rendering techniques. And finally, Quake II in a sense still remains a fairly modern game, because it was originally released with a sophisticated and artistic lighting design.

How can I use Q2VKPT as a benchmark?

Open the console by pressing the "~" key. In the demo version of Quake 2, you can use the command “timedemo 1; demo q2demo1 ", in the full version - the command" timedemo 1; demo demo1. The built-in profiler is started by the “vkpt_profiler 1” command. It provides details about the timing of the GPU for the individual rendering steps.

How is path tracing different from ray tracing?

Path tracing is an elegant algorithm that can simulate a variety of complex ways that light propagates and diffuses in virtual scenes. His physics based lighting simulation provides high-quality rendering. Tracing path usesray tracing to determine visibility between scattering events. However, ray tracing is simply a primitive operation that can be used for a variety of purposes. Therefore, ray tracing itself is not capable of creating realistic images. For this you can use light propagation algorithms like path tracing. However, despite the fact that it is elegant and very powerful, a naive path tracing is very expensive and takes a lot of time to create stable images. Our project uses an intelligent adaptive filter that reuses the maximum possible amount of information in several frames and pixels to create reliable and stable images.

Tracing the path and ray tracing - the future of game graphics?

The recent appearance of a ray tracing GPU has opened up entirely new possibilities for the future of game graphics, but a non-trivial approach is required to properly use ray tracing. The goal of our project is to find out what is missing to create a direct path to the future graphics with ray tracing. Although some problems have already been solved in scientific research, many real problems remain unnoticed until you start implementing the full game renderer. In the future, we plan to explore some of these problems, for example, better-quality lighting, improved filtering and a more complete renderer software structure. In order for these changes to become large-scale, good solutions are needed for new, unusual renderer tasks based on ray tracing and paths.

Will tracing the path finally solve all the graphics problems?

Tracing paths and methods similar to it elegantly solve many complex tasks of game graphics. However, their probabilistic nature adds a whole host of new tasks, the solution of which is necessary for creating clear (silent) high-quality images. The filtering method in the Q2VKPT prototype is the first step to robust unified methods that allow the rendering of a fully unified brute force approach using path tracing. In the coming months and years, we expect and hope to see other research in this direction!

Q2VKPT used lighting maps from the original game?

The original Quake 2 engine uses pre-computed lighting maps containing soft shadows and diffuse indirect lighting. Q2VKPT completely replaces static lighting with fully dynamic simulation, unifying both static and dynamic lighting sources.

How many rays Q2VKPT emits per pixel?

The amount of light emitted depends on the first visible surface. On opaque surfaces, Q2VKPT uses one ray for each pixel to find a direct and indirect visible surface. In addition, for both surfaces, Q2VKPT emits a single beam to randomly selected light sources. Therefore, Q2VKPT emits at least 4 rays for each pixel.

Is rasterization used in Q2VKPT?

Traditionally, a rasterizer is used to find surfaces visible from the camera in games. In Q2VKPT, visualization is completely performed by ray tracing, so the rasterizer is not used (with the exception of two-dimensional user interface elements).