Using the Remote Shader Compiler Compiling the Shader Cache

Total Page:16

File Type:pdf, Size:1020Kb

Using the Remote Shader Compiler Compiling the Shader Cache During development, we utilize Profile or Debug builds - those are builds that aren't fully optimized and contain developer utilities that aid the development of games. Overview Shader Cache To ship a game we choose to build the engine in a Release configuration, resulting in a build that's fully Using the Remote optimized and strips out systems that users don't have to run into. At the same time, we can pre-compile Shader Compiler shaders to ensure that no unnecessary computation has to happen at run-time of your game, in order to Compiling the Shader maintain optimal performance. Cache Creating the Shader The process of shipping a CRYENGINE game can be broken down into five steps (covered in further Cache Archives detail below): Compiling and Archiving Assets 1. Develop the game using Profile builds, compiling shaders with one Remote Shader Compiler Compiling Code in Release (covered further below) - resulting in a stored list of all shader permutations used by your game Mode 2. Compile all shader permutations used by your game using ShaderCacheGen.exe Packaging the Final Build 3. Archive the compiled shaders Conclusion 4. Run a Resource Compiler job to compile game and engine assets, and archive them 5. Compile engine in release mode Once complete, we'll have a build that can be run by end-users. Keep in mind that the process of shipping on platforms other than desktop will entail extra steps. During development, we compile shaders on-demand whenever an effect or object requests a specific permutation. However, this incurs a significant performance cost and will cause stalls during gameplay. To prevent this, we use the Remote Shader Compiler to compile all shaders requested by developers and testers in Profile builds, and store the required permutations in a text file. If this is done during the full development of a game, eventually we will have a complete list of all required shader permutations to run the game. Once we are ready to ship, we can then use the Shader Cache Generator to parse the text file containing all required shader permutations for our game, and compile them. We can then create .pak archives containing our shader cache, allowing our game to quickly load all required shader binaries into memory at start-up - resulting in a build where no shader has to be compiled at run-time. Using the Remote Shader Compiler The Remote Shader Compiler is contained in the <engine folder>/Tools/RemoteShaderCompiler/ directory, and can be run via the CrySCompileServer .exe executable. Once run, any number of profile builds from other machines (assuming that the address and port 61453 is reachable) can connect to it in order to request shader compilation. In order to connect to a remote shader compiler, you will need to set the r_ShadersRemoteCompiler CVar to 1 at start-up, and r_ShaderCompilerServe r to the IP address of the machine you want to connect to. For example, this can be put into your .cryproject as below: { "name": "r_ShadersRemoteCompiler", "value": "1" }, { "name": "r_ShaderCompilerServer", "value": "127.0.0.1" } Instead of compiling shaders locally, the game (and Editor) will then contact the shader compiler server any time a permutation is missing from the local cache. If compilation is successful, the remote shader compiler returns the compiled shader and stores the permutation under <engine folder> /Tools/RemoteShaderCompiler/Cache/Assets/ShaderList_PC.txt. Make sure to keep a copy of the shader list, it might make sense to check it into version control as it is vital to have an up to date list of shader permutations used for the game - in case a release build needs to be created at any point in time. Compiling the Shader Cache The Shader Cache Generator is contained as <engine folder>/bin/win_x64/ShaderCacheGen.exe, and is used to compile all permutations specified in a shader list (see the section above) in one go - providing a cache that can then be archived and sent to end-users. To run the Shader Cache Generator, we first need to copy our shader list from the remote shader compiler, in our case <engine folder>/Tools /RemoteShaderCompiler/Cache/Assets/ShaderList_PC.txt. This should be copied to <project folder>/USER/ShaderList.txt. We can then run the following command: bin/win_x64/ShaderCacheGen.exe -noprompt -anygpu +r_driver=DX11 +r_ShadersAsyncCompiling=3 +r_ShadersAsyncMaxThreads=16 +r_ShadersUserFolder=1 +r_ShadersUseInstanceLookUpTable=1 +r_ShadersSubmitRequestline=0 +r_ShaderTarget=DX11 +r_PrecacheShaderList This should start the Shader Cache Generator, and immediately start compiling a DX11 shader cache into the USER directory. Once complete, you can follow the steps in the section below to create the shader cache archives. Creating the Shader Cache Archives Once we've compiled the shader cache, we need to archive it into .pak files to be loaded by the engine on start-up. This can be done by running the <e ngine folder>Tools/PakShaders.bat script as follows: Confidential. © 2009-2015 Crytek GmbH. All Rights Reserved. Page 1 of 4 Tools/PakShaders.bat d3d11 . The first parameter taken is the platform we compiled compilers for, in our case DX11. The second parameter denotes the engine root directory, in our case the current directory. Once complete, the shader cache archives will be output to the Engine/ directory where they can be included in a release build. The Resource Compiler allows for creating jobs, an XML definition of how a project should be packaged. This job can be run to automatically compile textures and objects for the target platform, and creating .pak files that can be read by the end-user. An example can be seen below: Confidential. © 2009-2015 Crytek GmbH. All Rights Reserved. Page 2 of 4 MyJob.xml <RCJobs> <DefaultProperties src="../../" tmp="RCTemp_${p}" trg="${src}/RCOut_${p}" /> <Properties src_assets="${src}/Assets" tmp_assets="${tmp}/assets" trg_assets="${trg}/assets" src_engine="${src}/Engine" /> <PakEngineAssets> <Job input="${src}/Engine/*.tif" targetroot="${tmp}/" imagecompressor="CTsquish" streaming=" 0" /> <Job Input="${src_engine}/*.cfg;${src_engine}/*.thread_config;${src_engine}/*. xml;${src_engine}/*.txt;${src_engine}/*.mtl;${src_engine}/*.cgf;*${src_engine}/*.pfxp;${src_engine}/*. lut;${src_engine}/*.dat;${src_engine}/*.ttf;${src_engine}/*.ext" Zip="${trg}/Engine/Engine.pak" /> <!-- Copy DDS files in Engine folder that don't have tifs --> <Job Input="${src}/Engine/*.dds" Zip="${trg}/Engine/Engine.pak" /> <!-- Move converted tifs --> <Job Input="${tmp}/Engine/*.dds" Zip="${trg}/Engine/Engine.pak" /> </PakEngineAssets> <Animations> <Job input="*.i_caf" animConfigFolder="Animations" sourceroot="${src_assets}" targetroot="${tmp_assets}" cafAlignTracks="1" dbaStreamPrepare="1"/> <Job sourceroot="${src_assets}" input="Animations/*.xml;Animations/*.animevents;Animations/*. bspace;Animations/*.comb;Animations/*.adb;Animations/*.chrparams" zip="${trg_assets}\Animations.pak" Zip_SizeSplit="1" Zip_MaxSize="1900000"/> <Job sourceroot="${tmp_assets}" input="Animations/*.dba;Animations/*.img" zip="${trg_assets} \Animations.pak" Zip_SizeSplit="1" Zip_MaxSize="1900000"/> </Animations> <Audio> <Job sourceroot="${src_assets}" input="Audio/ace/*.xml;Audio/Wwise/Sounds.bnk" zip="${trg_assets}\Audio.pak" Zip_SizeSplit="1" Zip_MaxSize="1900000"/> </Audio> <GameData> <Job sourceroot="${src_assets}" input="Libs/*.xml;*.pfx;Libs/*.mtl;Libs/*.swf;*. schematyc_ent;*.schematyc_lib;Materials/*.mtl" zip="${trg_assets}\GameData.pak" Zip_SizeSplit="1" Zip_MaxSize="1900000"/> </GameData> <Objects> <Job sourceroot="${src_assets}" input="Objects/*.cgf;Objects/*.dds;Objects/*.mtl;Objects/*. cdf;Objects/*.chr;Objects/*.skin;Objects/*.chrparams" zip="${trg_assets}\Objects.pak" Zip_SizeSplit="1" Zip_MaxSize="1900000"/> </Objects> <Textures> <Job input="${src_assets}/*.tif" targetroot="${tmp_assets}" imagecompressor="CTsquish" streaming="0" /> <Job Input="${tmp_assets}/*.dds" Zip="${trg}/Assets/Textures.pak" Zip_SizeSplit="1" Zip_MaxSize="1900000"/> </Textures> <Run Job="PakEngineAssets" /> <Run Job="Animations"/> <Run Job="Audio"/> <Run Job="GameData"/> <Run Job="Objects"/> <Run Job="Textures"/> </RCJobs> Confidential. © 2009-2015 Crytek GmbH. All Rights Reserved. Page 3 of 4 This example will compile assets that need to be changed for the target platform, and output .pak archives into a RCOut_PC/ directory at the root of the project. This can be run as follows: Tools/rc/rc.exe /job=MyJob.xml /threads Depending on the size of your project, this can take a while. Once complete, we can move the shader cache archives we created into the RCOut_PC/ directory. This will give us a complete asset package that, after we follow the steps below on building the engine, can be run and sent out to end-users. This section assumes that you have already read Building the Engine from Source Code. Once you have a solution containing both the engine and your project, simply change the configuration mode to Release: In addition, it is recommended to enable OPTION_STATIC_LINKING in CMake when building a release configuration. This ensures that all CRYENGINE binaries get linked into one main executable. Once built, you can run the build through bin/win_x64_release. When shipping a build to your end-users, always consult the table below to determine what you are allowed to ship - and to ensure that you don't ship data that can't be used. Be careful to not ship the bin/win_x64/ or bin/win_x64_debug/ or Editor/ folders to end-users. This is not permitted by the CRYENGINE EULA - if you have a need to ship the Editor to
Recommended publications
  • Shading in Valve's Source Engine
    Advanced Real-Time Rendering in 3D Graphics and Games Course – SIGGRAPH 2006 Chapter 8 Shading in Valve’s Source Engine Jason Mitchell9, Gary McTaggart10 and Chris Green11 8.1 Introduction Starting with the release of Half-Life 2 in November 2004, Valve has been shipping games based upon its Source game engine. Other Valve titles using this engine include Counter-Strike: Source, Lost Coast, Day of Defeat: Source and the recent Half-Life 2: Episode 1. At the time that Half-Life 2 shipped, the key innovation of the Source engine’s rendering system was a novel world lighting system called Radiosity Normal Mapping. This technique uses a novel basis to economically combine the soft realistic 9 [email protected] 10 [email protected] 11 [email protected] 8 - 1 © 2007 Valve Corporation. All Rights Reserved Chapter 8: Shading in Valve’s Source Engine lighting of radiosity with the reusable high frequency detail provided by normal mapping. In order for our characters to integrate naturally with our radiosity normal mapped scenes, we used an irradiance volume to provide directional ambient illumination in addition to a small number of local lights for our characters. With Valve’s recent shift to episodic content development, we have focused on incremental technology updates to the Source engine. For example, in the fall of 2005, we shipped an additional free Half- Life 2 game level called Lost Coast and the multiplayer game Day of Defeat: Source. Both of these titles featured real-time High Dynamic Range (HDR) rendering and the latter also showcased the addition of real-time color correction to the engine.
    [Show full text]
  • Learning Human Behavior from Observation for Gaming Applications
    University of Central Florida STARS Electronic Theses and Dissertations, 2004-2019 2007 Learning Human Behavior From Observation For Gaming Applications Christopher Moriarty University of Central Florida Part of the Computer Engineering Commons Find similar works at: https://stars.library.ucf.edu/etd University of Central Florida Libraries http://library.ucf.edu This Masters Thesis (Open Access) is brought to you for free and open access by STARS. It has been accepted for inclusion in Electronic Theses and Dissertations, 2004-2019 by an authorized administrator of STARS. For more information, please contact [email protected]. STARS Citation Moriarty, Christopher, "Learning Human Behavior From Observation For Gaming Applications" (2007). Electronic Theses and Dissertations, 2004-2019. 3269. https://stars.library.ucf.edu/etd/3269 LEARNING HUMAN BEHAVIOR FROM OBSERVATION FOR GAMING APPLICATIONS by CHRIS MORIARTY B.S. University of Central Florida, 2005 A thesis submitted in partial fulfillment of the requirements for the degree of Master of Science in the School of Electrical Engineering and Computer Science in the College of Engineering and Computer Science at the University of Central Florida Orlando, Florida Summer Term 2007 © 2007 Christopher Moriarty ii ABSTRACT The gaming industry has reached a point where improving graphics has only a small effect on how much a player will enjoy a game. One focus has turned to adding more humanlike characteristics into computer game agents. Machine learning techniques are being used scarcely in games, although they do offer powerful means for creating humanlike behaviors in agents. The first person shooter (FPS), Quake 2, is an open source game that offers a multi-agent environment to create game agents (bots) in.
    [Show full text]
  • Investigating Steganography in Source Engine Based Video Games
    A NEW VILLAIN: INVESTIGATING STEGANOGRAPHY IN SOURCE ENGINE BASED VIDEO GAMES Christopher Hale Lei Chen Qingzhong Liu Department of Computer Science Department of Computer Science Department of Computer Science Sam Houston State University Sam Houston State University Sam Houston State University Huntsville, Texas Huntsville, Texas Huntsville, Texas [email protected] [email protected] [email protected] Abstract—In an ever expanding field such as computer and individuals and security professionals. This paper outlines digital forensics, new threats to data privacy and legality are several of these threats and how they can be used to transmit presented daily. As such, new methods for hiding and securing illegal data and conduct potentially illegal activities. It also data need to be created. Using steganography to hide data within demonstrates how investigators can respond to these threats in video game files presents a solution to this problem. In response order to combat this emerging phenomenon in computer to this new method of data obfuscation, investigators need methods to recover specific data as it may be used to perform crime. illegal activities. This paper demonstrates the widespread impact This paper is organized as follows. In Section II we of this activity and shows how this problem is present in the real introduce the Source Engine, one of the most popular game world. Our research also details methods to perform both of these tasks: hiding and recovery data from video game files that engines, Steam, a powerful game integration and management utilize the Source gaming engine. tool, and Hammer, an excellent tool for creating virtual environment in video games.
    [Show full text]
  • Design and Implementation of a Single-Player First-Person Shooter Game Using XNA Game Development Studio
    Final Report Design and implementation of a single-player first-person shooter game using XNA game development studio Master of Science Thesis in the Department of Computer Science and Engineering Hatice Ezgi TUGLU Kahraman AKYIL Chalmers University of Technology Department of Computer Science and Engineering Göteborg, Sweden, 2010 The Author grants to Chalmers University of Technology and University of Gothenburg the non-exclusive right to publish the Work electronically and in a non-commercial purpose make it accessible on the Internet. The Author warrants that he/she is the author to the Work, and warrants that the Work does not contain text, pictures or other material that violates copyright law. The Author shall, when transferring the rights of the Work to a third party (for example a publisher or a company), acknowledge the third party about this agreement. If the Author has signed a copyright agreement with a third party regarding the Work, the Author warrants hereby that he/she has obtained any necessary permission from this third party to let Chalmers University of Technology and University of Gothenburg store the Work electronically and make it accessible on the Internet. Design and implementation of a single-player first-person shooter game using XNA game development studio Hatice Ezgi TUGLU Kahraman AKYIL © Hatice Ezgi TUGLU, October 2010. © Kahraman AKYIL, October 2010. Examiner: Per ZARING Chalmers University of Technology University of Gothenburg Department of Computer Science and Engineering SE-412 96 Göteborg Sweden Telephone + 46 (0)31-772 1000 Department of Computer Science and Engineering Göteborg, Sweden October 2010 1 | P a g e HUMANKILLERS Will you keep your promise? 2 | P a g e Abstract “Humankillers” is a name of the game that was developed for Master Thesis in Computer Science Department at Chalmers University of Technology.
    [Show full text]
  • Comparison of Unity and Unreal Engine
    Bachelor Project Czech Technical University in Prague Faculty of Electrical Engineering F3 Department of Computer Graphics and Interaction Comparison of Unity and Unreal Engine Antonín Šmíd Supervisor: doc. Ing. Jiří Bittner, Ph.D. Field of study: STM, Web and Multimedia May 2017 ii iv Acknowledgements Declaration I am grateful to Jiri Bittner, associate I hereby declare that I have completed professor, in the Department of Computer this thesis independently and that I have Graphics and Interaction. I am thankful listed all the literature and publications to him for sharing expertise, and sincere used. I have no objection to usage of guidance and encouragement extended to this work in compliance with the act §60 me. Zákon c. 121/2000Sb. (copyright law), and with the rights connected with the Copyright Act including the amendments to the act. In Prague, 25. May 2017 v Abstract Abstrakt Contemporary game engines are invalu- Současné herní engine jsou důležitými ná- able tools for game development. There stroji pro vývoj her. Na trhu je množ- are numerous engines available, each ství enginů a každý z nich vyniká v urči- of which excels in certain features. To tých vlastnostech. Abych srovnal výkon compare them I have developed a simple dvou z nich, vyvinul jsem jednoduchý ben- game engine benchmark using a scalable chmark za použití škálovatelné 3D reim- 3D reimplementation of the classical Pac- plementace klasické hry Pac-Man. Man game. Benchmark je navržený tak, aby The benchmark is designed to em- využil všechny důležité komponenty her- ploy all important game engine compo- ního enginu, jako je hledání cest, fyzika, nents such as path finding, physics, ani- animace, scriptování a různé zobrazovací mation, scripting, and various rendering funkce.
    [Show full text]
  • A Novel Multithreaded Rendering System Based on a Deferred Approach
    VIII Brazilian Symposium on Games and Digital Entertainment Rio de Janeiro, RJ – Brazil, October, 8th-10th 2009 A Novel Multithreaded Rendering System based on a Deferred Approach Jorge Alejandro Lorenzon Esteban Walter Gonzalez Clua Universidad Austral, Argentina Media Lab – UFF, Brazil [email protected] [email protected] Figure 1: Mix of the final illuminated picture, the diffuse color buffer and the normal buffer Abstract Therefore, the architecture of newer game engines must include fine-grained multithreaded algorithms This paper presents the architecture of a rendering and systems. Fortunately for some systems like physics system designed for multithreaded rendering. The and AI this can be done. However, when it comes to implementation of the architecture following a deferred rendering there is one big issue: All draw and state rendering approach shows gains of 65% on a dual core calls must go to the graphics processing unit (GPU) in 1 machine. a serialized manner . This limits game engines as only one thread can actually execute draw calls to the Keywords : multithreaded rendering, deferred graphics card. Adding to the problem, draw calls and rendering, DirectX 11, command buffer, thread pool state management of the graphics pipeline are expensive for the CPU as there is a considerable overhead created by the API and driver. For this 1. Introduction reason, most games and 3D applications are CPU Game engines and 3D software are constantly bound and rely on batching 3D models to feed the changing as the underlying hardware and low level GPU. APIs evolve. The main driving force of change is the pursuit of greater performance for 3D software, which Microsoft, aware of this problem, is pushing means, pushing more polygons with more realistic forward a new multithreaded graphics API for the PC, models of illumination and shading techniques to the Direct3D11.
    [Show full text]
  • Remote Exploitation of the Valve Source Game Engine
    Remote exploitation of the Valve Source game engine Amat Cama Agenda ● Introduction ● Prior Work ● Motivation ● Game Engine ? ● Valve Source Engine ● Hunting for Bugs ● Conclusion and Future Work 2 Introduction Introduction Amat Cama ● Senior Security Researcher at Chaitin Tech ● CTF player, team Shellphish ● Pwning ● asdf Beijing Chaitin Tech Co., Ltd: ● chaitin.cn/en ● Pentesting services and entreprise products ● D-Sensor - Threat Perception System ● SafeLine - Web Application Firewall ● Chaitin Security Research Lab: ➔ GeekPwn 2016 awardees: PS4 Jailbreak, Android rooting, Router rooting, <this project> rd ➔ Pwn2Own 2017 3 place: Safari + root, Firefox + SYSTEM, Ubuntu root, macOS root nd ➔ CTF players from team b1o0p, 2 place at DEFCON 2016 4 Prior Work Prior Work ● “Multiplayer Online Games Insecurity” - Luigi Auriemma & Donato Ferrante: ● https://media.blackhat.com/eu-13/briefings/Ferrante/bh-eu-13-multiplayer-onl ine-games-ferrante-wp.pdf ● Ideas and methodologies for attacking game engines ● “Exploiting Game Engines For Fun & Profit” - Luigi Auriemma & Donato Ferrante: ● https://revuln.com/files/Ferrante_Auriemma_Exploiting_Game_Engines.pdf ● Study of a number of games and game engines ● Number of bugs ● “Game Engines: A 0-day’s tale” - Luigi Auriemma & Donato Ferrante ● http://revuln.com/files/ReVuln_Game_Engines_0days_tale.pdf ● Describes a number of bugs in different games and game engines ● ... 6 Motivation Motivation ● Because it is fun ● Fairly new area of research; great opportunity to learn ● Millions of players every day ● How hard would it be to get hacked by just connecting to a game server ? 8 Game Engine ? Game Engine ? What is a Game Engine (I) ? ● TL;DR: The “Kernel” of the game ● Software framework designed for the creation and development of video games ● Reusable code that provides functionality such as a renderer for 2D or 3D graphics, physics, sound, scripting, networking..
    [Show full text]
  • Exploiting Game Engines for Fun & Profit
    Paris, May 2013 Exploiting Game Engines For Fun & Profit Luigi Auriemma & Donato Ferrante Who ? Donato Ferrante Luigi Auriemma @dntbug ReVuln Ltd. @luigi_auriemma Re-VVho ? - Vulnerability Research - Consulting - Penetration Testing REVULN.com 3 Agenda • Introduction • Game Engines • Attacking Game Engines – Fragmented Packets – Compression Theory about how to – Game Protocols find vulnerabilities in game engines – MODs – Master Servers • Real World Real world examples • Conclusion ReVuln Ltd. 4 Introduction • Thousands of potential attack vectors (games) • Millions of potential targets (players) Very attractive for attackers ReVuln Ltd. 5 But wait… Gamers ReVuln Ltd. 6 But wait… did you know… • Unreal Engine => Licensed to FBI and US Air Force – Epic Games Powers US Air Force Training With Unreal Engine 3 Web Player From Virtual Heroes. – In March 2012, the FBI licensed Epic's Unreal Development Kit to use in a simulator for training. ReVuln Ltd. 7 But wait… did you know… • Real Virtuality => It’s used in military training simulators – VBS1 – VBS2 ReVuln Ltd. 8 But wait… did you know… • Virtual3D => Mining, Excavation, Industrial, Engineering and other GIS & CAD-based Visualizations with Real-time GPS-based Animation and Physical Simulation on a Virtual Earth => SCADA ReVuln Ltd. 9 But wait… did you know… Different people but they have something in common.. They are potential attack vectors • When they go back home, they play games • When they play games, they become targets • And most importantly, their Companies become targets ReVuln Ltd. 10 Game Engines Game Engines [ What ] • A Game Engine is the Kernel for a Game GAME API Sounds Graphics A GAMENetwork ENGINE Maps Animations Content Development Audio Models ReVuln Ltd.
    [Show full text]
  • Mapping Game Engines for Visualisation
    Mapping Game Engines for Visualisation An initial study by David Birch- [email protected] Contents Motivation & Goals: .......................................................................................................................... 2 Assessment Criteria .......................................................................................................................... 2 Methodology .................................................................................................................................... 3 Mapping Application ......................................................................................................................... 3 Data format ................................................................................................................................... 3 Classes of Game Engines ................................................................................................................... 4 Game Engines ................................................................................................................................... 5 Axes of Evaluation ......................................................................................................................... 5 3d Game Studio ....................................................................................................................................... 6 3DVIA Virtools ........................................................................................................................................
    [Show full text]
  • Gamebryo Based Smoke Effect System
    2006:032 HIP BACHELOR'S THESIS Gamebryo Based Smoke Effect System Tobias Björnudd Luleå University of Technology BSc Programmes in Engineering BSc programme in Computer Engineering Skellefteå Campus 2006:032 HIP - ISSN: 1404-5494 - ISRN: LTU-HIP-EX--06/032--SE Gamebryo based Smoke Effect System Tobias Björnudd [email protected] Luleå University of Technology Sweden Bachelors Thesis BSc Programmer in Engineering Campus Skellefteå Foreword This thesis is created for Luleå University of Technology Sweden campus Skellefteå and Resolution Interactive AB, Umeå. The bigger part of the smoke system have been developed in Östersund, Sweden. Resolution Interactive wanted a way to add realistic smoke effects to their Clusterball II title currently under development. I want to thank all the exceptionally nice people at Resolution Interactive. Many thanks also goes to my handling officer Lars Lindström who have been really helpful when it comes to integrating me with the rest of the company. I also want to thank Erik Winter for his programming help and for letting me use his code as example in how to integrate particles in Clusterball II using Gamebryo. Abstract Particle effects used in games nowadays is taken for granted. Almost every game engine that exists today has a complete system for emitting and handling particles. This thesis paper presents a way to utilize the particle system that is provided with the Gamebryo game engine. A basic overview in how to design a smoke effect system is presented. After that a overview of some Gamebryo and Clusterball II classes is given. Then a discussion about the results of this project is held.
    [Show full text]
  • Shading in Valve's Source Engine
    Shading in Valve’s Source Engine SIGGRAPH 2006 Jason Mitchell Valve Introduction ¾ World Lighting • Radiosity Normal Mapping • Specular Lighting ¾ Model lighting • Irradiance Volume • Half-Lambert • Phong terms ¾ High Dynamic Range Rendering • Tone mapping • Autoexposure ¾ Color Correction Timeline ¾ Half-Life 2 and Counter-Strike: Source (November 2004) • Baseline shading model we’ll present today ¾ Lost Coast (October 2005) • High Dynamic Range Rendering ¾ Day of Defeat: Source (September 2005) • Color Correction and HDR ¾ Half-Life 2: Episode One (June 2006) • Phong shading Episodic Content Î Incremental Technology ¾ The extensions to the baseline Half-Life 2 technology have been shipped in subsequent products in the year and a half since HL2 shipped. • More efficient way to develop technology • Delivers value to customers and licensees ¾ Shorten the delay between hardware availability and game support Marketplace Context See full survey at http://www.steampowered.com/status/survey.html World Lighting with Radiosity ¾ Realism ¾ More forgiving than direct lighting only • Avoids harsh lighting situations • Less micro-management of light sources for content production • Can’t tune lights shot-by-shot like movies. Don’t know what the shots are, and don’t want to take the production time to do this Direct lighting only Radiosity lighting Normal Mapping ¾ Reusable high-frequency detail ¾ Higher detail than we can currently get from triangles ¾ Works well with both diffuse and specular lighting models ¾ Can now be made to integrate with radiosity
    [Show full text]
  • John Carmack Archive - Interviews
    John Carmack Archive - Interviews http://www.team5150.com/~andrew/carmack August 2, 2008 Contents 1 John Carmack Interview5 2 John Carmack - The Boot Interview 12 2.1 Page 1............................... 13 2.2 Page 2............................... 14 2.3 Page 3............................... 16 2.4 Page 4............................... 18 2.5 Page 5............................... 21 2.6 Page 6............................... 22 2.7 Page 7............................... 24 2.8 Page 8............................... 25 3 John Carmack - The Boot Interview (Outtakes) 28 4 John Carmack (of id Software) interview 48 5 Interview with John Carmack 59 6 Carmack Q&A on Q3A changes 67 1 John Carmack Archive 2 Interviews 7 Carmack responds to FS Suggestions 70 8 Slashdot asks, John Carmack Answers 74 9 John Carmack Interview 86 9.1 The Man Behind the Phenomenon.............. 87 9.2 Carmack on Money....................... 89 9.3 Focus and Inspiration...................... 90 9.4 Epiphanies............................ 92 9.5 On Open Source......................... 94 9.6 More on Linux.......................... 95 9.7 Carmack the Student...................... 97 9.8 Quake and Simplicity...................... 98 9.9 The Next id Game........................ 100 9.10 On the Gaming Industry.................... 101 9.11 id is not a publisher....................... 103 9.12 The Trinity Thing........................ 105 9.13 Voxels and Curves........................ 106 9.14 Looking at the Competition.................. 108 9.15 Carmack’s Research......................
    [Show full text]