they said, preattached child actors, are very buggy and we should not use them directly in an actor as a child, its better to spawn them and then attach.
yeah child actor components are a little weird. It's adviced to not use them as prefabs, for simple stuff like this though, in my experience they are fine. of course if you CAN make something a proper component instead that's always preferable
I heard about that in a presentation on the unreal YT channel. Still, that only does a class check, which is what many people use casts for. But it doesn't replace the full functionality of casting, where the actual use for it is getting to access functions or components on another class.
@ I see. I don’t tent to run into cast problems cause I usually just use an interface call to have the item return the type it is. Like for my player character, I’ll do an interface call on it to see if it’s a characters, which will also return the class, check if it’s valid, and then you have access to all the class functions.
@@musichopper3644 so with that you're pretty much just creating a cast that youve set up by yourself. because if you return a reference that can run class specific functions or access variables, that has to be a reference of that class type, meaning it is a hard reference (unless youre very specifically setting it up to be a soft reference of course). So in the end you've re-created the issue with the casting node, which is that it creates hard references to other classes (and any used assets in those classes)
@@thegamedevcave So I decide to test it out, so the memory usage is basically the same, except for the editor memory because needing to do a manual validation on the interface version takes up memory and so does the interface call node. I also decide to test out if the interface was faster vs casting, and it turns out casting was faster by around 5-10ms on a 100,000 iteration loop, all I did was get the reference and set a variable on the actor. This might be the validation check on blueprints, so c++ could make the difference more negligible but I don't feel like testing it. So lol, the main reason I was using interfaces was because I thought it was a faster lookup time. But I'm willing to be wrong. Guess I actually have to stop putting off learning how to use soft references now. I'm also going to preface this with, I think people focus too much on the memory cost of casting, generally it's fine to use unless you're genuinely abusing it, where an interface call would have been better, like for doing damage. Also, I appreciate the video on GUID you did recently, I feel like it doesn't get talked about enough despite being super useful for saving/loading.
@@thegamedevcave My first typed out response didn't send for some reason, so here's attempt 2. Basically, I tested casting and interface, and their memory cost is basically the same. However, casting is faster than interfaces (anywhere between 5-10ms) after testing them out on a 100,000 iteration loop (let's be honest, you're realistically not running that many casts). Which is not what I expected, but it could have also been due to the blueprint validation check done on the interface, so maybe c++ makes the difference more negligible. Generally I feel people think that casts are evil, but honestly as long as you don't abuse them, and use interfaces when necessary, they're generally not a problem. Also, now I have no excuses putting off learning how to use soft references. I'll definitely look into returning a soft reference through the interface and see how well that goes.
Good video! I think there should be a simple tool that lets you define c++ classes with just a few clicks, for people who aren't interested in learning how to code c++, in case they have the need to benefit from the extra marginal performance boost.
So I really don't think your wrong casting can be ok. However, casting has 1 major flaw coupling. This I find to be even worse than the former issue. I've made a fair few games and everytime someone couples something via cast and we have to make a major change it can really suck and hamper us with having to change the casts or just using interfaces. I always use an interface you cannot go wrong at any point by doing this. However you can go wrong using casts so why do it anyway.
certainly, having better habits with casting still shouldn't be an excuse to rely on them for everything. As with anything, it's cool to use them, not to abuse them
you don't. Gun 1 shouldn't need to be cast to. all the functions and relevant components exist on the master. Running "attack" on the master version of the class will run whatever version of it you program in Gun 1, that's what inheritance does :)
@thegamedevcave That is one way, but holding all of the variables, functions (and child components) in the parent will noticeably increase runtime memory footprint as each child will allocate memory etc PER instance to facilate functionality it doesn't well, facilate. Which is a bit counterintuitive verse simply casting (loading in the class and existing world object). e.g. if an actor was spawned in the world, casting has zero cost as likely all of its dependences are already in memory. Edit: TH-cam keeps removing my replies.... annoying.
@ the amount you save with not loading even a single asset will require a LOT of variables and instances to get to the same level. Most variable types are of a size where we describe them as bytes. Where most assets are comfortably in the megabytes range. It’s super unlikely that you’re actually saving any memory on instances with variables while also loading a bunch of assets. Besides, you likely need those variables anyway so that memory cost doesn’t go away. Dividing the variables between a few different “branches” of classes might be a good idea though to prevent actors from having variables they don’t need. The point isn’t to have 1 massive monster of a master class for your whole game, it’s that functions and variables ideally exist on a base class. Of course you can make as many different base classes as you need
@ True, that it will be unlikely to be above the mb level for a class, but again it depends on the size of declared variables and instance count. If there are 10 unused vectors (3x32 bit (4 bytes) single point percision floats) per 100 instances of that class, then there would be 100(10x3x4Bytes) or 12KB, not facturing other variables and aspects. With potentially far larger variables like text/string and custom structs, this factor can grow further. It may not impact things in the short term, at small scale, but using a high instant count class to allocate memory to unused parameters is like choosing to not use Fast tarray replication (poor server cpu utilisation), its inefficient allocation and in very large worlds (with high instance counts *and* high editor object count) might cause performance degedation later when this is performed on scale. Also, it might be best avoided for devs who target lower performance machines. It's important to remember that object count (and memory) scales not just what is in the world, but all the Uobjects (Uobjects, Datatables, UWidgets, etc) and depencies/assets (e.g. mats, textures, vfx, etc) loaded, so memory profiling is important. Also, uwidgets are only freed once no longer referenced and garage collected (and are often pooled to reduced construct/memory costs). So effectively, your project assets are competiting for resources. You'd be surprised how much even a startup UE5 project is cost on memory (taken as a base level for in editor usage). Now scaling for 10gb usable ram on xbox series x, where profiling is essential. It's fine now, and for the foreseeable future, but I would rather avoid a (low chance) issue late in a pc platform project. Pooling can often help memory and initialisation footprints. Also, casting isn't an issue if the instance already exists in world, the class and the instance variables, dependencies (e.g. textures), etc, are already loaded into memory, so I don't really get the issue prominent in the community against casting when it comes to already loaded (e.g. spawned) instances and classes.
@ True, that it will be unlikely to be above the mb level for a class, but again it depends on the size of declared variables and instance count. If there are 10 unused vectors (3x32 bit (4 bytes) single point percision floats) per 100 instances of that class, then there would be 100(10x3x4Bytes) or 12KB, not facturing other variables and aspects. With potentially far larger variables like text/string and custom structs, this factor can grow further. It may not impact things in the short term, at small scale, but using a high instant count class to allocate memory to unused parameters is like choosing to not use Fast tarray replication (poor server cpu utilisation), its inefficient allocation and in very large worlds (with high instance counts *and* high editor object count) might cause performance degedation later when this is performed on scale. Also, it might be best avoided for devs who target lower performance machines. It's important to remember that object count (and memory) scales not just what is in the world, but all the Uobjects (Uobjects, Datatables, UWidgets, etc) and depencies/assets (e.g. mats, textures, vfx, etc) loaded, so memory profiling is important. Also, uwidgets are only freed once no longer referenced and garage collected (and are often pooled to reduced construct/memory costs). So effectively, your project assets are competiting for resources. You'd be surprised how much even a startup UE5 project is cost on memory (taken as a base level for in editor usage). Now scaling for 10gb usable ram on xbox series x, where profiling is essential. It's fine now, and for the foreseeable future, but I would rather avoid a (low chance) issue late in a pc platform project. Pooling can often help memory and initialisation footprints. Also, casting isn't an issue if the instance already exists in world, the class and the instance variables, dependencies (e.g. textures), etc, are already loaded into memory, so I don't really get the issue prominent in the community against casting when it comes to already loaded (e.g. spawned) instances and classes.
The reason why (loading textures, meches, animation), and the way how to analyze was actually interesting - thank you for explaining!
That awesome insights, thank you so much
they said, preattached child actors, are very buggy and we should not use them directly in an actor as a child, its better to spawn them and then attach.
Yeah I use zero forms of inheritance. You should check out what gameplay tags are and how to use them with primary data assets and data structures
yeah child actor components are a little weird. It's adviced to not use them as prefabs, for simple stuff like this though, in my experience they are fine. of course if you CAN make something a proper component instead that's always preferable
@@thegamedevcave made the same experience, but it was not really hard to make an actor component that attaches the actors on begin play anyway.
You should look into the "IsA" Node that I believe was introduced in UE5.5
I heard about that in a presentation on the unreal YT channel. Still, that only does a class check, which is what many people use casts for. But it doesn't replace the full functionality of casting, where the actual use for it is getting to access functions or components on another class.
@ I see. I don’t tent to run into cast problems cause I usually just use an interface call to have the item return the type it is. Like for my player character, I’ll do an interface call on it to see if it’s a characters, which will also return the class, check if it’s valid, and then you have access to all the class functions.
@@musichopper3644 so with that you're pretty much just creating a cast that youve set up by yourself. because if you return a reference that can run class specific functions or access variables, that has to be a reference of that class type, meaning it is a hard reference (unless youre very specifically setting it up to be a soft reference of course).
So in the end you've re-created the issue with the casting node, which is that it creates hard references to other classes (and any used assets in those classes)
@@thegamedevcave So I decide to test it out, so the memory usage is basically the same, except for the editor memory because needing to do a manual validation on the interface version takes up memory and so does the interface call node. I also decide to test out if the interface was faster vs casting, and it turns out casting was faster by around 5-10ms on a 100,000 iteration loop, all I did was get the reference and set a variable on the actor. This might be the validation check on blueprints, so c++ could make the difference more negligible but I don't feel like testing it. So lol, the main reason I was using interfaces was because I thought it was a faster lookup time. But I'm willing to be wrong. Guess I actually have to stop putting off learning how to use soft references now. I'm also going to preface this with, I think people focus too much on the memory cost of casting, generally it's fine to use unless you're genuinely abusing it, where an interface call would have been better, like for doing damage. Also, I appreciate the video on GUID you did recently, I feel like it doesn't get talked about enough despite being super useful for saving/loading.
@@thegamedevcave My first typed out response didn't send for some reason, so here's attempt 2. Basically, I tested casting and interface, and their memory cost is basically the same. However, casting is faster than interfaces (anywhere between 5-10ms) after testing them out on a 100,000 iteration loop (let's be honest, you're realistically not running that many casts). Which is not what I expected, but it could have also been due to the blueprint validation check done on the interface, so maybe c++ makes the difference more negligible. Generally I feel people think that casts are evil, but honestly as long as you don't abuse them, and use interfaces when necessary, they're generally not a problem. Also, now I have no excuses putting off learning how to use soft references. I'll definitely look into returning a soft reference through the interface and see how well that goes.
Good video! I think there should be a simple tool that lets you define c++ classes with just a few clicks, for people who aren't interested in learning how to code c++, in case they have the need to benefit from the extra marginal performance boost.
If you’re not going to code in c++ there’s very little reason to make a c++ class because you’d be casting to an empty class :)
You supposedly use to be able to build your game with BP to c++ auto converted code, but they got rid of it for some reason.
Great insights!
So I really don't think your wrong casting can be ok. However, casting has 1 major flaw coupling. This I find to be even worse than the former issue. I've made a fair few games and everytime someone couples something via cast and we have to make a major change it can really suck and hamper us with having to change the casts or just using interfaces. I always use an interface you cannot go wrong at any point by doing this. However you can go wrong using casts so why do it anyway.
certainly, having better habits with casting still shouldn't be an excuse to rely on them for everything. As with anything, it's cool to use them, not to abuse them
@thegamedevcave I agree 100%
Ok I cast to the master how to I get gun 1 from it
you don't. Gun 1 shouldn't need to be cast to. all the functions and relevant components exist on the master. Running "attack" on the master version of the class will run whatever version of it you program in Gun 1, that's what inheritance does :)
@thegamedevcave
That is one way, but holding all of the variables, functions (and child components) in the parent will noticeably increase runtime memory footprint as each child will allocate memory etc PER instance to facilate functionality it doesn't well, facilate.
Which is a bit counterintuitive verse simply casting (loading in the class and existing world object). e.g. if an actor was spawned in the world, casting has zero cost as likely all of its dependences are already in memory.
Edit:
TH-cam keeps removing my replies.... annoying.
@ the amount you save with not loading even a single asset will require a LOT of variables and instances to get to the same level. Most variable types are of a size where we describe them as bytes. Where most assets are comfortably in the megabytes range. It’s super unlikely that you’re actually saving any memory on instances with variables while also loading a bunch of assets.
Besides, you likely need those variables anyway so that memory cost doesn’t go away. Dividing the variables between a few different “branches” of classes might be a good idea though to prevent actors from having variables they don’t need.
The point isn’t to have 1 massive monster of a master class for your whole game, it’s that functions and variables ideally exist on a base class. Of course you can make as many different base classes as you need
@ True, that it will be unlikely to be above the mb level for a class, but again it depends on the size of declared variables and instance count.
If there are 10 unused vectors (3x32 bit (4 bytes) single point percision floats) per 100 instances of that class, then there would be 100(10x3x4Bytes) or 12KB, not facturing other variables and aspects. With potentially far larger variables like text/string and custom structs, this factor can grow further.
It may not impact things in the short term, at small scale, but using a high instant count class to allocate memory to unused parameters is like choosing to not use Fast tarray replication (poor server cpu utilisation), its inefficient allocation and in very large worlds (with high instance counts *and* high editor object count) might cause performance degedation later when this is performed on scale. Also, it might be best avoided for devs who target lower performance machines. It's important to remember that object count (and memory) scales not just what is in the world, but all the Uobjects (Uobjects, Datatables, UWidgets, etc) and depencies/assets (e.g. mats, textures, vfx, etc) loaded, so memory profiling is important. Also, uwidgets are only freed once no longer referenced and garage collected (and are often pooled to reduced construct/memory costs). So effectively, your project assets are competiting for resources. You'd be surprised how much even a startup UE5 project is cost on memory (taken as a base level for in editor usage). Now scaling for 10gb usable ram on xbox series x, where profiling is essential.
It's fine now, and for the foreseeable future, but I would rather avoid a (low chance) issue late in a pc platform project. Pooling can often help memory and initialisation footprints.
Also, casting isn't an issue if the instance already exists in world, the class and the instance variables, dependencies (e.g. textures), etc, are already loaded into memory, so I don't really get the issue prominent in the community against casting when it comes to already loaded (e.g. spawned) instances and classes.
@ True, that it will be unlikely to be above the mb level for a class, but again it depends on the size of declared variables and instance count.
If there are 10 unused vectors (3x32 bit (4 bytes) single point percision floats) per 100 instances of that class, then there would be 100(10x3x4Bytes) or 12KB, not facturing other variables and aspects. With potentially far larger variables like text/string and custom structs, this factor can grow further.
It may not impact things in the short term, at small scale, but using a high instant count class to allocate memory to unused parameters is like choosing to not use Fast tarray replication (poor server cpu utilisation), its inefficient allocation and in very large worlds (with high instance counts *and* high editor object count) might cause performance degedation later when this is performed on scale. Also, it might be best avoided for devs who target lower performance machines. It's important to remember that object count (and memory) scales not just what is in the world, but all the Uobjects (Uobjects, Datatables, UWidgets, etc) and depencies/assets (e.g. mats, textures, vfx, etc) loaded, so memory profiling is important. Also, uwidgets are only freed once no longer referenced and garage collected (and are often pooled to reduced construct/memory costs). So effectively, your project assets are competiting for resources. You'd be surprised how much even a startup UE5 project is cost on memory (taken as a base level for in editor usage). Now scaling for 10gb usable ram on xbox series x, where profiling is essential.
It's fine now, and for the foreseeable future, but I would rather avoid a (low chance) issue late in a pc platform project. Pooling can often help memory and initialisation footprints.
Also, casting isn't an issue if the instance already exists in world, the class and the instance variables, dependencies (e.g. textures), etc, are already loaded into memory, so I don't really get the issue prominent in the community against casting when it comes to already loaded (e.g. spawned) instances and classes.