[Music] thank you thanks all for coming my name is Valentine minitzke and I'm a lead by a fixed artist at playground games and today I'll tell you how parameters Drive the particle effects of Forza Horizon 5. but before we will start a please turn off the sound on your phones and also uh in the end do the evaluation piece all right so today we'll be looking at uh what challenges we faced in a new project and why we decided to switch to a new particle Editor to overcome them then we will uh talk about how we redesigned our core gameplay graphics and we'll show how putting car physics at the core of our facts help us to achieve more convincing and satisfying visual results
we also take a closer look at several several use cases such as how we use Wheels temperature to drive Tire smoke effects we will show our keycap Master effects and explain the external parameters that we use to control them then we will break down how these two effects we were able to cover hundreds of destructible crops and we will wrap up with several tips on efficient batching solutions that help us to optimize our game for various platforms so the goal of this talk is to show how we discovered that building Graphics systems to take an advantage of parameters would be a key to producing more satisfying gameplay effects and efficiently creating a wide range of assets so but before we dive into that let me tell you about the game itself uh Forza Horizon 5 is an open world driving video game set in authentic representation of
Mexico let's take a look at the trailer [Music] foreign [Applause] [Music] [Laughter] [Music] [Laughter] [Applause] [Music]
[Applause] [Music] train hold up coming out of me Lightning for electricity [Music] [Laughter] [Music] [Applause] [Music] [Applause] [Music] foreign [Music] let me describe what challenges we faced
in a new project and why we decided to switch to a new FX editor so what were our new project considerations we planned for a 50 longer development cycle and this was intended to give us more time to push the quality of our facts but that was also a bit of a scope increase as a goal was to create our largest and most diverse world to date replicating the huge variety of biomes present in Mexico the key Tech Improvement that we identified on the fix hard site was to push for a new particle editor that would enable us to live up to those project targets to better explain why we wanted to switch the new editor let's take a quick look at previous editor challenges so during Forza Horizon 4 production we felt that we had hit the limits of what our old editor could do and it felt that we were spending as much time fighting the two as we were creating the art itself it was a heavily extended middleware
that had not been an active development for years and we were highly dependent on the help of our internal Engineers for any fixes and new functionality but still it was a cumbersome stack based editor and its core and no amount of engineering support could change that in 2018 and early 19 we spent a lot of time checking various GDC talks and engines like Unreal Engine and unity to understand what kind of tool we were looking for everything was going node-based and overall trend in the industry was to give more control to artists through node graph editors as this approach is giving the ability to craft our own logic and data relationships in a way that suits our effects we had the choice to create an editor internally or use a third-party software again in this case popcorn FX version 2 was clearly the best option for us so we decided to go with it but this did mean that we would have to build a everywhere fix and a game from
scratch that would be no longer the momentum of previous projects behind us and we also would need to help support the implementation of this editor as part of a new editor evaluation process we started by designing a gameplay related fix so what was a problem that you tried to uh solve here well in Forza Horizon 4 we had a limited visual feedback to reflect what the car was doing there were many blind spots for example our particle system didn't know anything about which Wheels were actually driving the car and we had to offer most effects expecting real-wheel Drive any deviation from these required mod application and workarounds because of that in some cases we could achieve a behavior scene we couldn't achieve the behaviors in the reference and that would frustrate us a bit uh previously there were some situation we struggled with such as a initial kick up when the player suddenly Accelerate
from a static position to fix this we needed to introduce workarounds but in turn workarounds could cause incorrect Behavior which would then also trigger in other unwanted situations in this video we can clearly see an unintended emissions when the front wheels stopped rolling this boy was byproduct of previously mentioned workarounds and we unfortunately couldn't fix this so the first picture here describes how previously our effects work and we could only use Primitives for Mission points and from those we emitted particles flying backwards and up into their B to create a feeling of will kicking out dust and debris but now we have the power to create our own emitter Behavior the good place to start would be by defining a cylinder that matches the tire then we want to know where the contact point is and to use the surface of the tire thread around that point
and then we eject our particles with initial velocity set according to how fast the wheel is spinning this is a very first proof of concept for wheelbase emissions that we created during popcorn effects evaluation stage let's take a look at the effect graph on the right the script note here is defining a cylinder almost in the same way that we showed in a previous slide then we have a few inputs to control the arc and velocity of the base emission this then goes into the default physics node to add some gravity and billboard renderer this basic effect already feels quite satisfying you can imagine this is coming from a car wheel that is spinning away on a wheel very loose surface let's dive deeper and see what is under the hood in our cylinder defining script note so this is a basic script at the heart of this effect there is no reason that this couldn't be done in the node graph but it's far more visually transparent
to do this in a few lines of code we start by picking a random angle from a defined range for the Arc of emission and the same for the radius for a bit more Randomness there's a control over how much side to side spread we want we use this to pick a position on the defined cylinder that placed at the origin and then we calculate an initial velocity based on how that point on the tire relates to the contact point as at this point we were still working only in popcorn the fix editor so we recorded some gameplay from Forza Horizon 4. with our physics overlays enabled to try extract the data and apply it in our proof of concept effect pretending that the effect is listening to the game as you can see in this short clip the car is driving from a static position on a gravel road and this shows a bit of variance and how much traction there is due to the loose surface we took some
notes of what we see Happening Here with those values over time and it looked like RPM and sleep related data are the key so with those knots in mind we improved the previous test effect those previously fixed inputs are changed into attributes which allows everything to be controlled from the effect interface in the top right of the frame this control panel allows for live tweaking of elements of the effect but in theory these functions more appropriate for listening to external data as we don't have the physics data directly available for now we created some curves that map what we saw in the previous clip and Sample that over time to drive the effect here we have a side-by-side comparison that works as a proof of concept for inputting the physics data into the star emitter effect so after we proved the concept in popconfx editor it was time to start
implementing all this into the game and at this point we decided to look back and revisit a little bit our approach for creating effects for core gameplay systems as previously we were relying on options and data that are known to us instead of thinking about what are we actually trying to represent so that was really good question and to answer that we decided to start by talking to our resident vehicle handling and Dynamics Team as they're the people who know everything about the behavior of the car and what we are trying to represent in these gameplay effects it turns out that the key concept that relates to tars kicking up matter is a sleep ratio this is a difference between how much the wheel is rotating compared to how far it has moved linearly at zero sleep one revolution of the tire should Propel the car by the circumference of the tar and at one sleep there is no movement at all we kind of knew about sleep thanks
to the in-game physics overlays but didn't fully understand it and it turns out that this was the main contributing element to the Smoke Factor previously mentioned what this ultimately uh boils down to is that the rotational energy the tar spans that doesn't move the car forward must be doing something else this could be a pushing surface matter away from the car or lost in the heat energy in the friction between the tire and the surface sleep ratio is a key parameter that inform us of all of this happening so that information in mind we start by implementing some debug visuals to test that parameter hookups from the game to our effects are performing as expected we use Tire properties to place those debug particles on the surface of the tar and to do that we are reading the wheel position Tire radius and its width from the game we use RPM to rotate this as a wheel rotates
and at last we change the color depending on the slip value with those debug visuals up and running we now know that we can trust the data connection and it's time to start working on getting some keycaps in place here we show some early spawn layer logic we are able to map emission curves to the physics inputs and use a control panel of basic debris emitter to set tune the behavior of this effect as you can see when the we increase the Sleep ratio particles begin to emit it over a growing Arc from the contact point and with increasing velocity uh depending on the maximum that is determined by RPM and this is a breakdown of the core behavior of the entire amateur demonstrating how these inputs are reflected in Nigeria in real time our templates are able to be adjusted to create variants to tune on the fly so let's for a moment dive inside the diary emitter template again this is a evolution of the graph that we
showed from the popcorn of its evaluation stage the purple inputs are being read from the game but also are accessible in the control panel in editor for testing purposes from game read the wheel position Tire radius and width RPM slip ratio and use this to inform effect Behavior and the dark blue uh internal parameters that we were adjusting via control panel in previous slides this all comes together to allow us to create a comprehensive effect system that now consider all forces acting on the tire at once allowing that to influence the whole particle system in combination with the other factors at play if we know that the tire is traveling at given speed spinning at a specific rate and the amount of it is sleeping this can all be taking into account for the initial behavior of the spawn particle we only have to define the nature of the effect once and then uh drive it with a
data from the car physics now that we have the quarter emitter Behavior coming along nicely um let's put it to use with a tar smoke one of the most common effects you'll see in the game but first let's look back at what was wrong with our previous iteration of Tire smoke we previously discussed a smoke amount value this was a bit of a black box magic that tried to tell the particle system that the wheel was slipping and if it was hot this led to a fact that lacked much subtlety the smoke amount number needed very little change to go from minimum to maximum leading in most of the cases to Binary on off behavior and obviously our effect like a thick building smoke so to even better I'll try this let's compare our fact from Forza Horizon 4 against a reference well clearly our tire smoke look quite underwhelming if you think about the
burnouts and drifts you imagine a big thick clouds of smoke but ours were quite thin and weak so what can we do about all of this we decided that the good place to start would be by finding a more appropriate trigger to drive the effect itself so again we go to our friends in vehicle Dynamic team and tell them that we want to achieve what we see in the reference where Tara smoke starts all fairly thin and then thickens up a star gets hotter and hotter they gave us a quick lesson on what causes the tire smoke and pointed to some good reference let's take a closer look at the reference together so in this case the tire starts off cold at an ambient temperature of 90 degrees Celsius as we can see a lot of sleep causes a tire to quickly heat up and pass 100 degrees Celsius Mark leaving some rubber on the ground and producing a thin short-lived smoke often at this stage we are seeing a dirt
and other contaminants on the surface of the tire smoke before the tire compound itself now that there is a bit of a hot spot developing on the inside left of the thread unfortunately this reference is unable to capture the hit about 100 degrees Celsius Mark but a few seconds later you can see the heat has spread across the entire Tire thread at this point the smoke produces not a simply thicker and continuous and after sustaining that amount of friction for another 15 seconds on a similar RPM the tire is clearly starting off to break down a lot of lingering smoke is being produced and you can see particles of tire rubber being cast off it turns out that our car physics simulation already track all the necessary data in fact we were informed that it goes a step further and tracks how each entire compound responds to heat at what threshold it should be
start smoking and what will be reaching the kind of a Breaking Point a new smoke control parameter is produced to trigger this Effect called Smoke input the temperature of the tire is compared to these thresholds and map to zero to one range for easy effect control as soon as the tire is hot enough to be starting to produce smoke the very fixed system is informed by the parameter going above zero and increasing up to one for maximum smoke this new temperature-based control will have a bit more of a range than previous one had access to allowing for subtle build up in effect and will be helping us to address this prior binary nature from here we just need to apply it alongside our new tire emitter and see how it feels so we decided to go with two primary elements Thin and Thick Smoke there's a that's on around zero but once we pass that with a smoke input the thin smoke emission increases and thickens up
until we cross a threshold to Thick Smoke on this example you can see that the action of the tire influenced the overall movement of the smoke the highlighted parameters are the temperature that we talked about previously they determined the type of the smoke that is produced obviously the smoke material in this demo are great but alongside this we've been working on some significant rendering improvements that give us confidence in producing some thicker smoke materials but first let's go back to Forza Horizon 4 to talk a bit about the pre-existing issues our particle lighting model was not a fully featured as a rest of the game each billboard had a lighting value that was a average of its for vertices this led to a strange visual behaviors in areas of mixed light and Shadow the solution at the time was to reduce opacity and increase translucency leading to rather weak Tire smoke and trails that don't light appropriately
here you can see some Forza Horizon 4 tests on fine tuning translucency value which in effect lowers the amount of Shadow details available to our particles by adding the light from the other side of the billboard so here we have a comparison of our old particle lighting model on the top with the new one at the bottom we now have a per pixel light and Shadow a massive Improvement and as you can see the particles reading is more closely aligned with the rest of the game world on the right we also have a new six directional light map Shader which again give us more confidence in using thicker clouds as now we can bake it into the info for the light scattering through from behind to quickly recap how we improved our tire smoke so we've created a new bespoke smoke control that we plug directly into the effect in combination with the new tire emitter we can change
all kinds of behavior according to the temperature and movement of the tire Tire smoke Behavior now reacts more realistically according to what the wheel is doing and how hot the tire is giving us a satisfying cramp up over time and per pixel lighting and our new six directional smoke materials allow for billowing lingering smoke to look good and now we are happy to leave small particles lingering in the world for some time and that in turn our players to create long satisfying burnouts with all ingredients in place let's take a look at what we've created here you can see how results of our work compared to what we had previously notice how in a lot of the cases our new tire smoke ramps up from the thin to thick and Billy
well and being such a core part of the game it's great that to see that it was well received by the players and reviewers alike we were really happy about the amount of great photos that our players Community created in photo mode specifically showcasing new tire smoke one more thing before we move on having the ability to do what we like with data allowed us to create some cool new features by tracking the car volume we can determine if the smoke is inside the car and change its Behavior for example as you can see on this video we can fade out smoke over time to give the impression that you've dispersed it with your car we've made a good progress with the tire smoke but what about the keycaps we expect to see when we go off-road but first let's look back at what challenges awaited us when we started creating keycap effects
every Forza Horizon game is more demanding than the last when it comes to kick-up effects as our entire our team is always pushing boundaries and trying to make each location in our game as the ride as possible the way fixed team need to have an appropriate effect ready for every terrain material in the game to better illustrate this here's a quick selection of several biomes from the game but there are many more to account for there were at least 120 materials to keep track of across Four Seasons and this can be Blended together into all sorts of combinations that's a lot of ground to cover previously we would duplicate an existing effect and tweak it to suit each surface in the game and obviously this is a very cumbersome approach so this time around we decided that we can came up with a better solution considering previous success with receiving data from the game we ask our Graphics friendly rendering engineer to give us the ability to send parameters
of our choosing from the game to the effect based on the underlying surface when we receive this functionality we started by feeding in different flow three color to the same effect depending on what surface called for it here's an example of this in use on the cluster of Fairly similar but distinct surface we use a single effect that is selecting between some nice bright debug colors depending on what the term is actually touching and powered by the ability to feed the color into the effect we start to group up similar surface types to see what we could put this to use here is a list of uh send keycaps effect that we ended up with in Forza Horizon 4. we have three base colors of sand each with a compact and deeper version some of those were also kicking up Stones Some that were red Etc based on that experience
we realized that if we can use parameters for more than just palette swapping we can really streamline the process of keycaps creation for example here we have a three Sun types from the west coast and it's adjoining sand desert some sand here have a lot of stones mixed to it the other one is very deep so we don't want keycaps effect for those to be identical but we also would like to avoid having to make a maintain entirely new effect every time so how could we do this what if we also thought about the amount of sand that should be kicked out that relates to the depth of the matter that is being pushed around or that the tire sinks into the surface the core behavior is much the same just a different density from thin layers of compacted sound through to the soft deep deformable sand dunes so we thought maybe okay cups effects with a sand Trail component could be a single Master
effect which he fed for suddenly transforms depending on the depth of the terrain let's go back to our previous example our flow 3 is now float4 the extra Channel being depth and as you can see we use this to drive the size of the particle but why stop there there's no reason that this attribute cannot drive multiple aspects of the effect like for example emitted sand opacity levels so let's put this into practice and Define the RGB and depth for each GitHub in the same for this is how our different keycaps looks in XML as an example we use Sandeep and some deformable this is our plot 4 that defines a color we are RGB and the last parameter defines the depth this depth in effect will be used in a similar way to the temperature input for the tire smoke we use depth to decide if the surface should use a thin or thick
Cloud materials we've simplified the logic inside our effect for this example a bit but we listened to the dust RGB attribute and split that into RGB and fourth Channel depth this depth value is used to learn between Min and Max values contained in four twos two to the left this allows many aspects of the effect to be driven by this one input the rest of the effect is controlled using previously demonstrated panel of inputs on the entire meter system so we decided to take it even step further by adding another flood 4 to control a debris element with a range of properties we already have RGB so we don't necessarily need that to duplicate but we could use one channel to control the type of debris another for the spawn count of that debris the base size of debris and finally a control for which quality setting platforms this degree appears on now
with this setup we can not only output sound of different color size and opacity but also whereas debris types to it this example demonstrates how we go between those Min and max depth values and also how those additional debris types looks like remind you this actually is the same effect and we just fit different input data to it from the game and it outputs us very different visual results in going through this process we made some discoveries that surprised us we found that using fever but more complex and adaptable effects was significantly cheaper for our CPU task usage than numerous simpler effects in these situations popcorn effect scales very well as you add more particles to an existing system this is what's very important when we run into some CPU bottlenecks at times the more coverage we could get from this master effects the better of our performance
this allowed us to propagate optimization easily to all keycaps across seven platforms creating scalable effects that work on base Xbox one through Xbox series X and top NPCs this was vital in the game where it's common for 12 cars to be traversing the world at anywhere up to 300 miles per hour Crossing numerous surfaces per second so at that point we were quite happy with the facts that we produced um those effects played a big role in our game promo materials and our players Community just love them and created so many great photos showcasing our kick up effects the next good use case would be a smashable effects so what were our production goals for the so-called smashable effects first and foremost our facts should look and react naturally to the forces at play When the car smashes a destructible asset
um also our world is densely populated with those smashable props early production estimates put the amount over 500 unique assets and each required appropriate effect so how do we build one of these based on our previous experience we started by identifying key parameters for us to listen to those who are the impact energy and focus car velocity the impact energy is used to determine the spawn count the harder the impact the more particles that will fly up into the air from there we are the basic behaviors that calculate the initial velocity of any debris we consider how much we want the impact energy to scale the overall movement of the emitted particles and we take into the account the velocity of the car that has just broken the destructible asset to trigger this effect we also added some external controls to all of this template to be used and
reused externally we control our the overall velocity spread Direction Min and Max taking this initial velocity stuff we then also Define the physical properties of the smash debris size and density are used to calculate the mass per particle then we use a consistent accurate gravity and wind settings across all effects for natural and cohesive Behavior this video demonstrates how the previous system come together in editor using the control panel on the left we can test how our effects looks with a low impact energy and high impact energy we can also preview our effects simulating various car velocities and different impact directions so after creating this template and solving basic behaviors of debris it was time to for us to again think about how we would create all the effects that are needed
inspired by the GitHub system we implemented a similar XML based solution to drive smashable effects variation from within the master effect we extended it far from this couple of additional float Force to allow for actual selection using the Uber material and to create a new effect we just need to add several new lines in our XML file and assign it to the prop to handle so much variety we Define an indexed list of presets for each type of debris in this case rocks by doing this we are allowing to select a specific size color and other parameters from predefined list by single float in the XML this is how our smashable Master effects looks from upper layer it's kind of a little bit complicated but this is how we get all this to work in a single effect file when the car smashes one of the prop it sets a specific plot 4 from the XML to
our effect using those we select color and the size of the Ruby from predefined index leads shown in a previous slide we also determine how many particles and of which type we should spawn we select between slate big rocks dust Sparks wood splinters plastic parts Etc after that all the information come together inside the effect layer where we also use car physics data to determine velocity Direction and other properties of the spawn debris and this is how our system behaves in game with some careful consideration and categorization we were able to cover this 500 plus smashable props with just two Master effects and XML file this approach again led us to massive performance Savings in situation like in this video when the player is constantly breaking a wide variety of props let's quickly look up what we ended up
with so with our new approach almost all our smashable effects are now being batched together essentially we have the same two effects being called over and over again in a new position with a appropriate attribute this resulted in massively reduced draw calls when players perform extreme Landscaping cracking Havoc upon everything in their path this allowed a single amateur to be used to Output numerous distinct debris types smoke and dust and also meshes this greatly reduced CPU task time as it requires less duplication as we've previously mentioned popcorn effects prefers fever but more complex effects if we did this with individual layers we'd have to pay extra CPU time for each one now we are going to dive a little deeper into this notion of payloading and making the most of a single simulation layer looking at how we use that to
create waterfalls and much much more so we do this using what we call Patch templates this apply many of the principles that we've already covered today but within a single particle system to better explain how we do this let's take a look to get that simple example all the physics simulation happens in a single layer but instead of defining input data inside this layer we use intermediary layer where we load data like position orientation color and Lifetime and send it to our physics simulation layer and as a resulting in fact we have this stream of balloons we convert our payload layer into template the batch template and reuse it several times over but every version of this payload is now sending different data to the batch layer um sorry
okay so uh uh there are all the data is extracted to achieve different visual outcomes and now we have three visually uh different streams of balloons but the physics simulation for all of them is happening in the same layer all the waterfall streams splashes and Mist in this C note at least using this method all the verifics you see here are just a single particle system with two simulation layers and a whole bunch of payloaded data this massively reduce the CPU test duplication that would happen if we would be doing this individually here we can see a list of a payloaded data that are attached to each spawn event that goes into the simulation layer for the C note water streams we see data like position size of emission Zone orientation particle size and so on inside the layer the data is extracted and put to using the common Logic for
each stream of water in the same way that we showed in the beginning with the waterfall balloons example and this is an editor example you can see payloads being used to drive one stream then we activate numerous other streams that we find that the final waterfall consists from we also use the same payloading approach for the splashes layer and the mist and we have the combined effect in the editor and back to the game for comparison as mentioned previously this is a very CPU friendly approach and therefore this technique is used widely across the game for example the Cloudscape steam vanson volcano plumes in our game initial Drive are created using this workflow and our version of the dust storm is also using a lot of the same principles
okay let's sum up what we show today so start off by identifying a couple of key parameters for your effect design the system around this as inputs effects created that way can adapt to gameplay by reading necessary data later on you can easily overhaul your effects or create variety by defining variants through an XML or in some other way this approach could still be valuable even without external inputs as you can easily Define or embed all needed data in the effect itself I also would highly recommend a talk from GDC 2021 that touches on a lot of same topics that we discussed today it's called how to build complex system with a simple controls so templates are good designing useful templates when you start working on the big effects group can pay off tenfold later on in the project in many ways
with templates making consistent behaviors become easier you only need to make a tweak once to have it inherited by the family of the effects in age cases workarounds or exceptions can be done by creating a local copy of templates you just need to identify what you don't want to propagate changes to all dependencies the approach we took proof very efficient in terms of development time cost as we had to create all effects for our game from almost from scratch with keycaps what used to be 100 distinct complex files is not fewer than 10fx and XML document and with smashables over 500 distinct props are covered by two Master effects and XML all of this also gave us huge performance benefits that allowed to successfully scale our effects for various platforms okay and well that's all from me for
today but before we wrap up I would like to say thank you to the team behind the Forza Horizon 5. so uh first thanks to our great refix team kalisier John reads and Michelle Tolentino big thanks to George Eleni and Paul Benson from rendering team and Marco content Chris Phillips from vehicle handling and I also would like to say thank you to our art directors donor set and Conor cross for pushing our effects to be at their best and everybody else had playground games and of course thank you all for listening and any questions [Applause] hi thanks for your talk um I was curious it sounds like you're basically doing effects emission based upon the material name but materials can
vary across say you know the material itself are you like reading the textures like oh there's a puddle here but there's not a puddle here because you're like dynamically deciding that in the Shader or something uh so in our in our terrain texturing system we had a lot of those materials and we had also so-called uh surface types that kind of had the visual material side in it but also that was uh obviously uh parameters from game design in terms of how the car behaves on that material if it's sand or like a tarmacrode and stuff like that and also audio and we also used those to uh Define what kind of uh emission we would like to do in our Master effects got it thanks thank you once again I appreciate uh listening to your talk today um I wanted to know
um in comparison to Forza Horizon 4 how much more resource intensive did these effects end up being um sorry can you define the resource um so I I apologize um that's your CPU time CPU okay so um we had a 2.5 milliseconds of CPU budget across any kind of platform so it's the same on Xbox Xbox One and Xbox series X obviously 2.5 milliseconds on Xbox series X is quite different from Xbox one but we were constantly saying staying in that budget and in some cases we also had to even cut lower than that where our environment were like really complex with some additional props on Xbox one so yeah basically I'll we never were higher than 2.5 milliseconds
overall thank you I think awesome um two questions uh are you guys on the same engine as the force of Motorsports guys just out of curiosity and two um you guys HDR skies and rendering is probably one of the best that I've seen out there it's really beautifully done you know on what what on the particle side did you guys have to adjust at all for for a the sort of HDR rendering so yeah that's correct we are sharing the uh fuel engine with a turn 10 and Forza Motorsport title and on the yeah Sky setup so um yeah basically our Sky rig as you probably saw in some GGC talks back from the years is we just captured the sky in a various different scenarios and use that with a yeah motion vectors to kind of make it
look most realistic that we can do and on the fixed side in some cases in some scenarios where the player was on the top of the mountain we added some additional kind of low-lying clouds uh overall to to mimic some clouds that we saw on the sky itself obviously it's pretty hard to do because like you have this perfect picture of realistic sky and you're trying to mimic that with particles so there wasn't any space for uh doing some something kind of a little bit stylized we had to yeah make it as much realistic as we can cool thank you hello um thanks for the talk was super interesting and I was wondering if you had some overdraw issues because I noticed that when you have objects which
move very fast like your cars you have to spawn a lot of particles to avoid gaps in between them right and so I was just wondering if the player positions I don't know the camera behind the car and you go through his end I imagine like the PC or the Xbox just melting because of the overdrive I wonder how it you overcame this this issue so um with a lot of those kind of bigger particle effects like the long Trails of kick-ups or Tire smoke we actually use a quarter rest rendering of those particles that kind of significantly improved the uh GPU side of that um yeah and it all kind of worked and obviously for the lower platforms we scaled down the emission accounts of the particle system Etc but we were kind of lowering the uh lifetime of the particles as well so
there won't be like uh dead zones between the particles that we emitted the only thing that they would live uh shorter life on the Xbox One compared to Xbox series X okay thank you and um I was wondering whenever I try to make such a dynamic system with these parameters I often run into edge cases just for example you you mentioned that you can scale up and down the particle size depending on the speed right and it looks okay in 80 percent of the cases but if the car is very uh slow for example then you have mini particles which you look a bit weird right and sometimes I run into these things and then I try I make add workarounds for these ad cages and at some point I have a system which is so complex that it's hard to extend because it's basically full of workarounds and I wonder how you covered these Educators and made it just look good every time by not sacrificing
the complexity of the system so with example that you've just described the good idea would be probably not to start with the size of the zero you start with some predefined size and then there is a maximum as well and you basically kind of lurping between those values depending on the parameters that you receive from game so that was kind of basically our solution obviously this all kind of required a lot of tweaking so that's why in popcorn FX we had that panel with the various attributes where we predefined some mean and Max values so the effect itself won't be breaking down and we won't have that you know small really small particles up or something else like that okay thank you cool um I guess that's it in that case um cheers again thanks all for coming and
don't forget to feel the uh evaluation [Applause] [Music]
Auto-generated captions from YouTube — names and numbers may be misheard.
Distilling the key insights…
Game Developers Conference · 2026
Comments