Uncategorized

>> Alright, let’s kick this off, then. Good morning Welcome to our tech talk This session is Causing Chaos: The Future of Physics and Destruction in Unreal 4 I’m Jack Oakman, Senior Technical Artist at Epic Games, Special Projects, and I’m here with my colleagues Benn Gallagher, Senior Physics Programmer, and Kelly D. Gawne, Game Performance Engineer at Intel Our aim today is to introduce you to Chaos, Epic’s new and improved physics system To that end, we are going to be looking at our recent destruction demo of the same name We’re going to give a high-level overview of the kind of tools we used and of the system Unreal users can expect to see in the coming months We will explore the workflows we typically used and we will introduce you to a few foundational concepts along the way, so hopefully this should give you a decent grounding as you prepare for Chaos’s imminent arrival Many of you will have seen our announcement of Chaos in our State of Unreal Keynote at GDC In case you didn’t, let’s first establish what Chaos is and where we currently are with it Chaos, if you’ve already gathered, is Unreal 4’s new upcoming physics system It is still in active development, so what you will see here is representative of our alpha version, really We’ll be shipping the first preview version with Unreal 4.23 so stay tuned for that Chaos lends itself really well towards destruction so we decided to focus our demo around that aspect of the system We recently introduced it with a live gameplay demo at our GDC Keynote Again, not all of you might have seen that, so first of all, let’s have a look at the highlights reel [Demo video plays with no sound] Cool Let’s do it quietly, though [Laughter] [Demo video plays with no sound] Just imagine the explosions K-POW [Demo video plays with no sound] She said something really funny there [Demo video plays with no sound] There it is! Quietly, but pretty [Applause and laughter] Ok, so of course the first point of order was to define what our aims were in creating the demo Of course primarily we wanted to preview the kind of spectacle that Chaos would enable the whole Unreal community to achieve in their own projects The creative context we chose to achieve that was really a pretty simple one We like to create an homage to sort of an arcade-style classic light gun game type of thing, which is a pretty good excuse to smash up an entire city with Chaos destruction as its primary tool From fracturing Meshes to destruction simulation, everything we showed you there was created in Unreal There is no longer the need to create complex fracture hierarchies outside of it and no reason to import predefined simulations either All of that is possible in the Editor itself now Another thing of note is that everything you saw today was rendered in real time on a regular, albeit high end, gaming PC that you could buy in stores right now On the simulation side, we’ve introduced a level of flexibility that we’re all pretty excited about Everything we’ve shown you today was simulating in real time as well when we wanted it to be To explore what I mean by that, we should probably have a generalized look at the three sequences we just saw there In the first sequence, where we’re chasing Chaos through the streets, everything is simulating at runtime Here have obviously a very controlled game flow through the space We need to work at a pretty high level of fidelity, so this is close-up work That said, the player’s response will always be somewhat random, right? We can guide their actions but that doesn’t necessarily mean that they’re predictable They’ll shoot wherever, whenever they want, and that means that all of the destructible Assets in the scene have to be ready to simulate at the press of a button In the second sequence, the same general rules apply, but structurally we’ve moved away

from the more close-up interactions of stand-alone pillars and street furniture and we’ve panned back to introduce full facades Because we spend a little time at these buildings, we also need to account for depth because it’s entirely feasible for a player to shoot the same spot over and over again and burrow deep into the interior of the structure Since we have distance we can now balance our fidelity of the assets to suit that and we control the breakup of the assets to balance performance Then lastly we arrive at a cinematic cutscene whereupon we see an entire city block collapsing Here we have presimulated destruction and we’ve done that in the Editor and we’re playing that result back from a cache You might wonder, then, if that sequence would therefore have a very different authoring approach, but at its heart its very much the same as the scenes that went before it’s just how we choose to interact with the result that changes The prime benefits of prebaking sims in this way are as follows Of course we can art-direct the demolition We can control the pacing, play extra effects when we want to Things happen exactly as we intend, which of course is very crucial when we’re following a narrative structure In fact this whole scene was hooked up to Sequencer in order to line up the effects What this means is we can create huge destruction set pieces which wouldn’t otherwise run at perf We’re flattening an entire city block, after all, so that’s a huge number of assets But under the hood there isn’t really any difference Any of the scenes beforehand could equally have had a predefined series of events, caused their destruction We could have recorded those We could have tweaked them, if we wanted to, rerecorded, and played them back The reason we have that flexibility is because every building was created using exactly the same tools and same Asset type This Asset type is called a GeometryCollection Destruction using a GeometryCollection is the same regardless, whether we prebake or not What’s really cool about Chaos is that any geometry in a pre-baked simulation can become active at any time You might prebake a simulation because you want to art-direct the initial spectacle or to balance performance, but prebaked destruction and Chaos is never static Outside stimuli like player weapons can affect the simulation so Chaos can take the dynamic World State into account Because only the parts of the simulation that you’re affecting become dynamic, things are still super performant, which is very handy, of course If we want to put the player in beneath that beautifully art-directed demolition event, and then create gameplay where the player has to destroy incoming debris before it lands on them—something like that, that’s entirely possible We have the freedom to keep the player as an active participant all the time, if that is what we want to do I think the result that you’ll come up with that property alone will be pretty astonishing, actually Chaos can do all that because it’s a system It’s a First Class Citizen of Unreal Engine It lives alongside all of the other run time systems already simulating your Game World Chaos can be triggered It can be queried It can send events This creates some incredibly tight integration between all the systems, like for example Niagara, where break Events can trigger dust and debris and velocities can power dust trails Chaos allows you to create run time systems and behaviors that know how to interact with demolition It can modify NavMesh, for example AI can react to debris, so flinches, damage events, that kind of thing It can also detect debris, and use it to their advantage, like take cover Designers can detect destruction Events and create logic around those Events The potential ways to leverage this are countless Of course we will be providing some content examples around this and other subjects in the near future Lastly, let’s address networking It is important to note that this particular demo did not actually have a networking requirement, but I should clarify the point that since Chaos is Epic’s physics system of the future, it was certainly built with networking in mind, so networking will be supported Right, so the art side of things Of course we can’t have destruction without first having something to destroy, so let’s walk through that process and we’ll explore the tools we currently have at our disposal Once we decided upon the context of the demo, it was possible to plan the environments and the assets required to produce it But there’s a bit of dichotomy at work here, right?

Destruction is by its very nature chaotic We want to take random geometry, fracture it in random ways, and we want to allow a random user to hit it with random forces in random locations But we want to know that any of those results will feed into a desired predictable result In effect, we are herding cats To be successful in doing that, we’re really looking for one thing: control We need the appearance of chaos, but we need to organize its parameters so that it behaves predictably, runs in real time, and meets the needs of design, environment, and engineering teams alike For us, everything in this system revolves around that control That starts here With a drink of water I mentioned them earlier Let’s have a look at Geometry Collections Geometry Collections are built specifically for destruction in Unreal Benn will actually expand a bit further on this subject in a bit, but from an artist’s perspective, this is the bottom line Geometry Collections can be created from one or more Static Meshes, including those gathered within Blueprints or even from Blueprints within Blueprints Geometry Collections let the artist choose what to simulate They also offer incredible flexibility in terms of how you organize and author your destruction In this first example here, you can see we’ve chosen three Geometry Collections to represent a pillar We’ve separated the internal from the external faces, and this allows us to sort of do a bit of chopping and changing until we hit the appropriate fidelity and behavior that we like In a second example, we see a more modular approach We have got Assets that are repeated and gathered together to form the full building It’s worth noting that though many of these Assets are repeated, we have the flexibility to control their behavior independently of each other Then in the third example, intended more for a cached playback, we have broken the entire structure into twelve Geometry Collections This helps us to consolidate draw calls and it gives us a manageable number of caches to manipulate later on Once we have our Geometry Collection, we want to break it into pieces of course You can see the coloration on this example, the various Static Meshes that were picked up to create this particular object While we’re here, it’s probably a good idea to underline a few recommendations we have for the structures, particularly of this type Firstly, we want geometry to be water tight, right? Solid, contiguous Meshes with no holes If you could 3D print it, it’s likely going to be a pretty good fit here You want to avoid intersection where possible, but in fact Chaos can cope with intersections but for the sake of predictability and consistency, we’d recommend you avoid that as much as possible It’s also best to keep things on the cheap side A lot of this will be quite familiar to anyone who has done any destruction before You don’t want to be chamfering all of your edges You want to try and keep higher detailed areas sort of isolated to separate Meshes because you’ll be able to control their breakup out with the larger, simpler bulk of the structure The moment you slice one face you have basically doubled the topology count of that face This means destruction can get exponentially expensive over a range of Assets, so try to keep the bulk areas of Meshes simple and concentrate fractures there Modularity, as with many environmental features, is a good idea Here we have combined a selection of modular Meshes so we can hit them with fractures as a whole But we could easily target smaller modules if we wanted to with a different fidelity, if that’s what we want Modularity does keep things very flexible I’d absolutely recommend standardizing widths and heights, that sort of thing And organizing pivots to obey Unreal’s grid system You’ll save yourself a lot of time if you do that out of the gate Lastly, materials This one is important A window frame is metal A wall is brick or concrete or marble Even if they’re sharing the same textures, you are going to need to make sure you account for all the material types and apply those appropriately When we create a Geometry Collection, any shared materials will always be consolidated into one ID, and a second slot is then slotted underneath that into which we can put our fracture materials When we slice through a piece of metal, we can put metal in there In a wall, concrete or whatever Also, another note, we also support preskinned vertex position as well, so there’s room to experiment with your shaders there too So all that out the way, the moment we have our Geometry Collection, we can fracture it We can fracture each part individually

or we can apply a pattern across multiple pieces, and we can do that as many times as we like At the moment we have Standard Voronoi fracture, but we have also developed a suite of options that allow our artists to dial in a specific look You can see here we’ve got Radial fracturing, Clustered Voronoi fracturing, and Planar cutting using more noise to get a natural result. Or a combination of all of them In a budget-conscious environment, sub-fracturing allows the artist to decide where to add complexity Each time you sub-fracture, an extra level is inserted into the Geometry Collection, and the Chaos system keeps track of each subsequent level and stores that information into something an artist can control—a cluster Here is an example of a Mesh where each fracture level is combined into its own set of clusters These are a bit different from other systems in that the Chaos solver treats each cluster node as a single object until enough strain is applied to cause a break into smaller nodes When we’re simulating Level 1 here, the system is only calculating those pieces Conversely, if we turn off clustering altogether, every single leaf node falls. Not super-efficient, of course, doesn’t look great By tweaking cluster strength values we can therefore get a varied result that performs as optimally as possible Since the solver treats each cluster as a single object, this also opens up a kind of a destructible lodding approach, so an object like this made of 300 nodes can easily be clustered to half that number, and if we want to keep distant instances to even less than that, we might gate that to, say, eight, or even three if we want, depending on the distance That decision is very much a fluid and changeable one At any point we can simplify our cluster hierarchy and use procedural auto-clustering tool to gather the leaf nodes into the values that we want This basically allows us to spam an entire building with fractures and we can sort that out after the fact Because you have as many levels as you want, you can explicitly control the density of each successive level Controlling how difficult it is to break those levels up and to lock them at any point per instance means it’s easy to balance performance and visual aesthetic Another concept to introduce is the Connection Graph This is a lightweight connectivity map that’s a bit of a different paradigm for destruction simulation Here we have a few statically anchored pieces at the edges there, but everything else in the scene is potentially dynamic Rather than swapping from kinematic to dynamic State like many other systems, our system applies strain, which in turn breaks connections and allows nodes to know when they’re no longer sufficiently supported This is a really good way to maximize interactivity while retaining control over the amount of active rigid bodies in the scene We have everything set up and we can see sort of how that works How do we interact with it? The answer to that is Fields Fields are the way that artists and designers alike can directly interact with control simulations Fields can be used to control pretty much any attribute or any part of your Geometry Collection If you want to vary your mass, make something static, make the corner of a building more breakable than the middle, you just want to apply some Force, even Introduce another Field and you can apply that change These are the foundations of how we interact with Geometry Collections It’s because we have that that we can author Sequences of destruction that we can then record and play back When we’ve done that, we can introduce more Fields at run time Weapons fire, for example, and pull the targeted, rigid bodies off of their preauthored track and into a dynamic State Now we’ve only begun to scratch the surface here I’m very excited to see how the community responds as well as an awesome amount of stuff that I know that’s going to come out and emerge as a result of this system With that, I’m going to hand over to Benn Gallagher, and he’s going to walk you through the system further, and also expand on some of the areas I’ve introduced here Thank you very much for your time [Applause] >> I’m Benn Gallagher I’m a Senior Physics Programmer at Epic Games I’m one of the engineers working directly on the Chaos physics engine As part of the talk, I’ll briefly explore some of the technical aspects of the systems we built to produce the Chaos demo, so let’s get started When we decided to forge our own physics solution

and then to build a destruction system on top of that, we wanted to make sure we created a system that empowers our content creators in new ways and was scalable from small scale simulation to huge cinematic scenes Running on limited hardware devices like phones, up to super powerful enthusiast PCs and beyond I’m going to work through a number of solutions we developed to reach these goals Non-convex collisions are often modelled as a combination of smaller convex parts But this can become prohibitively expensive It would be necessary to support non-convex collisions to reach the level of complexity we’re looking for when fracturing objects We needed true non-convex collisions that were heavily optimized Here we see an example of some trail object interacting with a port These are each single, concave objects They don’t rely on any convex decomposition and it just works as you expect As soon as you have the geometry, you can simulate it with non-convex collisions Fields were mentioned earlier in the talk, so we’ll go over them a little bit more from the technical standpoint This is how we interact with the simulations Fields are a very generalized interaction system for Chaos They’re a region of space that can have some programmable effect on various parameters of the objects inside them In the demo we used Strain Fields with linear and angular Force Fields for the explosions from the weapons to break up buildings and fling pieces around, among some other applications that I’ll cover soon These Fields can also be triggered from Game Events, from Blueprints Fields can affect just about any parameter as Jack mentioned before You can change sleep thresholds, velocities, constraint parameters, mass If it’s a parameter on the physics object, you can change it They can also be combined in more interesting ways to form unions comprised of many Field types, such as Falloff Fields combined with Noise Fields so you don’t get such a regular structure inside the Field We’ll take a look at a few of the Fields we used in the demo project First of all, Anchors Earlier the Connection Graph was shown with a few anchored nodes and we built these Anchors through Fields Anchor Fields force any eligible particle within the Field to become an Anchor for the other particles around it as a supporting piece of the object that it’s part of The normal place where the destructive object connects to the rest of the World as a World Support In the example here, we use Anchor Fields to lock the top and bottom of the pillars and the walls to control how they collapse and where they are supported from Anchors are often the foundation upon which structures are built They have another benefit in leaving some interesting footprints when a structure has been brought down where something is very strong and supports the rest of the structure Having a spacial tool to build these Anchors can be a lot more intuitive than setting a World Support check box somewhere on an object, as you can see the structure of the whole scene and where you’ve put your World Support Strain Fields, as mentioned previously, will apply internal forces to the edges on that Connection Graph you saw earlier within the Geometry Collection Enough strain and you can break the connection between the pieces and they will fall One of the interesting features of the Strain system is that the Strain requires the breakage cluster to be tuned individually by the artist, by the content creator This allows you to specifically configure the simulation for either aesthetic quality, gameplay interactivity, or performance as required Pillar materials till tend to crumble really easily into smaller and smaller pieces, where sturdy materials will require more Strain to break off If the scene is getting too busy, you notice a performance degradation, the Strain limits can be raised to release less material into the scene and take the pressure off the simulation In this example, we have a Strain Field which is being animated upwards and applying a Strain to the Geometry Collection as it expands The box underneath is a Culling Field, which means that we just end up with a hemispherical region rising up through the object Since this is all Blueprint driven we can just expose all of these parameters of the interaction until we reach the desired result Sleep Fields put particles to sleep based on the threshold of our choosing based on the velocities or energy of the object itself A sleeping particle is one that no longer participates in integration but it still works with collision If they get hit by another object they can wake up and start interacting with the scene again Disable Fields are a little more severe They completely remove objects from the simulation, they do not integrate, and they no longer collide They can be reactivated by Fields, however, because Fields can affect parameters and whether an object is disabled is a parameter on the object But not other objects in the simulation Anything hitting a disabled particle will go straight through it You have to be a little bit careful with Disable Fields and use them judiciously Again, because we’re assembling an area of space, we define how aggressive the process is At any single point, we can have different values and different shapes of Fields across the level Expanding a little bit on Sleep and Disable Fields, as we mentioned, the sleeping objects wake up if they get hit by an object or a Field Disable is just a Field Aesthetically, this can keep your pieces from rolling around away from your scene and being distracting Obviously if you have got a cutscene coming off

just to the side you can make sure that you don’t end up with stray debris rolling around in your cutscene Primarily, it allows us to actually control the performance of a scene in a much more directed manner to make good looking scenes that perform well You can keep the guys working on the physics engine happy by making sure that you have less objects simulating so their performance metrics stay in the green You see here in this example, we are now able to completely destroy this area without any noticeable drop in performance because of well directed use of Sleep and Disable Fields Let’s take an example of how to actually build some of these Fields Fields are built using a number of Field nodes combined together to form a final Field union which can then be applied using the Applied Physics Field node Here we’ve got a Field system created as a combination of multiple simpler Fields We have a Radial Falloff Field that creates sort of a linear falloff in the desired radius and then we use that Field to cull around a Vector Field This is finally applied to the angular torque perimeter The effect of the Field is that in a limited radius around the Field origin, around the angular torque, will be applied to particles within this Field Fields aren’t simply just a volume, they can evaluate scale, as like the radial falloff or vectors like the Random Vector Field When combined, the Falloff Field scales the random vectors easier, as you might expect Let’s take a look at a bit of a more complex example This example here has a little more going on It’s closer to an effect that you might actually use in a game for an explosive weapon hitting a Geometry Collection We’re sequentially affecting two parameters here Strain, as described earlier, will cause the Geometry Collection to break apart Linear Force will apply an explosive Force to the new dynamic leaf nodes Radial falloff volumes control whether Strain and Force are applied We’re also using a Culling Field to ensure that we only evaluate the linear Force for the internal leaf nodes since they are the ones we are going to affect with the Field The Field system is a very powerful system and it will expand as we further develop Chaos and add new features and new simulation types Moving on a little bit from Fields, we wanted to make sure that Niagara integration was a first class citizen in the system as the VFX simulations can add a lot of depth and realism to your worlds For example, when a building breaks apart, it generates a large amount of dust and debris as the pieces interact To achieve this, we transferred data from the physics system to Niagara, especially when objects collide, when they break and when they enter a trailing State, which is when they have a velocity over a trailing threshold when they’re flying through the air This allows us to generate interesting looking secondary effects that you see here in this example Note that the events are not restricted to Niagara but a general event data store Other systems can access this This is how, as Jack described earlier, we can have AI reactions to these things, they can take cover behind them, affect dynamic navigation Blueprints can query this data, so it’s not just for effects As mentioned before we wanted to scale really well You can’t run a lot of these simulations on low-powered hardware We wanted to create large, cinematic-scale destruction in games without having it be completely scripted, and obviously just a recording playing back as if it was a Skeletal Mesh that you’d exported from a DCC tome To this end we built the system to record the results of simulation inside Unreal, and played the results back in later sessions These results are stored as a cache Asset inside Unreal and are essentially like a highly optimized transform track like we use in animations Once the simulation is playing we can also begin to reactivate kinematic elements of the playback That means that content creator can meticulously author a very specific destruction Event If they want their building falling down just in the right manner and they want six pieces over here and twelve pieces over here, they can set that Event up and then at run time the destruction looks really good and we get a very low performance cost for updating the transforms A player can then interact with the falling debris in any way they choose and the simulation dynamically takes over where it needs to, where the player has decided to interact Also, in order to simulate as many things as we wanted to, we kind of needed to rethink how we handle multi-threaded physics entirely in Unreal Until now, the Game Thread has been responsible for starting and completing physics simulations each frame You have a pre, during, and post physics Event throughout your tech inside Unreal For Chaos, we built an extensible framework that let us decide per application what our threading model actually looks like On top of that framework, we added a fully decoupled threading model that lets physics run completely independent from the game thread This means that if your physics flow is down, your gameplay, your input handling, doesn’t get sluggish Similarly, if the Game Thread gets busy, it doesn’t start to affect the frame time of the physics because it’s completely independent Beyond this, Chaos has been designed

to take full advantage of high core counts It’s a heavy parallelized simulation However, if the game needs to have increased control from a previous threading model or if someone wants to write their own threading model for a specific application they have, that’s all possible with the new framework around that model It gives the choice of how the physics engine runs to the developer rather than us dictating how the physics is going to update Geometry Collections Jack mentioned these earlier and essentially we built these on top of the underlying technology we put together, and as we began to build things that were more geared towards destruction To build this we needed a representation for the object that was as cheap as possible to evaluate and to render We created the Geometry Collection objects, as has been mentioned many times throughout the talk, which at a high level is a set of Static Meshes that can be rigidly transformed over time It will group triangles with a shared material inside a Collection with a single draw call for efficiency, so every interior material is one draw call, every exterior material can be one draw call depending on how you set up the Mesh It makes it substantially cheaper than either a set of Static Meshes or a fully-skinned Skeletal Mesh A set of Static Meshes would be many more draw calls and transform updates, and Skeletal Meshes are more complex when rendered because they support multi-influenced skinning, morph targets in clothing, and ingest a shader with more cost also in the component itself Once we had the representation we needed some tools to allow people to actually break these things up into sets of smaller chunks Behind me here, we’ve got an example of a Voronai fracture being set up on multiple chunks of a Geometry Collection, just in the edit there, so all this coloring comes up and you can select your individual chunks and perform whichever fracture algorithm you want on them Beyond just the normal Voronai fracture, we’ve got a bunch of different types, we have radial fracture, image based fracture, we have plane cutting with noise, which the pattens were shown in a previous slide As part of the tools we needed to have the ability of content creators to build Assets that scale really well and make it easy for them to build these Assets without making it too complex for them to achieve what they needed to do In addition to the more standard geometric LODs, you can do that by authoring them using different levels of destruction The first level can be broken in up into only a few pieces and each subsequent level is authored to contain many more objects The auto-cluster is very good for this because no one has to think about exactly how the clusters interact We can just say we’re targeting a number of clusters Here we have got some pillars We have larger sections of the pillars falling as the supports are removed, and they can further break down afterwards as repeated collision events increase the strain on the internal nodes It could be controlled per platform to easily scale the costs of assimilation by restricting the maximum destruction level Here is a bit of a fun example to end up here We had a large radius explosive weapon, a 120mm cannon in the demo Here we have attached that to the chain gun so it fires an awful lot faster Just to kind of show exactly how much destruction was in the scene that we created For this first alcove here, all of the pillars, benches, pillars, walls, and signs were completely destructible The pillars and walls were made from multiple collections with different materials so you had granite tiles on the exterior of the walls and the pillars, and sort of a concrete with rebar inside On the walk to the second alcove here we had more of the same We had pillars, walls, benches, they’re all destructible The pillars and walls had the multiple Geometry Collection set up with the granite tiles on the outside As you move into the second alcove, again, just about everything in the scene that isn’t on the floor is destructible, including the entire sky bridge, all of the windows inside it It gets a little bit crazy when you have got a weapon that powerful in this scene, but it does kind of show the scale of the destruction that we hit there There’s so much more to talk about and there will be even more to come as Chaos as a whole develops and we’re looking forward to the incredible scenes that the community start to create with the new system For now I’ll hand it off to Kelly from Intel to discuss how we make Chaos fast Thank you very much [Applause] >> Awesome. One of the things that we worked on with Epic is we care a lot about CPU performance in general at Intel, so this is a great opportunity for something that’s really going to work your CPU We’re really excited to help out Largely, we were working on some of our low level data solvers as well as the data structures and general thread parallelism because we really wanted to fill up the cores on this giant system Some things that we learned along the way—If you haven’t tried it

before C++ is naturally not very good at SIMD, or Single Instruction, Multiple Data programming, which is something that happens a lot when you’re doing, for instance, collision detection or intersection testing, so things that are very important for a physics system One of the things that is good for that, though, is something we call Intel ISPC, which makes it really easy to write nicely parallel code on any compiler and I’ll talk about that in a second Some other things to think about— one of those cases where you really need to let your data show you the right thing to do, you would think that using a TSet would be nice for having a good unique set to use for intersection testing, but we actually found in our testing that we were spending so much time on the hashing function that it wasn’t actually worth it We switched to using a TArray and a Sort and RemoveSwap in order to get rid of non-unique members for our intersection testing Also, ParallelFor, though it can be powerful for multi-threading in some ways is very easy to overuse and very easy to use it to hide bad cache behavior This is another case where you want to let your tools show you what’s going on and so we found that when you’re oversubscribing like that, you end up with much more thrash, you can have thousands of jobs, so batching is helpful in this case, especially if you have nice, friendly data access patterns What is ISPC? That is Intel Single Program Multiple Data Program Compiler I didn’t name it But basically, computers—CPUs in particular—have had vector instructions since the early 2000s But they’ve been a bit of a monster to program for Basically these vector instructions will allow you to do like eight floating point adds in a single instruction by loading them into a vector and then using a vector add instead of a single add, which is super powerful The problem is getting the compiler to do it correctly on whatever compiler version you’re on, and then the compiler updates, and you have to rewrite all of the code It makes it really hard to do in things like Unreal Engine, where you are cross-platform, cross-hardware and trying to make all of these things scale very naturally This is what the ISPC compiler is so good at Essentially what it does is it gives you implicit parallelism in a language that looks like a GPU shader language, but it’s running on the CPU, which allows you to parallelize really nicely Like a shader language, it’s going to assume SIMD by defaults and it’s going to act a lot like GPU shaders in the way that it executes There are a couple of caveats that I’ll talk about in a second, too One of the big benefits is that programmers can write the ISPC code once and compile the vectorized desctructions to any vectorized instruction set that’s been supported so—SSE4, AVX, AVX2—which makes it very easy to update with whatever hardware you are working on If you are compiling for multiple instruction sets, there is an auto-detect mechanism that can detect whatever your CPU supports and compile for that, too, which means you don’t have to update your intrinsics every time you get a new instruction set You can take advantage of it right away This was heavily used in the physics engine and will be available for all Unreal projects soon because this isn’t just something to use for physics This is something to use any time that you want to go really wide on the CPU We are working on integrating it into other parts of Unreal that we want to better parallelize as well The nice thing about ISPC, too, is that it’s super easy to integrate Essentially you include the module in your build.cs, you add the files to the project, that will generate a C++ header that you include in that file where you wrote the code, and the Unreal Build Tool will handle all of the rest We had a GDC talk about this You are welcome to check that out I believe it’s already up Also, we’ll continue to put out some more literature for you guys as this becomes more robust When to use ISPC? When you’re thinking about ISPC and where to use it in your code, you want to think about places that have dense compute-bound workloads Heavy math like physics intersection testing, and cloth or vertex transforms— anything where you are really putting your CPU to work and have a lot of work to do It works best when you don’t have data dependencies between operations so it’s not having to wait on a previous operation to finish It is especially useful when you combine it with ParallelFor and a batching scheme, because all of these things are going to help solve different optimization problems Remember I said that ISPC acts a lot like GPU shaders, and they do, but with some important differences Whereas on the GPU all the shaders

are going to run independently once you send them off, each SIMD lane and ISPC is going to perform in lockstep If one of those lanes isn’t going to take a branch, but the others are, it’s just going to stop and wait until the other lanes finish that branch and then it will pick back up afterwards, which is actually faster than it sounds when you’re on a CPU instead of a GPU Another neat thing about this convergence is that it gives the ability to do reductions across SIMD lanes For example, if you are trying to find the sum of an Array of integers or the min or the max, it’s super fast, and that was something we used a lot to make Chaos faster What you see on the bottom there is our actual ISPC code on the left—the not scary-looking one Essentially all you have to do is add those uniforms There are two key words, uniform and varying, which again, I invite you to look at the white papers and literature about how to use those properly You just add those key words to indicate how you would like it to compile into the proper vectorized instructions and it will turn into that code you see on the right Super easy to use and hopefully you guys find it useful for what you’re working on as well That is ISPC We were really excited to work with the Chaos team and get this demo out there and so excited to see what you guys are going to do with all of this Thank you, everybody Would you like to close this out? [Applause] >> Beautifully done. Lovely >> Thank you very much for coming to the session We are really looking forward to what this technology can do when it’s in more hands than ours Our artists sort of blew us away so we’ll see what everyone else can do We’re looking forward to the kind of things you guys can create Thank you very much [Applause]

You Want To Have Your Favorite Car?

We have a big list of modern & classic cars in both used and new categories.