2:02 "Don't use Tick" 13:45 "You can't make 2D games in UE" 17:54 "Blueprints are slower than C++" 25:50 "Don't use Cast" 32:21 "If it can be Nanite, it should be Nanite" 36:40 "GetAllActorsOfClass is Slow" 40:10 "Don't use ChildActorComponent" 42:45 "UE cooks everything by default" 45:51 "Avoid redirectors / clean them up asap"
Fun fact: [almost] all these also apply to Unreal Engine 4. It's almost as though nothing has changed. So you ca technically still use version 4 and be fine.
Maybe there would'nt be so much "Myth-Busting" needed if the guys at epic would care about a proper documentation and helpful tooltips on all important checkboxes. As it stands now, the entire knowledge base of unreal is community driven and therefore much misinformation is circulating around and about 90% of the tooltips are either only partially helpful, not helpful at all, gramatically incorrect and therefore hard to understand or a blatant lie!
They can't even make a rendering pipeline that doesn't look like Quake 1 software rendering when you take a still image (TAA/TAO), or learn that Euler Angles are just about the worst way to write the movement components of their templates (I've experienced gimbal lock FAR too many times while prototyping game features, for my comfort level). I don't think they're going to write actual documentation, because that would expose the house of cards that the Unreal Engine is today.
With the constant updates itd take twice as long to document every change Basically you pay for what you get…since youre getting it all for free, it easily explains why the community involvement is a big portion of Are you going to fit the bill for 100% current and up to date documentation for every massive leap since 4.27? Especially knowing so many things are being phased out and will soon be obsolete?
@@musicdudem6673 It's only free until you go retail. I see what you mean, but Epic makes their money, and can afford a handful of dedicated wiki maintainers.
i've been arguing with people over casting for FOREVER. i'm totally going to bookmark this timecode and send people over here in the future for that flowchart
I was so excited when he showed the "compare with soft class" node lol, then the rug pull... I generally use tags and interfaces though i may start casting in certain contexts.
@@CCGS Just use cast if you know the reference already exists. Means casting to GameState, PlayerState, GameInstance is basicly free, since they're always loaded.
Usually Unreal's presentations are hard to watch they are boring as f and usually I feel tired after watching them, but this one is a masterpiece it's so fun to watch...
Ari is an awesome presenter. That was entertaining and educational to watch. Thank you! I will be putting a lot of your advice (and myth-busting) to good use.
My god, for the 'Get Actors of Class' myth I was just looking this up. I'd heard it was slow, but I was thinking "surely this function uses hash buckets or something and isn't looping through every single actor in the level"... But everything I read said that it was, in fact, iterating linearly through every actor in the level. Now I know the truth, though. Great video. But them forgetting to change the comment absolutely contributed to the confusion.
I just googled what hash buckets are and figured it was a pretty straight forward no brainer optimization, and yet i wonder why its not like that for get all actors with interface or get all actors with tag.
Interface support in unreal is weird because there are three interfaces : the "real one" only exposed in cpp and not using reflection, the hybrid with declaration in cpp but exposed to blueprint and the one declared in blueprint which cannot be used in cpp. The three of them have different implementations and to use the hybrid one, you must undergo a lot of inconvenience and know your stuff to make it fully compliant and handle properly in both cpp and blueprint. I guess that's the kind of issue epic just don't want to go into for the interface version. Hash bucket saves rt perf but it's at the cost of memory too. Handling actor classes seems logical, interface for the reasons i mentioned (laziness) and tags : the fact is that there are so many usages for tags that i guess they supposed it wasn't worth the trouble...
I think one that was missing that I read a lot is people saying dont use level blueprints, I understand why, but level BPs are super useful and simplify getting actor refs for really simple use cases. I just wish the order that the beginplay could be configured relative to other actors
The "Don't use tick" and then just vanish is the classic move. I remember when I first saw it and thought "wow, if I was a different person i'd never go and look this up". I absolutely despise people who just say things like that and don't leave an explanation. So much so I'll go out of my way to contradict them just to make them explain things. I will say though avoiding tick has really made me better at communication between blueprints.
Same! When I first started out, avoiding tick helped me figure out and understand how to properly make UI and widget stuff that only updates when it changes instead of using tick
Like probably many others I was watching just for the part on Cast. Thanks for clarifying. I've been arguing with people for a long time that casting to the player is completely fine if there are no alternatives and you don't need to decouple as the player is going to always exist and already loaded anyway. Casting to the parent class was something I only learnt recently too and that is also a great tip.
This is all true and good, except the last point about redirectors. For most teams that are not spread out all over the globe, they can and should be cleaned up every night. There is no point in leaving them in if you don't have to, and they will only cause unexpected problems that you are going to have a hell of a time figuring out if you don't know its a redirector problem. I've been there and the only good thing about that experience is that I now know how to avoid it: get rid of redirectors ASAP. Though I really hope epic just switches to GUIDs for everything so redirectors are no longer needed.
Tick: can set to use less frequency to make the tick process faster. Cast: using blueprint interface can avoid cast completely and not need to know other class types. Still all is based of the use case. CMIIW
My question with the first is that there never is an actual use case for an empty tick function, so why does the engine still have overhead for an empty tick function and not assume it's a ghost function? This seems like a pretty reasonable save when there are 4,000 actors in a scene from the same blueprint that all have a tick that was never correctly ghosted. Or am I missing something.
What about Ticks in C++? Since basically in every class that we write Tick is a virtual / override, this means that even if you remove it from your classes it will still tick in the super. Or is that suggestion of don't use empty ticks just for blueprints?
@@flassari it will tick without explicitly setting bCanEverTick if you override Tick in the actor. That said you can disable an overridden Tick with this boolean, which is also true of blueprints.
@@flassari I have not looked at the code underneath the Blueprint tick but I would assume that when you add a node to tick and it Un ghosts it is just doing this underneath in essence and the tick not disabling when node connections are deleted is just an oversight that just not that important to fix overall cause it is small overhead and devs should be profilling and if there is enough empty ticks that actually affects performance in profilling it would be easy to find empty ticks.
Should have gotten into a very big question: "is it bad/wrong to continue making your game in UE4". I get so much flak and heat for saying I want to stay in UE 4.27 as a game dev. But my games are stylized, simple, and I don't need nanite/lumen/I don't sell assets on marketplaces and I don't develop for consoles, UE4 is so much lighterweight and launches in literally 9 seconds on my PC. I very rarely ever get crashes and when I do it's almost always related to moving or renaming project folders shenanigans
Does anyone else use "diet ticks" or "tick lite"? AKA a Set Timer by Event node which gets called on begin play and have it loop every 0.1 sec or 0.05 sec or something. For things that need to be checked constantly but not every frame
I'm an artist working in Unreal for a while and I'm learning BP and other things now at home for being able to make my own little games. What kind of tools or commands can you use to get these deep information like which part is ticking so much. It is interesting as well for my daily job as an artist because I'm usually struggling getting information about what is going on and it seems at times either programmers don't know how to find the information too or don't want to teach properly in how I can figure it out. If there are problems then I usually only hear "that part is expensive" but 0 information or tools to know what is going on. Like the entire screen? What do you mean?! I know a few commands (if I don't forget them again) to get some but it doesn't seem to go deep
You wouldn't have to make a 50 min video myth-busting best practices, if you would release your own tutorials and documentation showing the proper way to use these tools.
the tick myth is in unreal engine as well, it is not a engine or documentation problem completely. your comment is exactly like the reason myths come about, cause in the end game dev is a big messy thing where Sith statements are stupid.
Stop defending what is considered a bad practice for developers. As a developer you are supposed to make clean understandable code with documentation. I am not the reason there are myths of best practices in UEFN, that is a delusional statement.
All great but for child actor components there is no optimal way of NOT using them for real project. Atraching some external actors placed on a level is terrible workflow and designers would break everything.
90% of my angry rants in the shower are aimed at the "NEVER USE CAST" kids running around youtube. The other 10% is for people who say to never us BP or Tick.
There's better ways to do it, I'm sure. I think you can just Spawn Actor and it'll work fine, depending on what you need the current and new actor to do.
this is weird, i have 3 weapons for my character, and they are child actors of it. But everything works fine. i thought its the same as just spawn them in level and attack them to it or not?
There are plenty of people who refuse to use C++, but generally it's based on a lack of C++ skill rather than any particular reason against its use. Though there are definitely reasons not to want to use C++ in a given scenario (compilation times, reinst issues when interfacing with BP, or simply preferring the visualization of BP, etc)
Your reply is a good example of it. There's reverse elitism with Blueprints where you have so many people being proud about doing everything in BP and there's a complete phobia of c++ and discrimination as if they are the "elitists". BP were meant for quick prototyping and to enable artists to do some light scripting work, not to code an entire game. People from other industries in tech know how quickly any decently managed codebase can turn to garbage and the pains of using node based programming (which people have tried and failed many times in other industries). Also the speed comparisons aren't done any justice, this was possibly the most unrealistic test for performance. BP are in fact much slower even packaged and it's very apparent with larger systems. Run anything with loops and you get in the orders of 1000-100,000 times slower. The key is to test a large system and the thing is nobody is going to give a full performance comparison because of how much work it would be. Especially not Unreal because it wouldn't be to their benefit.
Upvote this if you want ACTUAL prefabs and nested prefabs in Unreal after 15+ years. This is ridiculous. No, Blueprints are not prefabs. Freaking Godot has prefabs and Unreal still doesn't.
I think that level instances are destined to become unreal's implementation of prefabs Still a long way but if you want it developped further ... You'll have to suffer the current implementation and limitations and push the community to have epic develop it They won't unless cdproject, fortnite or coalition needs it but that's your beat shot...
@@sotanaht13012 I was thinking that the benefit of big studios switching to UE5 could be that they put pressure on Epic to make some meaningful updates like prefabs. Level instances are still far from actual prefabs, like you said. There are also many other updates that need to be included. Simple stuff: why can’t variable Categories be moved around? Why can’t Level BP have exposed variables in a Details panel. Async functions for setting statuses of Data Layers. Fix folder moving so that things don’t break. Allow asset importing from Marketplace to let you pick a folder location and select which files you want (Unity has had this for years). Instead we get more bling bling like nanite. Guys, normal maps works just fine!
@@jacobpipers This is like asking why so obsessed with using 3d models in a video game. Prefabs provide actual solutions to problems. Also, other game engine looks Godot use them too.
It's really not. Rendering is already on its own thread. Things like asset loading/unloading, audio, etc. all have their own threads. What's single-threaded is the actual game logic you create. Which, imo, should be single-threaded unless you, as the dev, decide otherwise.
Its not, this kind of statements show u dont know much about game engine architectures in ue and general. No one will make MT code for you, and its the same in basically every game engine, if u want MT code then u need to at least opt for it, either yourself or using functionality the engine provides. There will be always a default main loop ST GT, but nothing is stopping u from using MT, but there is no magic functions that will convert your code to MT and synchronise it in main GT, i mean there are MT loops and things like that to help with the simplest scenarios, but anything more tuned needs manual work and games actually need most of the time more sophisticated solutions. Also its just the main GT, everything else has its own thread too, PT, RT, audio, async loading etc. And MT in UE is from the start, many many years, not just 5.4.
See some GDC presentations from people who made Cyberpunk 2077 as an example of a modern fully multithreaded engine. They have a job system and main thread acts as another job worker.
Some of the "myths" are based on false premises. For example, no one just says: "Don't use tick! (or cast etc.)!" Ticks: If you need tick functionality you use tick, who would've thought. What people say is that you do not put heavy stuff there, for example unnecessary queries, checks etc. if you can do it outside of tick. And if it can be Event-based instead of tick polling - use events. Cast: There are reasons why you should be cautious about them and it's not just an overhead they have. Lots of casts may signal problems with your software architecture. I know that game dev lacks behind "mainstream" development like web etc. significantly when it comes to architecture and patterns. But maybe it's time to move past projects with dozens of singleton managers, tight coupling, any actor/component referencing any other actor/component, and many other issues. If you have a proper architecture with abstractions, clear responsibilities and dependency flows, you will rarely if ever use casts because there would be no need.
In years of my career, I'm yet to see a person who states categorically to never use those things 100% without providing a context, so I won't just trust you on that. Guess I wouldn't be that surprised to hear something like this from a junior who parrots half-heard half-understood advice. But if by those people you mean youtubers, well, all I can say is: usually, you shouldn't use them as a source of professional wisdom. Same for Epic's evangelists.
@@pseudohyena so you've seen every person who talks about tick? You don't think that other people could have a different experience and maybe have seen other people talk about it? in "years in your career" you've only dealt with wise experts? never with someone who was under the wrong impression and needed educating? You provide no sources then can't trust someone at their word because "trust me bro" is only good when it comes from you? try some introspection man...
@MensoJero First, no one here had provided any source either. Second, I did say I wouldn't be surprised if some junior says it because he didn't understand the point, but it's not someone who you take advice from, same for youtubers. Of course, me saying "no one ..." is a hyperbole. Are there people who say it like that? Sure, that is not the point. The point is it's stupid to refute an already stupidly put argument. For someone who just starts learning this stuff, a video like this can put them in the wrong direction, making them believe that arguments like "be cautious using this and that" are just stupid and should be ignored because some evangelist from epic made fun of it.
They have added a new function in 5.5 called Instanced Actors that might fix this if it's worked on farther. What it does is convert Actors in to Mass Entities after they are a certain distance from the camera (so basically ECS which is great at multithreading). But in usual epic fashion theres zero documentation or demonstration.
It's a fundamental flaw in the way the renderer works. They have no incentive to fix it because they can drive sales of more powerful GPUs with their poor optimizations. It's called failing up.
Have you had issues in 5.4 and 5.5? Or are you just another gamer repeating this stutter nonsense with no real knowledge of what's happening in unreal?
So if it takes 10 years to do a comment for your best practices.. for your one stop shop engine... From people that are increasingly less knowledgeable about the actual underneath functionality and increasingly we've seen optimization get bypassed again and again to provide certain capabilities... That's not good dude.. I mean my bad sure.. But like come on.. Y'all have created this generation of developers, you got to kind of heard the cats that you've created a little bit.
The Nanite portion of this video could have been redemption for Epic. Instead basic information was given about Nanite such as the incompatibilities, overdraw, WPO issues. No mention that the per-pixel cost is far slower than optimized traditional rendering as proven in our videos. Guess we'll remain the only real "myth-busters" when it comes to Nanite.
They literally busted their own myth. They essentially agreed with you that it's not a 1 size fits all solution. But that doesn't mean it doesn't have its place. I don't think they ever once said, "OK, devs. Here's nanite. You can just trash all other rendering techniques." Like you seem to think. Not everyone has time to build and set up 5+ LOD levels and such that goes with. Obviously most know at this point that if performance is of major importance then nanite is not ideal like singleplayer vs multiplayer and other cases... if the project is OK with the draw backs and is going to be managing those then I don't think its the devil especially considering you can hit absolutely insane polygon counts on static meshes in multiple distances without any lod.
@@dylananhorn1 The real problem is that developers start to use nanite as the holy grail that allows them not to make any LODs, save time and have the same performance. But in reality nanite tanks performance compared to the traditional approach. And in this presentation this point wasn't discussed. Only the limitations of nanite were mentioned and the rest was summarized as "profile everything".
JESUS loves you all ❤️, REPENT and follow JESUS because he is the truth, the way and the life ✨️ 🙏 🙌 ❤️. Sin leads to destruction, rejection of the word of God is to have the mark of the beast, but JESUS leads to peace, love, joy, wisdom, mercy, prosperity, and eternal life ❤️ 🙌 🙏 ✨️. JESUS died for our sins. PRAISE BE TO GOD OUR LORD ✨️ ❤️ 🙏 🙌.
@@tiredcaffeine the did say it in that exact time frame in the video th-cam.com/video/S2olUc9zcB8/w-d-xo.html And honestly, I don't agree with that guy on everything for example there is a video where he says that two versions of one scene have only negligible quality difference between but I also tend to prefer my games with ray tracing enabled and i can recognize small differences in graphical settings most of the time so I might not be a good reference for that But for the most part, his explanation does seem to make sense even though he does emphasize things that i dont think are as much of a big deal as he makes them out to be sometimes(though from his perspective they probably are after all some people notice some things more than others) i am talking about visual quality not performance right now. But i am kind of a beginner so if there is somethings that don't make sense in his videos about optimization that you noticed because of your knowledge on the subject feel free to point them out
@@MyIndieGameDevJourney3818 Okay, when you said "optimization for complex geometry" I thought you were talking about Nanite making things run better. It's not about recognising how things look. Nanite enables artists to not worry about poly counts that much. That's what I think he meant by "enables complex geometry". Without Nanite, you aren't simply going to import a 1 billion triangle mesh into Unreal and forget about it. There is an entire pipeline in modelling for games where you take a high-poly model and dumb it down into something manageable, called "retopology". Even at the highest LOD, or LOD0, you are going to try to keep your mesh detail in check. With Nanite that isn't required, at least to the same degree. Nanite will do that "dumbing down" for you. There shouldn't be much difference in visual quality, other than the fact that Nanite eliminates LODs popping in and out.
2:02 "Don't use Tick"
13:45 "You can't make 2D games in UE"
17:54 "Blueprints are slower than C++"
25:50 "Don't use Cast"
32:21 "If it can be Nanite, it should be Nanite"
36:40 "GetAllActorsOfClass is Slow"
40:10 "Don't use ChildActorComponent"
42:45 "UE cooks everything by default"
45:51 "Avoid redirectors / clean them up asap"
I love this video for giving me ammunitions.
Fun fact: [almost] all these also apply to Unreal Engine 4. It's almost as though nothing has changed. So you ca technically still use version 4 and be fine.
Ari's presentations are always a treat!
Thanks for having me on as a guest.
Thank you for the collaboration! ❤
Was about to scroll further, until I see Ari 🎉 he's the goat
Maybe there would'nt be so much "Myth-Busting" needed if the guys at epic would care about a proper documentation and helpful tooltips on all important checkboxes. As it stands now, the entire knowledge base of unreal is community driven and therefore much misinformation is circulating around and about 90% of the tooltips are either only partially helpful, not helpful at all, gramatically incorrect and therefore hard to understand or a blatant lie!
They can't even make a rendering pipeline that doesn't look like Quake 1 software rendering when you take a still image (TAA/TAO), or learn that Euler Angles are just about the worst way to write the movement components of their templates (I've experienced gimbal lock FAR too many times while prototyping game features, for my comfort level). I don't think they're going to write actual documentation, because that would expose the house of cards that the Unreal Engine is today.
Real af. So much info comes from hobbyists on TH-cam/reddit and that’s where these myths live and thrive.
some people theorize that the reason why their docs are so poor is because the offer paid support to the studios. maybe that's the reason...
With the constant updates itd take twice as long to document every change
Basically you pay for what you get…since youre getting it all for free, it easily explains why the community involvement is a big portion of
Are you going to fit the bill for 100% current and up to date documentation for every massive leap since 4.27? Especially knowing so many things are being phased out and will soon be obsolete?
@@musicdudem6673 It's only free until you go retail. I see what you mean, but Epic makes their money, and can afford a handful of dedicated wiki maintainers.
i've been arguing with people over casting for FOREVER. i'm totally going to bookmark this timecode and send people over here in the future for that flowchart
Lmaoooo
Same!
I was so excited when he showed the "compare with soft class" node lol, then the rug pull...
I generally use tags and interfaces though i may start casting in certain contexts.
@@CCGS Just use cast if you know the reference already exists. Means casting to GameState, PlayerState, GameInstance is basicly free, since they're always loaded.
just done the same with one of those 'DONT USE CAST, USE BPIs' so feel ya bro...
Usually Unreal's presentations are hard to watch they are boring as f and usually I feel tired after watching them, but this one is a masterpiece it's so fun to watch...
Ari is an awesome presenter. That was entertaining and educational to watch. Thank you!
I will be putting a lot of your advice (and myth-busting) to good use.
My god, for the 'Get Actors of Class' myth I was just looking this up. I'd heard it was slow, but I was thinking "surely this function uses hash buckets or something and isn't looping through every single actor in the level"... But everything I read said that it was, in fact, iterating linearly through every actor in the level. Now I know the truth, though. Great video.
But them forgetting to change the comment absolutely contributed to the confusion.
I just googled what hash buckets are and figured it was a pretty straight forward no brainer optimization, and yet i wonder why its not like that for get all actors with interface or get all actors with tag.
Interface support in unreal is weird because there are three interfaces : the "real one" only exposed in cpp and not using reflection, the hybrid with declaration in cpp but exposed to blueprint and the one declared in blueprint which cannot be used in cpp.
The three of them have different implementations and to use the hybrid one, you must undergo a lot of inconvenience and know your stuff to make it fully compliant and handle properly in both cpp and blueprint.
I guess that's the kind of issue epic just don't want to go into for the interface version.
Hash bucket saves rt perf but it's at the cost of memory too.
Handling actor classes seems logical, interface for the reasons i mentioned (laziness) and tags : the fact is that there are so many usages for tags that i guess they supposed it wasn't worth the trouble...
Thanks for actual numbers about tick cost. Also, warning about issues of ChildActors in BPs was handy, maybe this was the issue with crashes for me.
I think one that was missing that I read a lot is people saying dont use level blueprints, I understand why, but level BPs are super useful and simplify getting actor refs for really simple use cases. I just wish the order that the beginplay could be configured relative to other actors
The "Don't use tick" and then just vanish is the classic move. I remember when I first saw it and thought "wow, if I was a different person i'd never go and look this up". I absolutely despise people who just say things like that and don't leave an explanation. So much so I'll go out of my way to contradict them just to make them explain things. I will say though avoiding tick has really made me better at communication between blueprints.
Don't use tick
So now instead of saying "Don't use tick", point devs to this video i.e. don't use tick unless you know it's fine and you profile it.
Don’t use tick and don’t use blueprints
"Do your own research bro", everyone that never has done any research but follows opinions blindly
Same! When I first started out, avoiding tick helped me figure out and understand how to properly make UI and widget stuff that only updates when it changes instead of using tick
Like probably many others I was watching just for the part on Cast. Thanks for clarifying. I've been arguing with people for a long time that casting to the player is completely fine if there are no alternatives and you don't need to decouple as the player is going to always exist and already loaded anyway. Casting to the parent class was something I only learnt recently too and that is also a great tip.
this guy is awesome and needs to do every upcoming presentation whatever its about lol
Epic presentation!
But would you say it's a epic mega presentation?
This was a good talk. Thanks Epic!
Love the presentations with Ari.
Thank you, Ari, both for the shared wisdom, the talk and for the text version of it!
this guy is super entertaining to watch tho, I really enjoyed this one
This is all true and good, except the last point about redirectors.
For most teams that are not spread out all over the globe, they can and should be cleaned up every night.
There is no point in leaving them in if you don't have to, and they will only cause unexpected problems that you are going to have a hell of a time figuring out if you don't know its a redirector problem. I've been there and the only good thing about that experience is that I now know how to avoid it: get rid of redirectors ASAP.
Though I really hope epic just switches to GUIDs for everything so redirectors are no longer needed.
Great presentation, let alone the tech detail, well done sir...
Super useful tips! This is a must-see for any Unreal Engine dev.
Really great talk and super helpful tips! This rivals some of the top GDC talks of all time
Awesome presentation once more! Thank you!
0:00 Rick Sanchez starts talking
49:39 Rick Sanchez stops talking
Yay ! I remember his previous mythbusting video. That was also fun 💯
Edit : I think this is the same video as before 😯
I got to say, this video is a long time coming. Could've come in a memo like he said at the beginning but still very greatful.
Ari always rocks! Amazing presentation! Please more content from Ari
Great Video btw! Make a series out of it if it's not already :D
Invite Doctor Who to talk about unreal more often. He's great at it.
Someone thought the mars bar wrapper bit was REAL funny. :))
Great video! Thanks!
The GetAllActorsOfClass comment is why I always believed that...
Great vid!
It would help the community if you guys provided time stamps!
Tick: can set to use less frequency to make the tick process faster. Cast: using blueprint interface can avoid cast completely and not need to know other class types. Still all is based of the use case. CMIIW
My question with the first is that there never is an actual use case for an empty tick function, so why does the engine still have overhead for an empty tick function and not assume it's a ghost function? This seems like a pretty reasonable save when there are 4,000 actors in a scene from the same blueprint that all have a tick that was never correctly ghosted.
Or am I missing something.
It was just an oversight, I added a fix for it in the next upcoming version of Unreal, 5.6. Empty Tick functions will no longer get called.
What about Ticks in C++? Since basically in every class that we write Tick is a virtual / override, this means that even if you remove it from your classes it will still tick in the super. Or is that suggestion of don't use empty ticks just for blueprints?
Ticks in C++ only tick if you tell it to in the class' constructor via PrimaryActorTick.bCanEverTick = true. The tip from the video was for BP ticks.
@@flassari thank you!
@@flassari it will tick without explicitly setting bCanEverTick if you override Tick in the actor. That said you can disable an overridden Tick with this boolean, which is also true of blueprints.
@@flassari I have not looked at the code underneath the Blueprint tick but I would assume that when you add a node to tick and it Un ghosts it is just doing this underneath in essence and the tick not disabling when node connections are deleted is just an oversight that just not that important to fix overall cause it is small overhead and devs should be profilling and if there is enough empty ticks that actually affects performance in profilling it would be easy to find empty ticks.
31:05 I was like WTF???
Wouldn’t it be the same if I cast to a parent blueprint class, which has no assets filled in, instead of an C++ class?
Yup, that also works! 🤘
Should have gotten into a very big question: "is it bad/wrong to continue making your game in UE4". I get so much flak and heat for saying I want to stay in UE 4.27 as a game dev. But my games are stylized, simple, and I don't need nanite/lumen/I don't sell assets on marketplaces and I don't develop for consoles, UE4 is so much lighterweight and launches in literally 9 seconds on my PC. I very rarely ever get crashes and when I do it's almost always related to moving or renaming project folders shenanigans
Ah, my favorite presenter, Ari
Re: C++ vs BPs
What about nativized blueprints tho?
They no longer exist
TL; DR: profile your game
You can use Unreal for 2D; its just better if you know which features to disable or rip out.
Bloody hell! I raised my hand here!
Does anyone else use "diet ticks" or "tick lite"? AKA a Set Timer by Event node which gets called on begin play and have it loop every 0.1 sec or 0.05 sec or something. For things that need to be checked constantly but not every frame
never heard anyone compare about the wrapper being too big on a candy bar that is great comparison lmao
I'm an artist working in Unreal for a while and I'm learning BP and other things now at home for being able to make my own little games. What kind of tools or commands can you use to get these deep information like which part is ticking so much.
It is interesting as well for my daily job as an artist because I'm usually struggling getting information about what is going on and it seems at times either programmers don't know how to find the information too or don't want to teach properly in how I can figure it out. If there are problems then I usually only hear "that part is expensive" but 0 information or tools to know what is going on. Like the entire screen? What do you mean?!
I know a few commands (if I don't forget them again) to get some but it doesn't seem to go deep
fine, I'll rewatch this :D
Ari is the best presenter 🙂
These are literally the same as with version 4 tho, excluding anything nanite and lumens related.
You wouldn't have to make a 50 min video myth-busting best practices, if you would release your own tutorials and documentation showing the proper way to use these tools.
the tick myth is in unreal engine as well, it is not a engine or documentation problem completely. your comment is exactly like the reason myths come about, cause in the end game dev is a big messy thing where Sith statements are stupid.
Stop defending what is considered a bad practice for developers. As a developer you are supposed to make clean understandable code with documentation. I am not the reason there are myths of best practices in UEFN, that is a delusional statement.
Very cool pres super funny !! 😁
All great but for child actor components there is no optimal way of NOT using them for real project. Atraching some external actors placed on a level is terrible workflow and designers would break everything.
One more solution to not using Cast: use components! Find Component of Class on whatever actor.
I see Ari I click on the video
90% of my angry rants in the shower are aimed at the "NEVER USE CAST" kids running around youtube. The other 10% is for people who say to never us BP or Tick.
Nice lab coat.
Wasn't this posted already? Great video, but talk about deja-vu.
Profile!
42:19 this makes me sad.. puts a kink in my plan for a sandbox with a natural selection/evolution style ecosystem..
There's better ways to do it, I'm sure. I think you can just Spawn Actor and it'll work fine, depending on what you need the current and new actor to do.
? This is not a blocker for your game whatsoever.
this is weird, i have 3 weapons for my character, and they are child actors of it. But everything works fine. i thought its the same as just spawn them in level and attack them to it or not?
@@Punisher1992 I'd probably put the weapons as Blueprint Components instead of separate Actors.
@@Badguy292 you mean like a scene component?
Why does he sound like he has Phil Collins' mic
2:38
What is a BP "purist"?
Scripting C++ (even C#) users are the ones who are "purists" and refuse to use nodes (oh but its ok for Blender)
There are plenty of people who refuse to use C++, but generally it's based on a lack of C++ skill rather than any particular reason against its use. Though there are definitely reasons not to want to use C++ in a given scenario (compilation times, reinst issues when interfacing with BP, or simply preferring the visualization of BP, etc)
Your reply is a good example of it. There's reverse elitism with Blueprints where you have so many people being proud about doing everything in BP and there's a complete phobia of c++ and discrimination as if they are the "elitists".
BP were meant for quick prototyping and to enable artists to do some light scripting work, not to code an entire game. People from other industries in tech know how quickly any decently managed codebase can turn to garbage and the pains of using node based programming (which people have tried and failed many times in other industries).
Also the speed comparisons aren't done any justice, this was possibly the most unrealistic test for performance. BP are in fact much slower even packaged and it's very apparent with larger systems. Run anything with loops and you get in the orders of 1000-100,000 times slower. The key is to test a large system and the thing is nobody is going to give a full performance comparison because of how much work it would be. Especially not Unreal because it wouldn't be to their benefit.
Upvote this if you want ACTUAL prefabs and nested prefabs in Unreal after 15+ years. This is ridiculous. No, Blueprints are not prefabs. Freaking Godot has prefabs and Unreal still doesn't.
I think that level instances are destined to become unreal's implementation of prefabs
Still a long way but if you want it developped further ... You'll have to suffer the current implementation and limitations and push the community to have epic develop it
They won't unless cdproject, fortnite or coalition needs it but that's your beat shot...
@@sotanaht13012 I was thinking that the benefit of big studios switching to UE5 could be that they put pressure on Epic to make some meaningful updates like prefabs. Level instances are still far from actual prefabs, like you said. There are also many other updates that need to be included. Simple stuff: why can’t variable Categories be moved around? Why can’t Level BP have exposed variables in a Details panel. Async functions for setting statuses of Data Layers. Fix folder moving so that things don’t break. Allow asset importing from Marketplace to let you pick a folder location and select which files you want (Unity has had this for years). Instead we get more bling bling like nanite. Guys, normal maps works just fine!
why so obsessed with the unity prefab workflow?
@@jacobpipers This is like asking why so obsessed with using 3d models in a video game. Prefabs provide actual solutions to problems. Also, other game engine looks Godot use them too.
I'm very sorry you had to go all the way to Seattle to try and talk to people.. It really is one of the worst places for doing that.
8:45 Tick
Game Thread being single threaded is crazyyy in 2024/5, really need to work on that.
It's really not. Rendering is already on its own thread. Things like asset loading/unloading, audio, etc. all have their own threads.
What's single-threaded is the actual game logic you create. Which, imo, should be single-threaded unless you, as the dev, decide otherwise.
There is multi threading in 5.4+
Its not, this kind of statements show u dont know much about game engine architectures in ue and general.
No one will make MT code for you, and its the same in basically every game engine, if u want MT code then u need to at least opt for it, either yourself or using functionality the engine provides.
There will be always a default main loop ST GT, but nothing is stopping u from using MT, but there is no magic functions that will convert your code to MT and synchronise it in main GT, i mean there are MT loops and things like that to help with the simplest scenarios, but anything more tuned needs manual work and games actually need most of the time more sophisticated solutions.
Also its just the main GT, everything else has its own thread too, PT, RT, audio, async loading etc.
And MT in UE is from the start, many many years, not just 5.4.
@@tiredcaffeine it should not be in this day and age. It's no longer 2004.
See some GDC presentations from people who made Cyberpunk 2077 as an example of a modern fully multithreaded engine. They have a job system and main thread acts as another job worker.
It wasnt true...guess I gotta bust 😘
👍
Babi buta ! 😊🙏
Some of the "myths" are based on false premises. For example, no one just says: "Don't use tick! (or cast etc.)!"
Ticks:
If you need tick functionality you use tick, who would've thought. What people say is that you do not put heavy stuff there, for example unnecessary queries, checks etc. if you can do it outside of tick. And if it can be Event-based instead of tick polling - use events.
Cast:
There are reasons why you should be cautious about them and it's not just an overhead they have. Lots of casts may signal problems with your software architecture. I know that game dev lacks behind "mainstream" development like web etc. significantly when it comes to architecture and patterns. But maybe it's time to move past projects with dozens of singleton managers, tight coupling, any actor/component referencing any other actor/component, and many other issues. If you have a proper architecture with abstractions, clear responsibilities and dependency flows, you will rarely if ever use casts because there would be no need.
trust me, there are many people who say exactly that. They say 100%! never use tick or cast. And so on.
Trust me, there are big youtubers who say never use cast.
In years of my career, I'm yet to see a person who states categorically to never use those things 100% without providing a context, so I won't just trust you on that. Guess I wouldn't be that surprised to hear something like this from a junior who parrots half-heard half-understood advice. But if by those people you mean youtubers, well, all I can say is: usually, you shouldn't use them as a source of professional wisdom. Same for Epic's evangelists.
@@pseudohyena
so you've seen every person who talks about tick?
You don't think that other people could have a different experience and maybe have seen other people talk about it?
in "years in your career" you've only dealt with wise experts? never with someone who was under the wrong impression and needed educating?
You provide no sources then can't trust someone at their word because "trust me bro" is only good when it comes from you?
try some introspection man...
@MensoJero First, no one here had provided any source either. Second, I did say I wouldn't be surprised if some junior says it because he didn't understand the point, but it's not someone who you take advice from, same for youtubers.
Of course, me saying "no one ..." is a hyperbole. Are there people who say it like that? Sure, that is not the point. The point is it's stupid to refute an already stupidly put argument. For someone who just starts learning this stuff, a video like this can put them in the wrong direction, making them believe that arguments like "be cautious using this and that" are just stupid and should be ignored because some evangelist from epic made fun of it.
Fix the stutter
They have added a new function in 5.5 called Instanced Actors that might fix this if it's worked on farther. What it does is convert Actors in to Mass Entities after they are a certain distance from the camera (so basically ECS which is great at multithreading). But in usual epic fashion theres zero documentation or demonstration.
It's a fundamental flaw in the way the renderer works. They have no incentive to fix it because they can drive sales of more powerful GPUs with their poor optimizations. It's called failing up.
Have you had issues in 5.4 and 5.5? Or are you just another gamer repeating this stutter nonsense with no real knowledge of what's happening in unreal?
Is the Hitching from world partition?
@@LittleBlue42I'm both Dev and gamer, and Epic needs to fix the damn stutter
I mean... doing comparisons on a threadripper is useless. 99% of gamers don't have one.
So if it takes 10 years to do a comment for your best practices.. for your one stop shop engine... From people that are increasingly less knowledgeable about the actual underneath functionality and increasingly we've seen optimization get bypassed again and again to provide certain capabilities... That's not good dude.. I mean my bad sure.. But like come on.. Y'all have created this generation of developers, you got to kind of heard the cats that you've created a little bit.
The Nanite portion of this video could have been redemption for Epic.
Instead basic information was given about Nanite such as the incompatibilities, overdraw, WPO issues.
No mention that the per-pixel cost is far slower than optimized traditional rendering as proven in our videos. Guess we'll remain the only real "myth-busters" when it comes to Nanite.
They literally busted their own myth. They essentially agreed with you that it's not a 1 size fits all solution. But that doesn't mean it doesn't have its place. I don't think they ever once said, "OK, devs. Here's nanite. You can just trash all other rendering techniques." Like you seem to think. Not everyone has time to build and set up 5+ LOD levels and such that goes with. Obviously most know at this point that if performance is of major importance then nanite is not ideal like singleplayer vs multiplayer and other cases... if the project is OK with the draw backs and is going to be managing those then I don't think its the devil especially considering you can hit absolutely insane polygon counts on static meshes in multiple distances without any lod.
@@dylananhorn1 The real problem is that developers start to use nanite as the holy grail that allows them not to make any LODs, save time and have the same performance. But in reality nanite tanks performance compared to the traditional approach. And in this presentation this point wasn't discussed. Only the limitations of nanite were mentioned and the rest was summarized as "profile everything".
The best practice for the Unreal Engine, is to not use the Unreal Engine if you care about performance.
Threat Interactive already debunked this slop engine. Too bad.
Unreal framerate engine. more than 30 is an old concept and we should improve upon that. how about we make 2 fps games?
quad overdraw engine 5
JESUS loves you all ❤️, REPENT and follow JESUS because he is the truth, the way and the life ✨️ 🙏 🙌 ❤️. Sin leads to destruction, rejection of the word of God is to have the mark of the beast, but JESUS leads to peace, love, joy, wisdom, mercy, prosperity, and eternal life ❤️ 🙌 🙏 ✨️. JESUS died for our sins. PRAISE BE TO GOD OUR LORD ✨️ ❤️ 🙏 🙌.
Bust.
I didn't know Borat was an UE expert
I used to think Steve Carrell did crappy voice impressions before watching this
If you think that nanite is better than standard optimization for complex geometry then explain that th-cam.com/video/M00DGjAP-mU/w-d-xo.html
They literally didn't say anything like that. It was literally a "Bust". Also, that guy is half full of bullshit.
@@tiredcaffeine the did say it in that exact time frame in the video th-cam.com/video/S2olUc9zcB8/w-d-xo.html And honestly, I don't agree with that guy on everything for example there is a video where he says that two versions of one scene have only negligible quality difference between but I also tend to prefer my games with ray tracing enabled and i can recognize small differences in graphical settings most of the time so I might not be a good reference for that But for the most part, his explanation does seem to make sense even though he does emphasize things that i dont think are as much of a big deal as he makes them out to be sometimes(though from his perspective they probably are after all some people notice some things more than others) i am talking about visual quality not performance right now. But i am kind of a beginner so if there is somethings that don't make sense in his videos about optimization that you noticed because of your knowledge on the subject feel free to point them out
@@MyIndieGameDevJourney3818 Okay, when you said "optimization for complex geometry" I thought you were talking about Nanite making things run better.
It's not about recognising how things look. Nanite enables artists to not worry about poly counts that much. That's what I think he meant by "enables complex geometry". Without Nanite, you aren't simply going to import a 1 billion triangle mesh into Unreal and forget about it. There is an entire pipeline in modelling for games where you take a high-poly model and dumb it down into something manageable, called "retopology". Even at the highest LOD, or LOD0, you are going to try to keep your mesh detail in check. With Nanite that isn't required, at least to the same degree. Nanite will do that "dumbing down" for you.
There shouldn't be much difference in visual quality, other than the fact that Nanite eliminates LODs popping in and out.
Babi buta ! 😊🙏