I’m looking at structs right now, and I’m kind of wondering something. What purpose or improvement does the C++ Ustruct have over using the pre-defined struct?
Is there a performance improvement?
When using a 2D struct through the pre-defined struct in the editor, I often experience serialization errors when bringing a project from the Windows editor over to the Mac or Linux editor. Usually the Linux editor can handle it better than the Mac editor. The Mac editor often breaks the entire project.
So, I was curious about if I implemented the base of the struct in C++. Then made an array of this C++ ustruct in a pre-defined struct. Thus, making a 2D struct from a C++ base and pre-defined struct.
Would this be any different than just a normal 2D pre-defined struct? Performance-wise and stability-wise?
To help you understand what I’m talking about, here are some pictures. The first one is where I’ve defined the base struct in C++ on the left, and then on the right made an array of it within the pre-defined struct of the editor.
Here’s the second picture. In this one, on the left is the base struct made in the pre-defined struct the editor offers. Then on the right is where another pre-defined struct is made with an array of the base struct.
I doubt you’ll see any performance difference at all. To be honest though, in the interest of keeping things in one place I would create all of these structs in C++. Mixing BP and C++ like this can make bugs hard to track down.
Array operations can be much faster in C++ than Blueprint though. BP does a lot of copying.
Interesting, so there’s practically no real implementation difference between the two then? I had thought the Blueprint structs were some form of UClass implementation (I read this elsewhere in the forum which is where my incorrect understanding comes from).
The sole reason I have a BP struct is for quick visual setting of the many variables. For example, setting the textures or models to be used has the auto-complete menu inside the editor, so I don’t have to try and manually remember where each asset is within the content directory. I type the asset’s name and the editor finds it for me and I can be certain the directory path is correct. These variables are also meant to work with the DataTable for changing stuff outside of the editor later on, so the in-editor struct allows me to visually see that everything is correct first.
If I implement the 2D struct in C++, how would I set it’s values beforehand for use in-game? I can only imagine manual labor for remembering each item’s location within my content directory and then writing them down in code in either the constructor or some function (think textures, behavior trees, skeletal meshes etc). My current workflow is setting up the struct values in the editor, and then after that exporting it to a CSV for changing values. Setting the directories to assets in CSV doesn’t seem like a good way to go.
Any best practice for this sort of thing? I appreciate the response, I usually am met with silence when posting on the forums
In the case of what you’re doing there, it’s pretty irrelevant which way you do it really. The C++ way to set those default values would probably be using CDO in the Constructor with FObjectFinder (which as you say, would take a bit of copy-pasta). All you’re really doing here is setting static variables by the looks of it, so it’s just like any other array. You can set the vars using a CSV if you wanted to, and fill the values in at runtime during load / contruction. I would probably go down that route if it was a lot of vars, and it’s easy to do in C++.
It might well be that BP structs are indeed UCLASS, just so you can have the asset type. Either way there’s no performance difference as such. If you don’t care about Garbage Collection btw, you can just use 2D TArrays:
TArray<TArray<MyType>>;
I’ll-advised though, especially since it’s extremely easy to treat a 1D array as 2D, and accessing it becomes considerably faster the more it grows.
Also one thing to bear in mind, since you’re using regular / raw pointers to assets, those assets will I believe be loaded when this struct is used. It’s often a good idea especially with a lot of objects, to use TAssetPtr instead, which can lazy-load objects as and when you need them. Up to you though, just worth bearing in mind for the future!
