Effects & Techniques

AdvancesinRealTimeRenderingin3DGraphicsandGamesCourse–SIGGRAPH2008 N.Tatarchuk(Editor) Chapter 5 Effects & Techniques DominicFilion1 RobMcNaughton2 1 [email protected] 2 [email protected] 133|Page Chapter 5: StarCraft II: Effects and Techniques Figure 1. A screenshot from StarCraft II 5.0 Abstract In this chapter we present the techniques and algorithms used for compelling storytellinginthecontextoftheStarCraftII©realtimestrategygame.Wewillgoover someofthedesigngoalsforthetechnologyusedtoempowerourartistsforbothin gameand“storymode”settingsaswellasdescribehowtheBlizzardartstyleinfluenced thedesignoftheengine.Variousaspectsofourlightingpipelinewillbeunveiled,witha strongfocusonseveraltechniquesmakinguseofdeferredbuffersfordepth,normals, and coloring components. We will show how these deferred buffers were used to implementavarietyofeffectssuchasdeferredlighting,screenspaceambientocclusion anddepthoffieldeffects.Approacheswithrespecttoshadowswillalsobediscussed. 5.1 Introduction StarcraftIIpresenteduniquechallengesfordevelopmentasasecondinstallmentina wellknown franchise with the first entry dating from ten years before. During the processofdevelopmentwehadtoovercometheseandwewillsharetheengineering 134|Page AdvancesinRealTimeRenderingin3DGraphicsandGamesCourse–SIGGRAPH2008 N.Tatarchuk(Editor) choices that were made in the context of the Starcraft II graphics engine, and in particularhowthesechoicesweremadetosupporttheuniqueBlizzardartstyle. 5.2 EngineDesignGoals Earlyonduringdevelopment,wehadseveralthemesinmindthatwewantedtodrive thedevelopmentofourgraphicsenginewith: ScalabilityFirst Amajordesigngoalisthescalabilityoftheengine.Blizzardgamesarewellknownfor their ability to support a range of consumer hardware, including fairly outdated specifications, while always providing a great player experience. This was typically achieved in our previous games by keeping the playing field pretty even between all players,withaminimalsetof videooptions.ForStarcraftII,wewantedtomaximize compatibilitywithlesscapablesystemstoensurehasslefreegameplayforasbroada playerbaseaspossible.Yetwealsowantedtoutilizethefullpotentialofanyavailable hardwaretoensurethegame’slookswerecompetitive.Thismeantsupportingawide range of hardware, from ATI RadeonTM 9800/NVIDIA GeForceTM FX’s to the ATI RadeonTM HD 4800s and NVIDIA GeForceTM G200s, targeting maximum utilization on eachdifferentGPUplatform. This scalability translated in a fairly elaborate shader framework system. A full discussionofourshadersystemcouldverywellencompassawholechapterbyitselfso wewillnotfocusonithere,sothisisonlyashortoverview. Weonlyhadone ortwoartiststhatwouldactuallyhaveanyinterestinwritingtheir ownshaderssoearlyon,insteadoffocusingonwritingelaborateshaderprototyping tools for artists we decided to focus our efforts on making the shader framework as flexibleandeasytouseforprogrammersaspossible,whichissomewhatcountertothe industrytrendatthistime. Thus,writingshadercodeinourgameisgenerallyveryclosetoaddingaregularC++file inourproject.Figuratively,wetreattheshadercodeasanexternallibrarycalledfrom C++,withtheshadercodebeingafreeformbodyofcodeorganizedstructurallyasaC++ codebasewould.Thus,theconceptofshaderscanbealooseoneinStarcraftII–the shadercodelibrarydefinesseveralentrypointsthattranslatetodifferentshaders,but oneentrypointisfreetocallintoanysectionofshadercode.Thusitwouldbedifficult totalkabouthowmany“individual”shadersStarcraftIIuses,asitisasinglebodyof codefromwhichmorethanathousandshaderpermutationswillgenerallybederived for a single video options configuration. Making our shader framework system as familiar as possible for programmers has enabled us faster turnaround time when debugging shaders. In our case, when our technical artists have some ideas for new 135|Page Chapter 5: StarCraft II: Effects and Techniques shaderstheywillgenerallyprototypeitusing3DStudioMAXrendersandaprogrammer will implement an optimized version of the effect, often times adding reusable abstractionstotheshaderthatmaynothavebeenapparenttoanartist.Inall,Starcraft IIusesabout8,000unique,nonrepeatinglinesofshadercode,dividedamongst70files. Interestinglyenough,we’vecometothepointwherethebodyofshadercodealonehas grownlargerthantheentirecodebaseforgamesfromtheearlystagesofthegames industry. StressGPUoverCPU WechoseearlyontostresstheGPUmorethantheCPUwhenrampingupqualitylevels withinthegame.Oneofthemainreasonsforthisisthat,inStarcraftII,youareableto spawnandmanagepotentiallyhundredsofthesmallerbaseunitssuchaszerglingsand marines.Inlargescalemultiplayergameswitheightplayers,thiscantranslatetoupto roughlyfivehundredunitsonthescreenatasingletime,atpeak.Becausethenumber ofunitsbuiltislargelyunderthecontroloftheplayer(aswellasduetothechoiceof theselectedrace),balancingtheengineloadsuchthatCPUpotentialiswellutilizedin bothhighunitcountandlowunitunitcountsituationsbecomescumbersome. Figure 2. Players can control a very high number of units, thus balancing batch counts and vertex throughputs is key to reliable performance. 136|Page AdvancesinRealTimeRenderingin3DGraphicsandGamesCourse–SIGGRAPH2008 N.Tatarchuk(Editor) Incontrast,GPUloadsinourcasetendtobemuchmoreaffectedbythepixelshader load, which tends to stay constant for a realtime strategy game because of the generallylowoverdraw.Althoughvertexcountsforaparticularscenecanrampupwell aboveamillioninabusybattlescene,thistypeofvertexthroughputiswellhandledby most modern GPU hardware. This has driven us to push the engine and art styles towardseverincreasingpixelshaderleveleffectswheneverpossible,minimizingbatch countsandusingrelativelyconservativevertexcounts. The Starcraft II units are generally viewed from a good distance away and therefore result in a small screenspace footprint during game play. Therefore, increasing the modelvertexcountswouldhavegivenusmarginalbenefitsduringactualgameplayin mostcases.Forthatreasonweavoidedgeneratingartassetswithlargepolygoncounts. DualNatureoftheEngine StarcraftIIissupportedbyanenginethatinmanywayshasasplitpersonality;during normalgameplaywetypicallyrenderscenesfromarelativelyfarawaydistance,with highbatchcounts,andafocusonactionratherthandetails.Atthesametime,wereally wantedtopushourstorytellingforwardwithStarcraftII,andthisiswherethegame’s “StoryMode”comesin.Inthismode,theplayergenerallysitsbacktotakeinthegame’s rich story, lore and visuals, interacting with other characters through dialogues and watching actions unfold. This is the mode where most of Starcraft II’s storytelling happens and it has radically different and often opposing constraints to the ingame mode;storymodegenerallyboastslowerbatchcounts,closeupshots,andasomewhat morecontemplativefeel–allthingsmoretypicalofafirstpersonshooter. 137|Page Chapter 5: StarCraft II: Effects and Techniques Figure 3. In-game view vs. “story mode” in Starcraft II. 138|Page AdvancesinRealTimeRenderingin3DGraphicsandGamesCourse–SIGGRAPH2008 N.Tatarchuk(Editor) Wewillexplorehowthesedifferentdesigngoalsaffectedouralgorithmicchoices.We will showcase some of our ingame cinematics and peel off some of the layers of technologybehindit,aswellasshowsexamplesofthetechnologyinactualgameplay. 5.3ScreenBasedEffects OneoftheobjectivesforStarcraftIIwastopresentrichlightingenvironmentsinstory mode,aswellasmorelightinginteractionswithinthegameitself.PreviouslyinWarcraft III,eachunithadahardlimitastothenumberoflightsthatcouldaffectitatanygiven time. This would cause light popping as units moved from one of light influences to another.Forthatreason,theuseofdynamiclightingwasfairlyminimal.Atthesame time,usingforwardrenderingapproaches,wewerequicklypresentedwiththeproblem of the large increase in the number of draw call batches. One of thestress cases we used was a group of marines, with each marine casting a flickering light that in turn shades the surrounding marines around him.The batch counts in such cases rapidly became unmanageable, and issues were also present with our deeply multilayered terrainrendering,thusrequiringcomplexterrainslicingandcompoundingtheproblem. The goal to reduce batch counts was the first step that sent us on the road towards using deferred buffers for further treatment at the end of the frame. “Deferred rendering” term (as covered in [CALVER04], [SHISHKOVTSOV05] and in [KOONE07]) often referstothestorageofnormals,depthandcolorstoapplylightingatalater,“deferred” stage.Inourcaseweuseitinthebroadersensetomeananygraphicaltechniquewhich uses this type of deferral, even in cases where a nondeferred approach would have beenviableaswell.We’llexploreissuesandcommonalitieswithallthingsdeferred. Inpractice,we’vefoundmanyprosandconsforusingdeferredcomputationswiththe storageofrelevantinformation,suchasdepthvalues,normals,etc.Althoughstorageof this information consumes memory and bandwidth, as well as the extra cost of re samplingthebuffersattheprocessingstage,itgenerallyhelpsgreatlywithscalabilityby ensuringthecostcurveofeffectstendtostaylinearinsteadofexponential.Whenusing deferredbuffers,addingmorelayersofeffectsgenerallyresultsinalinear,fixedcost perframeforadditionalfullscreenpostprocessingpassesregardlessofthenumberof models on screen, whereas the same effect with forward rendering exhibits an exponential cost behavior. This leads us unto our goal of maximizing resource usage regardlessofwhethertherefiveorfivehundredunitsonthescreen. Keeping batch counts low is paramount for any RTS game. We were thus naturally drawnawayfromtryingtofillupthedeferredbuffersinaseparatepassandinstead relied on multiple render targets (MRTs) to fill the deferred

Load more