Building 'Zeta Halo': Scaling Content Creation for the Largest 'Halo' Ever

[Music] thank you this talk is building Zeta Halo and it's about how we scaled up our content creation tools workflows and best practices to build the largest Halo ever my name is Kurt Geiger my pronouns are he him I'm lead environment technical artist at 343 and my name is Mikhail nelfors pronouns he him and I'm a technical art director at three for three Industries yeah so first I'll walk you through what we're going to talk about today first we'll go over a bit of History both the cultural and technological history of 343 so you can see a bit about where we're coming from then I'll talk about well we'll talk about what our goals were for Halo infinite um then we'll talk through a few of the things we built to achieve those goals we'll

talk about the mass painter system the terrain system we'll talk about the H1 system we'll talk about a few procedural content creation tools and workflows that we developed and finally we'll go through our content scalability system so first I'll hand off to Michael to talk you through the history yeah so as some of you guys know might know a 343 industry was started by Microsoft back in 2007 to take over Halo production from Bungie and uh the Halo infinite is the fourth of uh the studios Halo FPS games and if we look at the campaign specifically about campaign in the previous Halo games they've all been very linear unique and handcrafted they used very specialized workflows that were destructible and time consuming for example there was no terrain system to speak of or really any procedural techniques to fill out the world and they only really targeted one single platform so when we started talking

about Halo infinite and what we need to do we we quickly realized that this was not scalable so some of the goals we set out for ourselves when when we started planning for this was we knew we had to support large open playable spaces that meant we had to improve our iteration speed and stability which means meant that we wanted to invest in modular workflows so we could fill the world with more variety procedural workflow so we could make more content than ever before and non-destructive so we could make it faster and this time around we were going to have to be multi-platform we were not seeing uh longer on a single platform we had to support nine-year-old Hardware with the Xbox one up until the high-end PC you will hear us talk a little bit later in the talk where we refer to low spec that is we mean Xbox One and low end PC and we will say Ultra spec that's a high-end PC and to give you an idea of kind of what

challenge we have how big of a challenge we had here on the left side here you can see a top down of all our campaign levels for Halo 5. and on the right side you can see the the main campaign Island we had and if you would add these Halo 5 levels on top of the campaign Outlet it covers about 10 so we really had to do something to be able to fill this world with with enough content so now I'm going to hand off to Kurt that's going to talk about some of the first of those uh improvements that we spend time on yeah so first I'll talk about the mask painter system um so as Michael mentioned we invested in modular workflows for Halo infinite um the example here is a wall that's built out of different configurations from the same set of modular pieces so one of the goals of the mass paint system was to help us tie those together visually for example by painting a rust streak that runs across multiple modular

pieces um but we also wanted the mass painter system to be able to uh create the illusion of more variety by uh being able to paint different variations of our non-modular pieces um we knew we wanted the mass painter to be what you see is what you get we wanted to be able to paint on the actual Assets in the actual levels and the actual lighting situations and see the material update in real time um which was about improving our iteration time um we also wanted the mass paint system to be non-destructive and art directable again to help us to iterate quickly um one interesting goal of the mass paint system is we didn't want to introduce any additional popping with it and finally we needed it to be affordable both in terms of memory and runtime performance um so the design of the mass paint

system one of the first decisions we made was to go with texture-based masks rather than vertex colors to drive the material Blends um one of the main reasons for that was vertex color based material Blending Systems you can get pops between the Geo Lots um the the shape of a rust patch for example can shift by a surprising amount in between Geo Lots so as soon as we decided to go with texture-based masks we knew that memory was going to be something we're going to have to keep an eye on so we built a lot of features into the system to keep that under control the artists specify the resolution of each mask they paint they usually pick 64 or 128 um we also built tools to audit that content afterwards to catch the few giant masks that inevitably slip through the cracks um also we didn't want to mass paint unique

masks onto every placement of every asset we sort of only wanted to paint enough to create the illusion that everything was unique so we built some tools around setting up what we called variants and reusing them whenever possible to minimize how many mass we needed um so in the end it wasn't as much memory as we were worried to do texture-based masks it was on average in campaign about 60 Megs worth of mass textures loaded on Ultra spec and about 37 Megs of mass textures on low spec um and our napkin math was that if we'd have done it with vertex colors instead of with textures it would have been about 10 Megs of additional memory um so um The Mask painting system we've built and go to the next slide is um it's fast it's wysiwyg we can paint across multiple meshes simultaneously here you can see an example of using it in an actual level

um the panel on the bottom right shows the the names of the layers that are exposed to an artist so they can paint on any number of those at the same time or on different meshes at the same time um and get fast workflows over here you can see some of our our variant oriented stuff at first we're painting on the same mask on two different doors um and then we set up a new variant here so that that door is unique um and jump to the next slide um so part of the mass paint system is the the Shader interface that reads those masks um we started out with we had layered shaders on previous Halo games that sort of we evolved that layered Shader along with the mask painting system uh but where we eventually landed is we were not tied to use a specific Uber Shader for all of our Mass painting we could annotate any texture in any Shader is mess paintable um including in our

Shader node graph system so here you can see what the interface for that looks like um to set up a texture sampler and a Shader node graph is mass cleanable in the spot where you type in the names for the layers so that unlocks some cool special cases for us for example here we set up the opacity texture on this river is mass paintable which allowed us to very quickly fine tune the blend between that River mesh and that waterfall mesh in a way that wouldn't have been possible before um so a little bit about the implementation of the Mask paint um it runs in the GPU it pretty much has to to be as fast as it needs to be each paint operation is a draw it draws the mesh um and the vertex Shader uses the Mass paint UVS instead of the positions as the positions to like stamp the mesh down into the mask texture we also need

a projection from World space to breaststroke space which is calculated from the camera transform in the mouse position um we support an undo redo step as part of our non-destructive workflows goal um the way undo is implemented is we play back we go back to the beginning of the paint session and play back every stroke in the session except for the last one which is another reason why the actual paint operation needs to be so fast in the undo stack itself just stores the uh that transform from World Space 2 breaststroke space so that we can play it back when the camera is somewhere else so I mentioned we use the mass paint UVS instead of the position originally we used light map UVS for that because it was a unique unwrap that we had to have for a different reason that was already there but part way through the development of Halo infinite

we abandoned 2D light maps in favor of volumetric light Maps so at the time the only thing we needed that UV set for was mask painting so we started to optimize it to do things like enlarge the shells that we intended to paint on and shrink and overlap the shells that we didn't intend to paint on but that ended up being a bit of a problem for us later on when we uh ended up needing that UV set for other things for example the um H1 material composite that I'll talk a bit more about later um so that's the mass paint system now I'll hand back to Michael to talk about the terrain system yeah so looking back at the previous Halo games like I mentioned there was no terrain system or a very destructible so if looking at the terrains they were actually just unique assets nothing specific about them they were generated they were made in my RC brush run through weld machine and they imported as a regular object they had a very

limited number of material layers so if you wanted to have say one biome with a set of materials in one end of a map and then another in the other side you would have to do a lot of extra work The Masks had to be painted or generated by dccs there was no way of doing it in the level in context and see it directly and they had to be optimized by hand all by that we've still used it to great effect just kind of show some examples back from Halo 5 uh the terrains that actually was made with this which for the time worked really well but if for example on this map attack on sanctum this is what the actual terrain mesh looks like and it was actually split up into multiple sections so we could allergy it properly and if you look at every single hole you see there all those triangles were deleted By Hand by an artist every iteration just because they were covered by rocks or other placement so to get

perf back they deleted them by Hana you can see how much of a Time sink this was so we could not continue like this uh so some of the goals we set out for ourselves again we wanted the what you see is what you get to to speed up our iteration speed we needed to support small to large landscape small like something like live fire from a Halo internet which is a small Arena map 120 by 120 meters to something as large as the our campaign Island which is seven and a half by seven and a half kilometers it needed to support multiple users working at it at the same time so we don't lock up files and or areas and that includes being able to paint down materials gets physics material with effects and sound getting ground cover generation procedurally with it it need and it needed to be non-destructive and play platform scalable so where we ended up was very inspired by Far Cry and the Talks by Horizon zero Dawn and

it's the design we went with is a tile height map it is quadril based and as the player moves around times of appropriate size and resolution are generated and loaded into memory in Virtual textures and you can see on this uh hopefully it's not lagging as much as it for me uh you can see on the screen here when we're moving around the square instead of flashing by is when we are requesting these new tiles to get generated I was switching to them and each of those tiles contains height physical based shading inputs like Albedo and roughness and things like wetness and micro displacement and to scale performance we in memory we scale the distance of when we are generating and switching these as well as how many of these virtual texture tiles that we do per frame and the geometry we render its runtime for the train is basically just the greater verts uh one per height pixels so the terrain geometric details further from the camera is tied directly to the amount of hyper data that is loaded into the virtual texture that was true until we had we wanted to

add more detail into this so we added what a feature We call we call it micro displacement and we take the Blended Heights from our material layers and offset the vertex positions basically to get more detail and we all are really only subdividing our grid of words even further to get that detail and we this is something we also can control per platform and even though our art is referred to this as tessellation it's actually not Hardware tessellation uh it turned out that was it was faster for us to just subdivide it further and continue with the kind of uh uh Tech that we were using already um and now I'm going to take a step back and kind of look at the overall of how the terrain system works these are basically the high level parts of our system and it really is divided up into two sections we have an offline section and a runtime section and in the offline section everything is run really by masks so we

have our height Maps or masks or user created masks that are then fed into two sets of graphs and we're going to talk a bit more about these graphs in a bit so we have something we call a sculpting graph that controls the geometry of our train and we have something we call the surfacing graph that controls our materials and ground cover this then gets optimized for runtime so we optimize the masks and logic to get it into the format that's faster and then that is what we were seeing in that video earlier where we're requesting the various tiles and that gets generated into the virtual textures as well as masks that are used for our runtime ground cover and the virtual texture also goes into random materials so the artist has the ability to do additional things that are not supported in a virtual texture per se things like if they wanted say sand blowing across the train or small ripples in water puddles those kind of things they can do in there and we although we did actually end up with

two modes of our terrain system and what I just described was our runtime version which is a compilation for edit time we run the entire thing live it skips the optimization step and the virtual texture and this was basically because we wanted the what you see is what you get so we wanted the fastest possible iteration time and we but still needing the fast runtime the downside with this approach turned is that we ended up with slightly Divergent code paths which has caused some issues with bugs with inconsistencies and we also add a cost of compiling when we commit an edit which can be get bigger for if the level is really big and this is something that we are looking into how we can improve in the future and get down to just one while still retaining the fast edit and fast runtime but now we're going to talk about the graphs and I'm going to first hand off to Kurt that's going to talk about our

sculpting graph so as Michael mentioned uh the sculpting graph is the one that controls the geometry of the terrain so originally it didn't do a whole lot except take the height maps that the artist sculpted with our sculpting tools and generate a normal map from that um but pretty soon we started to add a visual flare to the terrain that we could apply in a non-destructive way to that height map the artist's sculpt um so a bit about the sculpting graph it runs offline in the runtime terrain case the results of the sculpting graph are saved out is textures on disk but we also support the ability to run the sculpt and graph in real time for our wysiwyg edit mode the sculpting graph is implemented as a render graph which is basically a way that we built to expose the ability to do node-based Graphics programming to content teams so if you

jump to the next slide we can look at an example sculpting graph let me see what it does here so we're doing stuff like uh we're getting the surface for the height map getting the bindless index for that height map we're allocating a temporary buffer here and plugging in that bindless index putting that into a constant buffer and feeding it to this dispatch compute Shader node here so as you can imagine this exposes a ton of power to the content teams but it's also you know it's pretty easy to do things like cause tdrs in here um so we definitely had to work closely with rendering as we built these guys um so some of the things we built with this one of the first ones was our road system the way this works is the artist can place bezier spline control points in the world which have settings on them like width and opacity and fall off those bezier spline control points are

verts in a draw call in the sculpting graph which then has a geometry Shader stage that evaluates the spline and breaks it up into quads it also does uh blur paths along the spline to mitigate some of the stair stepping artifacts we could get in extreme cases you can see this checkerboard pattern here so another thing we do in our roads we can output textures from the sculpting graph other than just height maps that can then be uh we can make an arbitrary number of inputs to the surfacing graph later on so we use this to do to do things like make a mud material show up in these tire tracks in a texture that's mapped along the spline and makes the high points have a grass texture on them the next thing we built in the sculpin breath was the terrain volume system which conceptually is like

uh layers in Photoshop for the terrain system where this came from originally was we had one artist responsible for sculpting the terrain inside of the base that you can see here in different world artists were responsible for the terrain that the base happens to be on top of and we needed a way for all those artists to work at the same time without fighting to check out the same set of files uh so the way terrain volumes work is in the sculpt graph it's a draw call that draws a quad aligned with the volume um down into the terrain's height map and other input masks like the biome mask and the road Mast um and there's also an opacity mask on the volume that the artist can fine tune separately um another thing we do in the sculpting graph is we made ourselves a hook so that we can go off and do things in Houdini that are a bit more fiddly and subject to

iteration than our native terrain features um so we use this as a spot to run an erosion Sim in Houdini um and bring it back into the terrain as well as what we call macro textures which are things like normal maps that have interesting bumps in them and interesting color shifts in the Albedo to just provide a little bit more breakup for that finally another thing we do in the sculpting graph is we have this idea of wetness so the wetness is is kind of like another height map that describes where the water table is um we use this to do things like uh create the appearance of mud around the edges of the lake instead of just dirt um so uh in the sculpting graph rather than carry around another 16-bit height map um we compress this relative to where the terrain Heights surfaces I'm

going to write it we write it into the turians virtual textures which we can then we can sample that later on from from anywhere for example here you can see a rock that's sampling into the terrain's virtual textures to decide where to draw that wet material change along itself yeah so that's the sculpting graph now I'll hand back to Michael to talk a bit about the surface and graph yeah so as I mentioned earlier uh this just reiterate sculpting graph controls the geometry the surfacing graft and I want to talk about now is the materials and ground cover on the train and the sculpt the surfacing graph really consists of three different parts so the you have here what's highlighted here is the inputs which are masks and they are either masks coming from the skeleton graft that Kurt just mentioned or their masks that are created by the artists they they want to do something specific with so they have control to add an arbitrary number of masks then on our

right side we have outputs and outputs are either material layers which are discrete single material layers that include has like color information normal height and physics material or they are placements and placements are either procedurally generated ground cover or we have some limited Support also for audio and effects and then in the middle we have our node-based rule system this is where the artist has full control to do whatever they really want with the mask to get the result thereafter so they can combine the mask subtract them from each other kind of if they want like uh card were mentioning if you have a gradient in a mask you can tell it to blend in a certain material in the first part of that gradient so we go from rough gravel to finer sand all those kind of things is in the artist's hands and I was just want to show a quick example of it this is me in edit mode in our edit uh with the wig mode playing

around with just with some of our uh ground covers so we have full control over spacing size what type it is so we can just switch it on the Fly and that goes for both the like the ground cover as well as materials so it makes it really fast for for our artists to work with and figure out kind of what is the look that they're after and this works of course with everything every all the sculpting tools and painting tools just like uh it should do and so if we're sculpting everything follows along and the rules that are are applied and something that our artists used a lot was that we created they created what they call biomasks which drives a whole lot of things so instead of painting individual masks they added so they have the ability to switch out all the materials and all the ground covers just by painting into one type of mask instead and all that control also control over how the UI looks in terms of names of masking grouping and all that is control in the surface and graph

by the artist so we want it to be as much as possible controllable by them so they can set it up in the best way possible for them to work and you might have seen it in in that video it's flashed by but this is just an example of how big something it kind of grows very quickly and for the campaign Island which is our biggest level that graph group quite a lot so we had a total of 22 input masks 53 ground cover placement as 65 different material outputs as well as 24 audio and 19 FX placements so at the same time give them the power but also make sure to keep track of uh what's going on so they don't go overboard and that kind of concludes what we want to talk about on the terrain side I just want to end with showing some of the examples from what what the team were doing with this Tech uh and we're honestly I'm just blown away what they were able to do uh because it's it's new to the studio but

it didn't stop them and I'm curious to see what they do in the future with it uh and now I'm gonna hand over to Kurt that's gonna talk about some of the other improvements we did and he's going to start with age Lots we did build H logs for previous Halo games but that was very much a manual process and we knew from day one that it was never going to scale up uh for Halo infinite um we also knew uh that we tend to have high fidelity um assets so we talked about the mass painting system that generally means um the pixel shaders for a lot of our geometry carries around four layers that it Blends together in real time um we have a number of other heavy pixel Shader features like sampling into the train spiritual textures or triplanar mapping or relaxed cone step mapping

we also tend to have pretty heavy geometry in the top image here you can see our lod0 geometry in particular those repeating teeth are difficult to reduce with regular lot methods um so we were attracted to the simply gone remeasure as a way to solve both of those problems to it has the ability to bake geometric detail like those teeth to texture detail and the H rods which you can see in the example H below um it bakes all of our shaders down into a single set of textures for the h slot which by the way we uh we did have to fix a few bugs there that we created for ourselves by over optimizing the mass paint UVS because the H1 material composite needs that same UV set to bake the textures down for us um so

um we knew when we started out with age lots that um low spec was where we would need the GPU savings the most um but we also knew that low spec was where we would have the least amount of memory to spare um in fact we didn't even really know how much memory we could use on H Foods we had an idea that we were going to try to fit into a hundred Megs of content memory for H rods but in any case we knew that balancing all of those conflicting needs was going to be tricky so the way we approached it was we built a lot of controls into the h-loud system so we have controls for each HH lot around reduction and remeshing settings we have controls over which meshes are included or excluded from H slots um we can place stage slots manually as volumes um at any level of the hierarchy and we also have a system that automatically subdivides the world into a grid of age floods at any level of the

hierarchy um and we have a lot of multipliers for things like quality and switch distance that we can tune on each individual H law so once we built all those controls uh we started out iterating to try and figure out where the best balancing point was just by trial and error and I think we learned some interesting things along the way um originally we anticipated we were going to need to exercise a lot of control over exactly which meshes are allowed to go into an hlot and which aren't to try to keep the memory cost down and the quality up um but what we discovered is the simplygun re-measure it does such a great job of deciding for you what to include and what to leave out of the remeshed mesh it builds um that we were able to pretty much just throw everything at simply gone give it one quality setting that we tuned per H lab and let's simply gone figure out what to

keep um with one minor caveat that if you throw if you throw everything everything at it um it tends to uh you tend to run out of memory so in a few cases we had to uh split H Rod volumes up into two smaller h block volumes um which is a relatively straightforward fix um we also anticipated we would need to specify texture resolution in geometric quality really fine tune that on a per H Rod level but again what we found was that that single simply gone remeasured quality setting did a fantastic job of Simply gone just figured out for us how much textures it needed to use for each H slot um we talked a bit about modular workflows earlier so we had a modular workflow of sorts for rocks which is that we had six or seven Rock meshes that we built our Cliff walls and Things by bashing together um which is a good workflow for the artists because it's fast you can get a

high quality result but it has an unfortunate consequence that you end up with a lot of rock geometry that's between two Rock placements or hidden under the ground that you can't see but you still have to pay for so we had hoped to be able to use the simply gone remeasure to turn those into a single efficient shell which it does do but uh we didn't have enough memory to be able to apply that technique to all the rocks in the world um so where we ended up for our hlot setup is we tend to have one parent hlot around each base or a point of interest um you can see the parent hlotter for prison on the bottom left here um underneath that parent volume in the hierarchy or a number of childhood volumes um and the main reason we do that is that it allows us to push a lot of quality into those child volumes which allows us to switch to them surprisingly

close to the camera on low spec to get GPU savings um but then when we're a little bit further away we can switch to that parent H slot and stream out the child Hogs so we don't have to pay for that memory all the time um so I mentioned we were we had an idea that we could fit all our H rods uh into 100 Megs of content memory but interestingly at the end of the trial and error process where we ended up was more like more like 300 Megs of memory Budget on hvlots um so that's the h-lot system next I'll talk a bit about some of our procedural content creation tools um I mentioned in the sculpting graph that we have hooks to do things in Houdini for the terrain um so the way we interface with Houdini is we have a python API to read and write our game data files directly um and we can invoke that API from Houdini which ends up looking like uh it

looks like just loading the map in Houdini um it knows where the terrain is it knows where all the rock placements and the tree placements are and from there we can do a number of things like running erosion Sim or generate our terrain macro textures for some interesting bumps and break up um we use a similar setup to generate flow maps for our River Shader we load the we load the world with the river banks and the rocks and the mesh that's the surface of the river into Houdini and then run a fluid Sim make the results of that back out to a texture that the Shader uses for the river um we have a similar system for our hex placements the hexes is the grid of hexagonal metal Forerunner columns that's the substructure of the ring so the world artists Place those red boxes in the map um and then Houdini loads the map that sees the red boxes um and it has a number of rules to

generate those hex placements on the right grid with the right spacing with the right Randomness along their tops and feeds it back into a custom rendering system that we have for the hexes in the engine um so and I mentioned that we had to give up on our idea of hlotting all of our rocks um so one mitigation we had for all of that hidden Geo that we still had to pay for was we uh we had a tool to non-destructively slice the Rocks into pieces in Houdini um and the benefit of that is we're able to use our runtime visibility calling system um and it's able to hide some portion of those meshes that are completely hidden by the ground or other meshes and it doesn't do a perfect job but it was certainly better than nothing too save us some runtime performance there so that's our procedural content creation tools next I'll hand back to Michael to talk a bit about scalability

yeah so as we mentioned in the beginning the previous Halo games were only really targeting one platform so they had some some scalability built into the engine at that point which is basically the progressive resolution system that scales the the game resolution based on performance as well as the throttling system the scales back certain features like LOD distance is also based on what the performance is but they had very few there were very few scalable systems some parameters was exposed some were hard-coded but overall it was very hard or correct it was very hard to have an overview of what's going on and it was very limited so we went into this knowing that we needed a very flexible system that supported multiple hardware specs like I mentioned in the beginning we had to support Xbox one which is nine year old Hardware by now so it would need to be very extensive we wanted it to be data driven and we we opted for for op that we wanted manual tuning for this and several reasons for

it the one of them we wanted to have content and art director Direction be able to make decisions where to sacrifice visual quality on specific platforms for to get back CPU GPU or memory but also because of the amount of time it takes for an automated system to get things right how to get it the results that you're after how it should know what to choose versus something else and we were not in the we didn't feel like we were at the place where we wanted to do that kind of choice so we opted for manual tuning uh that still we knew that that was still make time take a lot of time but it meant that we had control over what we changed and this would also be able to we should be able to look at that data now when we have released and talk about can we do this automatically in the few future so this kind of just helped those getting the mindset of what we needed to do so the what we kind of ended up is what we call scalability presets so on

the left side you can see all the various features high level features where we have scalability built into our engine now uh and on and there's multiple settings in these and they usually had multiple presets within themselves as well usually a low medium high in Ultra and on the right side you can see a high level version of this is how we could Define what is the the settings for each of these features that we're using for in this case Xbox series s so it's using in this case a mixer medium and high uh and like I mentioned there was multiple settings within each of these uh categories so for geometry we had for example we could skip LEDs per platform or scale our LOD render distances or for something like Shadows we control the resolution of our shadow Maps we use contact Shadows those kind of things and it was a mix some of these settings were Global for the entire game and in some cases we had it so we could do it per level

and how the engine used this to kind of get us to the frame rate where we needed to be was that we had our scalability presets so they are automatically applied on Console but on PC you choose them uh if we don't hit that frame rate then we still have a progressive resolution system kicking in and this will start scaling the resolution down to try to get to where the frame needs to be if we still don't hit frame rate at this time on GPU throw link kicks in and but the difference this time around is that throttling is actually tied to our scalability presets so when we set up the geometry the multipliers for how to scale back our geometry we have a high and a low value so for the high value is what's used when the game is not trying to scale it back further and the low value is how close we allow it to scale back at the maximum and the the idea around both the progressive resolution and the throttling system is that these are a buffer that are used when the game is throwing things at you

that can't really predict when you have you don't know how many enemies are going to shoot at you at any given point so this is kind of how we're trying to maintain perf even though those kind of situations happen because usually that's when you least you won't notice it as much but overall the scalability presets should take us to perf on a various platform on their own and I mentioned it takes time to get to this and there is no Special Sauce really we were using regular performance reviews with our various content teams and Engineers to kind of look through it while where we're at we did build a lot of Automation and data Gatherings into our process so we have daily or a play test or our night we have nightly run-throughs where we get data into Power bi where you can see Trends we have this is an example of a high level report where we can see kind of where we are on the GPU on the various parts of the island and this kind of helps us to identify if

there are regressions and if we need to go and look at specific areas so we then and then deep diving into those and having a conversation about what do we do instead of optimizing content or is this some scalability we need to apply because this is a problem all up and lastly I just want to show some examples from the from Hello infinite where we kind of what the differences are between the very specs these are taken on PC so there's would be a resolution difference if I would run on Console but otherwise it's the same and you definitely can see that we for running this on an Xbox one we have to scale back our LED distances and our Sky quality and those kind of things have to go but overall the overall look of the game is still consistent throughout and on something like on an interior you see much less of the geometry differences but more in a volumetrics and Lighting and then lastly this is of course also used on mp uh on our MP levels since

they're smaller we managed to keep it very more much more consistent look on the geometry side throughout the whole range it's more noticeable especially on a reflective map like this that the reflections The Squeeze face Reflections was something we had to turn off to get our frame rate on Xbox One and this kind of concludes what we wanted to talk about today and we want to say thanks to everyone at three for three and all our partners because we wouldn't be able to be here and talk about this without all their amazing work over the years and since while you're at GDC please check out our the other talks at 343 have here everything from Career Development to programming and engine design and please visit our website we have lots of positions opening come build the future of Halo with us and with that we'll open up for questions

[Applause] hello how's it going over there thanks for the talk um so you sliced up your rocks in Houdini so that you could do like sub part culling on them did you end up having to pay extra draw calls for each of those parts or did you have a system that kept the different chunks of the rock as one draw call um good question uh so our engine is actually does a really amazing job of instancing and GPU submission so uh it was more draw calls but it doesn't well it's not actually more draw calls it would have been if we didn't have instancing so um we did work uh closely with rendering about that plan before we put it into action and they were able to give us

some sort of guidelines on how many chunks might be appropriate and we were careful to test it um hope that answers your question yep thank you as someone who's so heavily involved in like tool development um were you privy to any of any of the decisions behind ultimately making uh this Halo an open world game as opposed to a more linear shooter that was not really something that was on our level so come speak for that sorry hi I was wondering if you could talk about uh performance scaling that you had to deal with with Drive access and network it did you have any type of scalability decisions that you made around those restrictions so most of the stuff that we had to deal

with was I wasn't really involving those areas so I unfortunately I can't speak much for it ours were more yeah the content side scaling um so sorry not able to answer that one uh hi um you mentioned briefly how you got uh how you generate the cliffs on on the levels by hand placing the the sections of rocks and then just simplifying it and simply gone um did you have a procedural process to place those Cliffs on edges around the map uh or was it everything handmade it's mostly handmade we have a few a few um a few things we do procedurally for that but yeah the cliffs are mostly handmade thank you hi there thank you for coming out to talk I was wondering what was probably the biggest challenge for making the procedural curation system and if you

were to reapproach that uh situation again how would you do it a second time Kirk you want me to um which which procedural system are you referring to specifically I guess as a whole the entire system as a whole yeah I think I think where I would go with that there's a number of things you could say but I think where I would go with is uh fine-tuning the balance between um the places where you need to really hand build stuff to get it to look exactly how you want versus the places where you want it to happen procedurally so that you can you know do it on a wide a wide swath of the game and um and preserving the ability to do both of those things um where it's appropriate to do one course versus the other so I think what's top of my mind about where we go next is just sort of revisit some of the assumptions we made about

which parts of the world had to be hand built in which parts it's possible to procedurally build um yeah yeah I would agree with that because a lot of it for especially this for this project this was a lot of new things for the teams as well and we like Kurt said it was a lot of assumptions in how much hand tuning we wanted to do that it kind of goes back to when we were talking about the rocks that was a the conscious decision that we rather hand unit because we were after a very specific look but I think now when we have a project that we can look back on we have a lot of learnings where we can revisit and see which of those things could we actually procedurally generate in the future and I think we have a lot of opportunities there uh that that we definitely should look at awesome thank you so much

hello great talk thank you I have a question about um tools you have eight by eight kilometers so in for example for the terrain tool do you have any issues with like memory or performance when you like have this kind of let's say an optimized way like edited it on the edit side you mean yeah uh so yes you can if you would try you can't like load the entire terrain to edit it at any given point so we we had to restrict it in the sense of how big of a space you edit in our editor at any given time so you it will tell you when you try to load too much uh too many of those terrain tiles uh so yeah definitely what that size you have to be able to split it up somewhere I know with there's potential Solutions uh with streaming techniques that we could look at for the future but what the solution we ended up with it kind of worked as well because most of the time we had multiple artists working at the same time and they could

work in smaller sections and if we wanted to do something really big where they had to affect the whole terrain that was usually that they were generating something in a separate DCC like how do you need to get the simulation going so it was less of a problem but yeah definitely on the bigger levels that that that happened to be a problem I was wondering if you could talk about any strategies you took on to limit popping or any type of loading artifacts as they were moving through the map uh let's see so so one thing we do is we have a lot of control over the the multipliers for the LOD transition distances um for different for different types of things so we try to um you know we don't apply scaling settings uniformly to trees as we do to rocks as we do to hard surface so so one answer to that question is we expose a lot of

tunability to exactly how we scale um yeah it's basically it's uh the teams themselves can just Define how granular they want to be able to set up the the multiple multipliers we have for the scaling on the various platforms other than that I would say a lot of it was just iterating a lot of iteration on trying to find something that works both perf and Visually and in some cases that means going back and reauthor the lods and seeing like what can we do to make this better uh so it was both giving the flexibility on the technical side but also a lot of iteration on the content side if that answers your question

hey um I had a quick question about um the dynamic system that you use to create grass and change terrain and everything did it eventually at runtime just break down into something static or were you able to use that during gameplay for like things like destruction or someone through a grenade and killed the grass or uh we don't have a dynamic system like that currently uh the the the ground cover is generated on the fly but they are driven by mass that we don't change really it's something that we I would love to look into for the future but not something we do the only thing that's really affecting we have a win system and like grenades uh do a push through that to defects it but we're not destroying anything no thank you before everyone runs out we just wanted to say thank you very very much for all of the people who stuck it out for the the tech art Summit in person finally [Applause] um so yeah this has been Mary and Mary

so thank you thanks to everyone for being here um thank you to our Cas our av team we really appreciate all the hard work you've put in today um check out techartist.org if you are so inclined and thanks for coming everyone yeah [Applause] [Music]