Blueprint Optimization | Live Training | Unreal Engine

hi everybody I'm Alexander Pascal and welcome to the stream today I've got West bun our technical writer with us and later on we're gonna have Nick whiting joining us in buy a phone call or skype call I should say today's topic is blueprint optimization best practices tips tricks what you should and should not do with blueprints so let's go ahead start off with documentation that's already available that's going to kind of get you into the flow of things we'll show it up on the main screen here as our screen up yeah there we go so we have some new documentation here for best practices lorne Ridge on our team here has created a general do's and don'ts when it comes to working with blueprints it's right off the main blueprints visual scripting page here if we scroll down a little bit there's an option for blueprint best practices so that's how you can find it and it covers a wide variety of different things working with you know the level blueprint versus blueprint classes and what each of those can give you and how you can use each of those based on your situation and your needs we're not going to go through this here altogether but I did want to highlight the main topics here class variables versus local variables and how you can use those a big one is functions versus macros and when to use each of those and then it goes into blooper communication types general tips again you can kind of scroll through this at your leisure and and learn some of the best practices here at your own pace the other thing that we did want to touch here as far as the documentation is concerned and we'll go into this a little bit later towards the end of the this first segment here I want to talk about profiler so I'm going to pop that page up here if you search from the main documentation page search for profiler or you can see in the nav bar where it sits in the tree we'll talk a little bit about profiler here and how you can use it with blueprints profiler itself is pretty exhaustive we'd have to do like a whole stream just on all the stuff you can do yeah like GPU profiling CPU profiling it's it's quite an interesting piece actually right so I think just to kind of get your feet wet will show you how to get to it just the basic navigation of it and the the general things you can kind of look out for if you're getting hitches in your games how to identify where all the time in your blueprints is being spent and kind of help you narrow down some things that are going on in terms of your blueprints again instead of covering rendering and all that stuff we're just going to focus on some of the blueprint steps so we'll get into that a little bit later but did want to show you this page again so you can kind of go and look over the details on how to navigate the profiler when we get to it so with that lets actually close these yeah I've put the links up in the chat so you guys should have them okay so what we're gonna do here Nick whiting is going to be joining us a little bit later right yeah he should be in 15 to 20 hours he is gonna probably provide more of the why what we're gonna do here is show you some examples just some some best practices or some tips from from our perspective covering some of the general use cases the things that you use the most so we're gonna jump actually into the editor here I have a sample project up with some examples here so I'm gonna hop in actually the first thing we talk about is tick so I'm playing in the edit here now and this is not fancy along the left here you can see the text for 100 right now it is ticking my Mach health I didn't want to create a um G widget and all of that just for debug purposes this is perfectly fine this is my health and this is ticking every frame so tick you got to be very careful when and where you use that in a single-player scenario using tick to run a couple things here and there may be perfectly fine however you do got to be careful if you're calling a lot of things on tick that can start to bog your your game down and especially in a multiplayer scenario you and I were talking about this earlier depending upon tick is not very reliable so to give a complete explanation so tick is frame based execution so when you're executing on tick it's literally saying every frame do this thing so if I'm running at 60fps but my friend has a really bad graphics card and some other bad stuff and he's running it more like 2530 guess who might be taking damage you know so multiplayer not so much yeah you you definitely definitely got to be aware of where you're using it and again in the profiler there's an actually an option to see everything that is ticking both actors and components so again that's very useful to kind of identify where all your resources are being spent so back to our example here one of the things that I wanted to kind of touch on here and I went to lunch with Zack parish the other day and I told him we were doing this stream and I asked him I said you know what are what some tips and tricks that you would use you know for optimizing your blueprints and the first thing that he mentioned was using child blueprints as often as you can and so I kind of want to demonstrate that really quickly here I'm gonna go ahead and so we have our character here on screen running around scape actually and say we wanted another character so I created a little box character here again it's not fancy it's just a box that can move around what we could do if I open it the third person character blueprint here this is all the script for third person character we could duplicate this script in another character to provide that functionality or we could make another blueprint a child blueprint of this which will inherit any functionality we put in here or anything that we add to this blueprint will be passed down to the child child blueprints as well so it gets you a little bit extra mileage and doesn't doesn't require you to add additional script so we have our child blueprint here which is just this box and he has some other script in here that we'll talk about in a minute but you can see he doesn't have all that other script that our third person character does because he's inheriting that script from it so not only does he get all that movement that the third person character gets but we can provide any kind of unique functionality that we want for this specific character in here so if we hop into the editor here in play so I have my character here they can run around and he can jump and if I switch through the other character this character can do the same thing walk around jump but I can also do some additional functionality if I press R it scales up and gets bigger a press R and it goes back down so just an example of using child blueprints here we've inherited all the movement from our third person character but added some additional functionality as well now this is not just for characters if you have pickups or any other kind of blue that share some functionality that you want to pass to other blueprints that other blueprints can use as well that will help in terms of optimization there's actually an example of this in the content examples if I click on this link here and pop that up on screen yeah so if you if you're familiar with the content examples project we have a lot of stuff to work with in there and there's a child blueprint section is this under it this is under advanced blueprints correct it's a class blueprint it's blueprints of hmm so I'll get the content examples project load up the blueprint advanced map and you'll see down the hallway there's all these really great pickups I'll give you a good idea of how that works yeah so this example it's basically showing you to pick up and they all do different things when you pick them up but they're sharing the same functionality of rotating and bobbing up and down being able to determine when the actual item was picked up etc so just a good example of using child blueprints ya know to go back just a little bit people are asking what's a good use of tick since since I know that we tend to be like ooh tick very scary it's actually very good for a lot of rendering stuff and I think Nick did Nick disconnected I think so oh hey hi Nick hello hey how's it going okay done not too bad good you could join us yes I might perfect timing I was just about to start talking about when you want to use tick the best times and you know what you'll you'll probably be way smarter than me on that so as well so yeah the thing about tick is you know it's not inherently evil like it does has it have its uses it just it's one of those things that you should use sparingly um so you know tick gets fired every frame so if you start doing a lot of work in there um it you know it can it'll start building up the amount of time you're spending processing your blueprints every frame so one example week we had was in the infiltrator demo the one with like the the Rastafarian cyber ninja guy we had a bunch of lights that were kind of all going down the hallway and they're all kind of blinking u s-- and that was done in tick and you know one light wasn't too bad right you know it's it's cheap it goes in the scene doesn't really hurt the right but then we started duplicating it you know two or three hundred times down the hallway and all of a sudden it's costing a huge portion of your frame it was like four or five milliseconds of your frame which is just totally blown out of the water so it's one of those things you want to be able to use it um it's really useful for example for characters and stuff if you want to have something that changes um you know every taker if you're listening for some event every tick or doing some sort of rendering thing every takes changing the color of light or something like that you just want to make sure that you don't use it on everything so that everything is sticking in the world right mm-hmm and there's also actually a stats group I think it's uh I forgot which one it is off the top of my head but there's stats actors I think or something like that or sad object which tells you how many things are ticking in your scene and that's a good way to kind of tell immediately if you're spending a lot of time in tick if you have you know forgot that you had this one blue print that had taken abled and you duplicated it a hundred times in your map and all of a sudden the time's going down the toilet um that would tell you how many actors are ticking and can you actually see that inside the inside the game with a console command to bring that up yeah I think it's that object or set off my head but yeah like I said you know you can basically we try to reserve tick pieces basically being like your characters or you know a boss or somethin maybe I'm just trying to limit its use when it's out in the environment just because it is kind of an expensive heavyweight operation if you don't have to use it don't use it right and the other cool thing you can do is if you'll need to use it some other time there's actually a set tick enable function which can enable and disable ticks so if you need you know something to tick when you know it takes damage and it needs to do some fancy effect for a second or two you can enable ticking for that second or two and then just turn it back off when you're done with it and that helps you know keep your number of ticking actors down awesome that actually gets there's a question that we had come in which was if I turn on tick how do I get it back off so nice little yep very cool right yes yeah the next thing that we were going to talk about did you have anything to add about child blueprints we kind of talked about those in terms of you know when when would be a good time to use them and what they give you by using those we are you weren't here for the demo that we just gave of it but I was wondering if you had any other additional information to provide yeah so cello blueprints are super useful when you have kind of a base that you want to build upon in in the game team's actually here like in fortnight we have usually a gameplay program or kind of a more technical designer will make kind of a base blueprint first a you know you have a car in the world you want to have a bunch of different types of car like a cop car a fire truck a normal car stuff like that but you want to have them all share a bunch of functionality like when they get shot the horn goes off and stuff like that we oftentimes have either a game play program or a technical design or kind of go through and make that base car blueprint that has all that functionality and then the level designers or whoever else can go in and just make a bunch of variations of that as a child and change the mesh and maybe they want instead of just the horn honking on the fire truck you know maybe it spritzes water and stuff when it takes damage to build that kind of one-off functionality from a common shared base functionality is a really good application for it so we leverage those really heavily we do for weapons we do it for props we do it for characters all that sort of stuff I think the common comparison that we hear is you were saying it earlier too was the the animals like you have an animal based class and that holds like animals have health they're full of meat they you know they run around and they play it was in dogs fetch cats chase mice it's a yeah exactly you kind of go to specific functionality in the child blueprint but the things that all of them share in the parent blueprint that's really nice because if you have a bug or something in your code you can fix it once in the parent blueprint and then that automatically gets propagated at all the children that come from very cool cool uh what else do we have we have next up we're gonna talk about timers a little bit yep let me throw that link up in the chitchat go for it all right BAM so actually the next two topics kind of go hand in hand a little bit timers and timelines you know cost of timers versus timelines this is I'm glad you're here for this as I was not gonna be able to explain it but I am a student here as well so if you can provide any insight into timers versus timelines cost estimates for those I guess you know there's a lot of variables that come into effect but generally speaking which would you prefer which one's better so if people don't know the difference between timers and timelines timers are basically something that fires off that's an interval you give it to you can say I want some custom event to my blueprint to get fired off every second or every half second and you can tell it to loop or you can tell it to go off once um and it can basically just it tells you that I want to do something at some point later in time timelines are kind of a collection of curves so you know you can blend numbers from zero to one using a nice curve editor but those things are that fire continuously every tick of it so they're they kind of have the same problem that dick does and that it's not you know it's not free to do that every time you take the game and render a new frame you're gonna be doing something if you use a timeline so for things I think you guys had a good example with the the taking damage when you step into fire you could do that with tick or timeline and just every every take give them a little bit of damage or check how long it's been since the last time we gave them damage and if it's been you know a half second do it again but really a timer would be a little bit better suited to that because you can say every point five seconds I want to take another two points of health damage and then you just have a little event that says you know subtract two from my health and go on uh and that only gets fired when you need it so it's a lot cheaper to use a timer than it is a time line component but there's some things you can only do in a time line like if you wanted to blend the color of a light or the intensity of a light and have it looked nice and smooth you'd really want to use the time line for X you want it to update every frame and keep blending so it's nice and smooth alright I think you provided did you probably provide both those links in the chat how to use timers and timeline examples let me see here there too okay okay yeah so there Alex just posted those on the chat there's two good examples the fire example of taking damage I believe that is the actual one that I did for the timers how to use timers I think I wrote that page I think that is the exact example that I gave and for the timeline I believe I did a pickup I think it's the medical one yeah it's a it's the wiki page seven video seven changing things over time okay yes yes yeah it's changing the location of a pickup so it Bob's up and down and rotates and changing the light using a timer to that so it's kind of like what you were talking about as well didn't have an example here in the editor here but it is the same example that we just talked about there's actually no need to go into that again I guess sorry still the Thunder is just such a good example yeah right let's see I guess since we covered timers and timelines let's open up the let's open up the fire blueprint do you want to you want to see it yeah exactly what we're talking about here so when you look at the nodes so let's so here's my character he runs in here's the foot that the fire blueprint here it's got a little box collision on it and when I step into it you can see well there's two things that are happening right now and this is actually very interesting so so the child which has inherited the parents tick event which is to print a string of how much health it has it has inherited that so you're seeing the 100 of the child's health and also the parents health going down slowly yeah there's a way that we can override that that kind of gets into the macros versus functions discussion which we'll do in a second we'll do in a second yeah but did one illustrate that we are losing health here as we are in it and as we exit it then it stops we could do that on tick find a way to do it on tick but as Nick mentioned timers are probably the optimal way to do it and so let's go and open up that fire blueprint really quickly so we can take a look at it now Nick I'd like your input on this as well because there's a million and one different ways to go about doing things there's never just one they're always like 50 ways that a blueprint can achieve right there's this is the way that I just did it for this example I do it a bunch of different ways just to pen depending on the situation but for this particular example on event begin play I just get the player character cast to it and create a reference of it and then when I overlap that trigger box I then check and see is the other actor that I hit that player character and if it is then we can set the timer which calls a function inside the player character blueprint and that's what decrements are health now you could drag off this and cast to the third person character here to check is it indeed the third person character that overlapped this box but they need to be doing that every time that you overlap the box but we only need we know since we started the game that we are going to be checking for this that's why I did it that way so oh yeah absolutely instance since for example since this one was we have one main character we know who it is that can take fire damage we know we'll just do get player-character and cast to the third person character now if we were in a much larger scale game like if we're saying to fable or something in that strain we could do something like an interface that is like is flammable and then we'll we'll cover interfaces in a bit but there's always a hundred ways to do these things yeah so to go back to that function thing really quickly let me go ahead and open that up so here's our event tick up here that is just taking the health variable and printing it to screen since as Alex mentioned our child blueprint is also executing this as well a nifty little thing that we can do is take the script here and collapse it into a function so let's go and click collapse it into a function and just call it print health and then inside of our child blueprint which is this it's right click and say vent yes so anything that's connected to this now will get called when that function is called in our third person character blueprint so in this example we're printing to the screen but say for example instead of health it's say you want the character to execute some kind of special ability you could then in the child blueprint execute a different special ability for this character when that function is called for example yeah absolutely so so since right now it's not hooked up to anything we've basically kind of done like a function override where we said you know what you really don't function as anything though we could replace it with like lose goo or whatever yeah you know so now the only shell yeah no we're not getting both the child and the parent because the child no function yep it might be worth children how to actually call the parent function in there since people sometimes have a hard time finding that in the child blueprint mhm yeah if you right-click on the the print health yeah you can add called a parent oh yeah if you so on that red node there just right click the node itself and then so you see how it says called a parent function in the right click menu halfway down into it you guys look kind of see you'll see that that really just goes okay I want it what the parent says plus whatever else or do something then also do with the parent says to do so yeah go ahead and click that and then you'll see we get this new node and if we hook those up yep that's it I'm gonna zoom in a little yeah so now it says when I you know have the event happen also call what the parent normally does mm-hmm in addition to whatever else yeah if you wanted for example you you know play a fire effect or something out there if you only wanted the child actually catch fire right on there so let you kind of extend the B just said something about like yo where the child catches fire I feel like a terrible terrible NIC very cool uh so we can continue I guess the next thing that we were kind of kind of touch on here was casting yeah so onto the communication side of things yeah you got that link yeah show em it - okay so I kind of did it here so just just to clarify I posted in the chat the just casting how-to documentation in case you guys are curious yeah I believe there yeah that's how to walk you through yeah that one should walk you through step by step through several examples of casting actually and I kind of mentioned it earlier as well that you could off the other actor here cast to the third person character and I guess we should describe what casting is actually if some people don't know yeah it's it's definitely like a very old concept in programming yeah the way that we kind of describe it and turn on at least on the dog team is that it's kind of like a treat as essentially you're basically checking is for example here is Arthur is our player character indeed this third person character blueprint if it and if it is then we can access the functions and variables and properties inside it if it isn't then it doesn't worry about it it just omits it and I think I did have an example of that actually on this pick up blueprint here so we have a pick up factor in our level which is a nifty little statue here and if I open that up there is our other actor we are casting to check is it the Box character that actually overlapped this pick up and if it is which we'll talk about in a moment event dispatchers I'm calling an event dispatcher if it isn't then we check if it's the third person character and then if it is the third person character then we have a blueprint interface again which is another topic that we'll cover here in a second but it's basically just a treat as kind of statement is this thing indeed of a particular type in this example it's definitely being more used as a is valid check oh yes since we're not after we cast to it to check to see if it is of that class we're not really telling to do something you know we could I mean we could set properties we could drag off this and set the health from here we could call any functions from the Box character from here again because we are accessing that particular blueprint and able to access the properties and values inside of it yeah so the the kind of interesting thing with this is if if instead of using casting we used interfaces we could definitely week instead have it say if anything of this inner that implements this interface type which I think we have an example of an interface yeah yeah then it'll try to pick it up instead we can do this a few different ways but since we're just using the one character again you're always going to see us doing that first I think it might be worth pointing out too that um casting is you can only cast from a parent on class to a child class so you know if you have a reference to a character you can cast it to Boxey character or third person character but if you can't cast a character to something that's completely unrelated like a static mesh that's very good point to make actually sometimes we forget about things like that we just assume it's common knowledge but again it's not and it's a very important thing to mention yeah and another thing with casting is a week we didn't show um can you do a pure cast just to show what that looks like like change that one cast there like the second one or something this one yeah since the one is kind of being uses in Israel it can you're right clicking yeah yeah there it is right there I'm blind it's you guys okay so now if you hook up the cast failed straight into the item pickup BAM we could have it like implement something out of here but then we lose that great kind of is valid and you know you still have the valid check from the branch from the success boolean output too so right that lets you clean up a lot of code though if you're absolutely honor percent certain that's going to be one of those third-person characters sometimes it's nice to have that pure cast in there yeah yep a million different ways to do things now did you have anything else you wanted to touch on on casting Nick Before we jump into interfaces and keep moving forward no I think that about covers it I think yeah just remembering that you can only cast from something that's from a parent type to a child type is important because a lot of times people kind of assume oh if I have a character if I cast him to a static mesh I can you know set his material based on that it doesn't work like that it has to go from a parent to a child that's very chair okay do you want throw the next link oh yeah let me throw up the interfaces link so talk a little bit about blueprint interfaces and then we'll touch on event dispatchers and then we'll talk about profiler and then jump into the qnx I know you guys have a lot of questions and I want to get to those as soon as possible so yeah we'll go over very briefly over writing functions that's another me night we just did that Oh mate kinda we did that yeah we didn't use that new fancy override function drop down that's over there or was it I did you did I did on that oh you did I did it in here and we changed it yes we don't there on the left though see it under functions and then you have construction script oh yeah yeah so it's like oh this one yeah yeah that's it that's another way to do an override just to point it out like if you click it it was like a little drop-down menu of things you can overwrite but all right so interfaces right so interfaces let's actually take a look at this quick example again so here's our character there's our pickup up there the blue and statue here which is our quote-unquote pickup is actually implementing an interface so that when I overlap this pickup it sends out a message to both the third person character and our boxy character there who both have implemented this interface and both of them can execute their own script based on when they get that call which is very useful if you have several different things that need to respond to an event and do different things based on that event so for this example the character runs over it and our box changes to a goldish color and our character can run a lot faster so I'm only working with start starter content here ladies and gentlemen so that's why this is how we like to roll yeah so but if you switch to the box since the box is alright using the interface you can also switch his color by running into the pickup Chris so if I switch over to that so this one isn't using a cast to check to see if it's this one actually if it is the box character it's actually going to turn off that fire because I set up an event dispatcher oh I see that kind of gets into the next thing so we'll talk about that in a moment how we did that I mean it's it's on that cast instead of our pickup here if it is our boxing character we're doing an event dispatcher on stage so just trying to mesh everything together just showcase a bunch of different examples in women but our interface here so we've created a simple interface there's a bunch of that's not it there's a bunch of different ways that you could do this so our interface here it's just a function that's being called we could provide inputs and outputs and variables that we want to pass as part of that interface but for this example am I on the interface yep yeah okay it's not showing the grid for some reason so I kind of threw me off but for our example when the interface is called this function is called and it's being executed and the blueprints that implement them if you don't know I'm assuming most of you do but if you don't know you can implement an interface just by going up to the class settings of a blueprint and if we move this window over just a little bit there's an option to add interfaces if you click this Add button and you'll be able to find your blueprint interface here that you can add and once you've added it then anything that's in that interface you can implementing your your script here so what we've done we've added it and then we've added a call to this item pick up here and I've added a variable here and Nick you may want to jump in here I'm not sure if this is the correct way to do it but this is the way that I've been doing it added an array of just targets so it's like a bunch of different actors no I've made it publicly editable so that on the pickup if I go to it in the details panel I could specify you know what start what targets to effect oh I see you got a little drop-down yeah because I've made a publicly editable and I can add you know additional things to effect but they would also have to implement that interface every time I've done an interface you have to specify the target am I correct in assuming that Nick yes so if you go back there I think there's two cool little things to point out if you go back to where you're actually calling the interface mmhmm yeah right there um one is that a lot of people don't know this but if you hook up an array like the interface targets there to a target then even though the target pins not an array what the blueprint compiler does for you basically say I'll call item picked up on every one of the elements in that interface target array so if you had three items in that array right it'll go through ya sequentially and just call item picked up on it so that's a really useful way if you have stuff like that where you want to have one pick up item or whatever it is affect a bunch of different things at the same time you can do that and not have to use a for each or anything like that yeah very good to point that out actually because again I kind of just took that and did it without explaining it but yeah that is an excellent point as well oh that's extremely useful yeah yeah it's it works on functions it doesn't have to be done interfaces it works on both of those so super handy yeah the other thing was you to your other question about the target yeah you have two interfaces are basically like the weight and one way to think about them is they're like a function or event on something mm-hmm that will only call if that item implements that interface so your interface targets there is an array of actors right so you can put any actor in the world there whether or not they implement the interface and that item picked up will basically ask each actor in that array hey do you implement this interface if so I'm gonna call the item picked up ah event on you and if you don't I'm just gonna skip past it right so you can kind of mix and match stuff one of the kind of classic examples we use is like a flamethrower imagine if you're making a flamethrower right in your weapon you just kind of you know trace out in a box or a cone or whatever in front of you and get everything that you touch with the flame and then you could just call you know set on fire interface or something like that and then only the things that you've implemented that interface on like maybe a you know what torch as opposed to a stone or a wall or something will actually respond to it so it's a good way of kind of you know filtering out items that can respond to certain events or not without having to go through and cast you know is this a torch is this a wall is this a piece of wood stuff like that right awesome yeah I would say I think one of the misconceptions that I've seen is that with interfaces it's expected that once a blueprint implements that interface you're kind of done so oh no yeah you even though they've implemented the interface you still need a specific that's fine yeah you have to define what its actual actions are and then you have to you know call system is conception that I've seen a couple times people are like well I've implemented the interface how come it's not yeah it's it's it's not doing the fire particle animation well that's well you have to go into the function and say that I catch fire right yeah I think you know that that's actually another one I don't know if it's the same when you're mentioning but a lot of people assume that if something in the world implements an interface anytime you call an interface message on any target it'll call all the targets then that's not true you you have to direct it to the targets you want to actually call on right which is kind of what I've done here so yeah this is the box character here all we've done is again went to the class settings this one actually I wanted to point this out because it's inheriting from the parent we don't have to specify for it to implement the interface it just comes with it as part of being the child so we can implement the interface here the event item picked up and then execute whatever script we want when the pickup item is picked up yeah and this is just such a great universal function since a for example I'm actually using interfaces for all of my resource objects in an RTS thing I've been sort of working on for fun and so it's you know anything that can be picked up as a resource is part of this interface and as a child of that and and that's generally how you set these things up is you want to from the beginning structure it as this is the base with all of my core elements that everything will derive from and then go from there you know say that actually leads to a good question I don't know if this actually was one of the questions but a question for Nick here interfaces versus casting versus event dispatchers cost wise I mean is there a large disparity between those it sort of always boils down to yeah right I really don't which one do I use in which situation cuz they can all be used yeah you see here it's just which one gets performant and the cheapest way to do it um is if you already have a reference to something just calling a straight-up function or event on it is always the fastest right on um and but if you have to cast every time that adds a little bit of overhead to it so kind of what you did there with the you know third person character you're casting in this situation but in the other blueprint example you actually cashed off that reference to the third person so you do the cast once and then use that everywhere right that'll be the most performant way because you can then just call the function directly right and then go ahead go ahead I was gonna go on to interfaces basically what an interface does under the hood is it takes whatever the target is does a little query to see if it implements the interface or not and if so it calls the function as normal so it's basically like a little mini cast step in the middle there it's pretty efficient um it's probably slightly more efficient than a cast because it just does a little lookup into a much shorter table um so it's probably a little bit faster than a cast but it does kind of make it so that you don't have that nice kind of scoping that you would if you dragged off if you casted something and know exactly what you can roll on it so it's a little more ambiguous and event dispatchers are probably the least efficient of all of us because basically that that's storing in their array of functions to be called serve time you call it has to go through that array and call it on everything so if you had a you know an event dispatcher with you know ten people listening to it you're calling a function ten times ok sitting under the hood so that's probably the least efficient oh yeah the event dispatcher something that you know you you want to use that when you really want to just kind of broadcast to a bunch of different things at once it's totally fine to do it that way um you just don't want to do it in you know like a normal function call if you only have one object or two objects that you're calling it on it's probably a little bit better to use either an interface or a direct function call and with that we're actually gonna cover a little bit on you Mike over a little bit yeah well go ahead and show the example I did want to show one thing here we kind of mentioned about the direct blueprint communication being like the cheapest way I kind of did that as well with our third person character here and our boxy characters I've created just a character variable here and made a public and inside of our level here exposed it so that I can set you know what the character is that I switch to some directly communicating between these two blueprints and did the same thing on this one as well so I don't need to cast or do anything like that I could just use a direct blueprint communication to communicate between these two that's for the switching of character so I'm passing that back and forth to one another so let's go on to event dispatchers here and then we'll jump into profiler really quickly yeah and then get to the Q&A how are we doing on time actually we've got plenty of time and we've got 25 minutes that's good that's really quickly let's go over the least performant dispatcher friend that we just learned so the example that we had was our pick up so as Alex mentioned when the character goes over the pickup it changes the box and increases my characters move speed but if I switch to the box and the box goes over it what the box does is sends out an event dispatcher to tell the fire to deactivate itself so the box goes over it and the fire deactivates my hero yeah right we love you bugs yeah box ER frame so it's just calling this event dispatcher here that we've created inside they this is the pickup blueprint right yep and inside of our fire blueprint what we've did I've moved it all the way to decide because I don't want to talk about yet all we did is on event begin play we've bound that event dispatcher so that whenever it is called it executes customer event here and whatever script is tied to this will get called whenever that event dispatcher is called so that's the only example that I had it here but hopefully we sent out the link as well yeah links another would you have some other use case cases I think you're kind of already gave us some but yeah yes sure um the difference between a function and an event dispatcher is kind of like the difference between like an email directly to somebody else then mailing a mailing list right so a function you know exactly who you're talking to you have a you know some reference like the third person reference in there or some other actor directly you're just gonna call a function straight on right so it's kind of a one-to-one communication where event dispatchers really are meant to be more like mailing lists where a bunch of people can sign up add their names to the mailing list and then when you something happens you basically broadcast to everybody and let them determine what they want to do with it so um one example would be undyed we we do that one in a lot of the games like you know when an enemy dies or something like that um there's potentially a lot of different things that want to happen maybe you're you know HUD wants to play an effect like ooh you killed an enemy maybe the level itself you know if it's a boss enemy or something like that needs to know to open a gate when the enemies died and maybe you need to get power up the game state might need to know about stuff so basically when a single event happens that a bunch of different things want to know about an event dispatcher is a really good way to do that because they can just say hey I died anybody who cares do what you want to do with this right cool yeah that's kind of the example we gave here - awesome so with that let's take a quick look at profiler again we kind of touched on this at the intro to the video that we don't want to go too far into this but we'll just show you some quick things in here and Nick feel free to jump in at any time - in regards to profiler specifically with blueprints and what to look out for so let's just jump in really quickly and if we go to window developer tools session front end so this is where you can access the profiler there's a little tab it says profiler here we are running in the background here so let's go ahead and enable a data preview and there's a lot of stuff that we're looking at here we can there's a bunch of different bells and whistles here again we link the documentation if you want to kind of step through what each of these do but would just kind of want to touch on a couple things to look out for in regards to the profiler here so as you can see there's some kind of like spikes in the graph here again make feel free to articulate this better than me if you would like but because I have not used profiler too much but I did know of a couple things that we could talk about here specifically with blueprints and tick specifically so we find if you have weights many things ticking right there's actually an option I kind of wanted to show that really quickly down on the graph here we've highlighted a section that is has a spike in it and this is very small text so I'm not going to be able to see it feel free to speak up so we're looking for is the game thread and frame time and under here what we're gonna try to find here is the F tick function task and that will tell you everything all the actors and components that are ticking and reducing the number of actors or components that tick every frame is a great way to speed up your game so if we look under there in our example we probably don't have a lot of things that are ticking so if we find frame time should be under world it a couple times is it no it's not under here I don't see it you see the F tick function task I hate it because we were looking at earlier I know we took we took forever to find it the first time - yeah I said the game's read update time yeah I thought it was underworld tick time there's another way that we can get to it too as well you can kind of see it if we go over at least the second thing to kind of find if we go over to inclusive here and we can look there's a ramp time yeah we can look for a blueprint time blueprint time in here right there so this will give you a breakdown of all the blueprints that are running at that particular moment we can hop back over to the hierarchy view here and now you can get a look at what is being executed all the blueprints that are being executed where that time is being sent the number of calls that blueprint made per frame so if you're you know have some hitches in your game this is this would be one way that you can come in and kind of see you know what's causing those hitches again this is a very in-depth topic but it's a starting point I'll probably have to do like a full-on stream about I mean as you can all see on that left side it's a huge list of things you can check and see what is in is not acting the right way performance-wise yeah I think noting out that the spikes that you see up in the green on there are the actual hitches in the game basically the lower that line the faster your game time so when that line goes up sharply you did something that's costing a lot of time so it had a you know a blueprint event that was doing a lot of work on a single frame um you might see that as a bunk right another way you can actually do that too as well if you go to is it maximum they get out of yeah so he's like maximum that will sort it as well - you're looking for the inclusion time whatever has you know something that's more than a couple of milliseconds if you have something like I think one of the examples that I had seen fonts was like 4.5 milliseconds for rendering fonts or something's like why is it every another another weird thing that we discovered was that we there is an idling process so if you if you click off of ue4 and do something else and come back and it's like oh my gosh everything's spiked that's actually the idling process and it's not it's not no danger CPU stall yeah they're two CPUs you don't have to worry about those becoming you see all this ready like what is all this red yeah I worry about this it's like looking in your uh you know your windows task manager and going over and you see oh my gosh idle is 99% that's all yeah another common offender is the tick widgets as well so for you know if you're you want to look for those some slate attributes that says visibility may get called several times for frame so they should be small and return in a timely manner it's just another thing to look out for again I think we should do another stream on this yeah you can go super deep in this the other thing in addition to kind of your your average time and they take times a lot of times if you get things to look for are if you're spawning actors and stuff a lot of times that's a slow process because there's a lot to kind of process in one frame and also activating a lot of particle effects and stuff in big batches this will help you find those by looking for the spikes right sorry about that I think that's actually gonna segue into our Q&A cuz I know one of the questions was this next one of the questions I had as well as like what are the most heavy nodes in blueprint no get all I could closet okay ik I know yeah as a matter of fact that was one of our first question right yeah so I think it's exactly almost that jump into the Q&A now if you want to yeah I wanted to mention this right here is you know kind of super intimidating and not really unless you're a programmer I'm familiar with this it's really kind of hard to rock um but one of the tests that we have just started this week is starting work on improved debugger and performance tools in blueprints so one of the things we want to have is basically you can choose the blueprint to profile just like you choose a blueprint to debug and then it'll give you like a heat map you know draw areas and nodes groups of nodes that are taking a lot of time in red and ones that aren't taking as much time and kind of blue and softer colors like if you've ever seen like you know game level eat maps where most people get killed and stuff you want to do the same sort of thing with performance tuning so that it'll be much much easier you know be able to go right to the node that is causing you the problems rather than trying to suss through that giant list of stuff it's all gonna be based on the same data just a lot easier to visualize it yeah it's gonna actually lead them to another question that I think somebody had is determining how do you isolate which node it is yeah that's that's definitely also know the node then it's gonna be good that's so that's the first question is how would you do bug the performance of a specific blueprint of a specific blueprint node let's say I have function X is expensive but I don't know what node is inside function is the bad one so this would be a kind of a way of seeing that yeah this would definitely help with that because you'd see which functions are being called the game credit profiler also will show that information in there it'll show you which notes are costing the most time mm-hmm in there so that's that's the easiest way is if you kind of drill down in that tree view on your slow blueprint it'll show you which node and which function is getting called the most yeah um if you don't want to do that one way to kind of get around that is just kind of skip a node right you know take it move it up and then skip the execution on it and see if the time gets better or worse in there that's we kind of do that where we we do what's called a binary search where we kind of take off half the graph see if that makes a huge difference and then if it doesn't take off the other half of the graph and then you've kind of isolated into two halves and you keep doing that and smaller and smaller chunks until you nail down down the problem what the most expensive thing is so usually um it's not necessarily a node that's super expensive necessarily but groups of nodes for it yeah um I think there's a question later on about you know what kind of blueprints are the most an early performance and you know what makes things slow do you want me to go right into that now uh yeah sure I have the question right here it's uh which blueprint functions have the worst overhead so we'll go ahead and address that one while you're on the topic so the thing that gets you most in the blueprints is we operate on what's called a virtual machine lots of other things do this like Java runs on a virtual machine and there's a lot of stuff in your web browser that runs on a virtual machine and that virtual machine is basically responsible from taking your your blueprint nodes right and calling the functions that are native C++ functions that correspond to those nodes the biggest overhead in our system is not kind of once you get down into the functions in the native C++ code it that going up and down between layers between the VM and the native functions so we find that the you pay the most cost for that overhead if you're doing really really small bits of functionality for a node so things like you get long chains of math like if you're doing a lot of super complex math every tick the the fact that you have to go down to native code to call the math function and then go back up to VM and then take that result and go back down to native and go back up that's kind of the worst case scenario for for blueprints so the easiest way to speed that up is if you have a bunch of like common complicated nodes just write a C++ function and expose that to blueprints then you're only paying for one trip down to native and then back up for that so we tend to optimize a lot by looking for those kind of clusters of nodes that we use a lot that are paying a lot in that VM overhead and then trying to optimize those into one node so basically going from any nodes to one note is the single biggest optimization you can do for blueprint stuff awesome I think that was actually touched on as well and the blueprint best practices page then we linked earlier I think Lauren wrote something up about that as well yeah a bit of there yeah all right so I guess kind of in that same strain of you know wood is going to be more there um so if I have a blueprint that I've derived from the static mesh blueprint class does that have less overhead than if I made just an actor blueprint with a static mesh component so the only place where there's a difference in that is if you're spawning them dynamically in the game because it's a little bit more expensive to spawn and blueprint right now than it is to spawn a static mesh actor which is what we call a native class because it's made in C++ when it you spawn a blueprint it actually copies the template for the component in there so your static mesh component basically it copies that and creates a new one whereas the native code path skips one of the copies so it's it's slightly slightly faster but you probably wouldn't notice it unless you had just an absurd amount of them and they're so if you're like loading a level in spawning a thousand of those blueprints all in the same frame it would be faster to use a static mesh actor but if you're just spawning one you know like every time you shoot a gun or something like that you're really not gonna notice a difference it's a fraction of a fraction of a millisecond all right really cool and in the other I should point out in the other is where yeah that's a youth when you just place one in a level I'm not spawning you dynamically you basically pay that costs when you place it in the editor so at runtime it really makes no difference hmm it's only when you have to run the construction script basically alright um in that case so I guess the next question is sort of related um where is the most blueprint overhead compared to C++ cuz because we know that blueprints are a little bit heavier so ya learn from in our tests we find that in our kind of like fortnight use cases it's about eleven to twelve percent earned eleven to twelve times slower to write something in blueprint than it is native C++ which is a little bit actually faster than unreal script in Yui 3 was but the most of that overhead is going back to the talking between the VM and the native code there again so again the most effective thing you can do for that is consolidate a bunch of functionality into one node and then you you're not paying the cost of that overhead going back and forth between the native layer and the VM so none of the the functions internally to it really costs much more than the C++ it's that transit time between native and the VM ok and we're actually working on ways to improve that you know we've optimized the the VM code to do less memory copying and stuff like that to speed that up and one of the things we're actually looking at is potentially just exporting blueprints under the hood to be C++ natively so that VM overhead goes away completely so that's that's a little bit longer term research project but it's one of the things about we're looking at doing all right cool um let's see here ok what this is actually something I've been pretty curious about - oh what's better doing 8 line traces or doing one sphere trace it's not really the a - that's important but multiple line traces or one sphere trace at what point does one outweigh the other so this is a little more physics pace but I'm gonna take a stab at it anyway uh because you're paying the the overhead doing the eight line traces is probably a little bit slower because you're every time you do a line trace you're going from blueprint to native code whereas when you do the sphere trace you're doing one on call the other thing to consider is that each one of those lines in the physic system has to go in query you know a length of the line basically sphere checks are super fast because it's just basically a point in a radius so it's really easy for the physics engine to figure out what's within the radius whereas a line check has to go through and basically trace through the octree which is a structure I'm gonna need that tells basically where everything is in relation to each other so it's probably a little bit faster to do this for your trace if for no other reason then the VM overhead is less than the eight line calls all right then that's really good to know that confirmed that really yeah that really does help a lot and in the same strain just calling one line trace node what is the overhead from blueprint compared to C++ and and I guess they're looking for a hard number of some sort so I'm gonna throw two out there and I'll be my guess no yeah it's the VM overhead so if you had like a super tight for loop or something like that calling the line trace every time you're gonna get that worst case kind of twelve times slower but it's just one line trace in the middle of a longer function that doesn't have a lot of kind of going up and down between the VM a you're not gonna notice it nearly as much all right cool um is the for each loop with brake more expensive than just a regular for each loop I asked because the regular loop is a node written in C++ while loop with brake is a blueprint macro slightly but really not a huge appreciable difference on there it's the the for loop with brake basically has a little more state to keep track of but that difference is so minuscule you'll you'll never really notice it in practice okay cool that's neat oh yeah this is this is a really pretty good one for a lot of stuff here next hour the question will have boils down to our blueprints platform-agnostic if I have blueprints running and I package out to Android iOS Windows Mac etc do they perform better or worse on certain os's certain systems they because we deal with the the VM it's pretty much the same across platforms the biggest difference you see is when we're more CPU constrained so on mobile platforms the the CPU isn't quite as good at jumping around in when we're doing execution which the BM kind of does a lot so you'll see probably a little bit worse performance on a mobile constrained platform but on a PC or the modern consoles where you have good out of order execution units on the CPUs there'll be a little bit more performant there okay that's interesting all right so this one's a little bit long here but after optimizing blueprints to the best of our ability if what would be the best or recommended way of going about figuring out minimum and recommended system requirements for PC game so I mean that's a pretty good question I'm not sure if that's something we'll be able to answer but I think we should take a whack at it build 50 pcs with varying degrees of strength and binary search to figure out which one has the 60 FPS you should go down to the QA lab the ridiculous amount of you know Android phones iOS phones PCs and stuff that's just laying off there that's really the only way is to kind of find the representative specs and then test to see how well you can do on each one yeah it's it's much easier to kind of maintain a high performance and kind of do continuous profiling as you build up your game then try to squeak out a lot of performance at the very end if you kind of think about at the beginning it's much easier to make kind of informed decisions on how you set things up and how you lay them out and make design trade-offs as you're going along rather than at the very end it's like when we do VR demos where you know you have to hit 90 frames a second and have ridiculous performance requirements we start at you know 90 to 100 frames a second and maintain that rather than trying to go from 60 to nine you get the very end because it's a much much harder task once you've kind of built up a bunch of content you have to make a lot more tough decisions you know which baby do you sacrifice yeah only another children today I swear okay um so we have a question in about circular dependencies and favorite yeah how should I deal with um G widgets affecting the player controller where the player controller spawns the widget without circular dependencies or using interfaces for everything is there a cleaner way to do this should interfaces always be used to avoid circular dependent even though sometimes they are okay wait it's a little oddly phrased yeah so that kind of it's on a an odd misconception a lot of people because originally circular dependencies just completely broke everything right so he said no circular dependencies kind of around that the time when 4.0 was being released and the way a lot of people went around that was to make an interface because that you can reference the interface but then you don't have blueprint a referencing blueprint B which references back to blueprint a a references the interface and B references the interface but they don't reference each other basically so a lot of people think that interface is only purpose in life is to break the cyclic dependencies and that's not the case they were just the easiest way to do that so cyclic dependencies actually thanks to mr. Michael Beach who's sitting right over there fixed the issues with cyclic dependencies for 4/7 then we found a few in the community because you guys are have a lot more people testing stuff than we do and fix the rest of those up for four point eight so cyclic dependencies now shouldn't really be a concern if they do break please please send us the repro and we'll get it q8 and taken care of but using interfaces and hacks like that to avoid cyclic dependency shouldn't be something that's on people's radars anymore all right that's really good rest of the question but I just wanted to say that well circular dependencies are always a thing that comes up and I know you really shouldn't be that afraid of them at this point we used to all be you know like avoid them at all cost I remember those days someone asked in here and it I didn't actually post it up in the list here but um I'm curious myself he's got ten thousand things he needs to update at once what's the best way to do it yeah I know you can do if they really really need to be updated all at the same time the best way is to have some blueprint that's a manager or something that goes and broadcast to all of them rather than having all of them tick or do something like that so basically one thing does the the method the calculations then tells everything else what the result is so if you have to do that all in one frame um that's the best way to do it the better way to do it is if you can have it happen over you know the course of one two three four frames maybe um you can do what's called amortization and what that does is it breaks up the work into chunks so maybe you like update the first thousand the first frame the second thousand the second frame the third thousand the third frame the four thousand the portsmen so how you do that basically as you just you know go through the first you know end number you know thousand elements have them update on this frame you can use a timer to update you know on the next you know 0.05 seconds or something to update the next batch and then you spread that work out across a few frames so that you don't have this gigantic hitch everything when you update that so when we do like huge crowd simulations and stuff like that we you know update basically you know a certain chunk of the crowd at the same time but then spread that out over a couple different frames and that's really how you are able to update a ton of those things in a way that you know you wouldn't even notice the spread between five frames usually unless you're doing something really crazy we try to get away with tricks like that and timer notes are good for that awesome well it looks like that's about all the time we have I know a bunch of people have meetings I got means if welcome to epic meeting central so I'd like to say thank you to my guests West and Nick today you guys have been amazing thank you so much Nick appreciate you yeah yeah thanks for calling it yeah what's such short notice - we won't discuss all the background issues we had to go through just to get this man in organization you should appreciate all the work you did to make this a Shelley over here she's the true boss she was the one doing the hard work all right so yeah we will see everybody Thursday see you guys in two days the May 21st stream will be on recruiting and hiring they're gonna have a chance Emily Gabriel and wife Johnson on there to talk to you guys about recruiting hiring and all the fancy stuff that comes with that it's totally out of my realm of course so yep enjoy we'll see you guys around thank you guys

Channel: Unreal Engine

Views: 28,145

Rating: 4.9344263 out of 5

Keywords: Unreal Engine, Epic Games, UE4, UDK, Unreal

Id: RwbkvUEgCls

Length: 61min 17sec (3677 seconds)

Published: Mon May 25 2015