Hi all. I need help. How i can create array comprising various type.
Example:array comprising various structures declared in C++(marked as USTRUCT) with common base struct
Hey there Forrgit,
Blueprints are picky when it comes to typing an array, and even more picky about Structures. You can just set up the array of structures with the base type that you have, and if I remember correctly, it will allow all subtypes, to be added as well. If it doesn’t, don’t shoot me! lol
To actually create the array, create a variable, and set it’s type to the base type, then set the variable to be an array.
To have access to the structure, from blueprint, you will need to annotate the structure in C++ with the following.
USTRUCT(BlueprintType,
meta = (DisplayName = “Name to display on the node”,
Keywords = “Keywords that can be used to search with”))
struct Dummy_API F_DummyStructureIdentifier {
GENERATED_USTRUCT_BODY()
/*
Dummy Comment that will displayed on mouse hover over the Struct member on the node
*/
UPROPERTY(EditAnywhere, BlueprintReadWrite)
FString DummyMember;
};
Hope this helps,
UStructs do support inheritence for me, at least when I code them up, they are not supported in blueprints.
To Wit the folowing will compile
USTRUCT(BlueprintType,
meta = (DisplayName = " Test",
Keywords = “Test”))
struct IWBPLIB_API FIW_Test {
GENERATED_USTRUCT_BODY()
/*
parent struct
*/
UPROPERTY(EditAnywhere, BlueprintReadWrite)
int32 m1;
FIW_Test() {
m1 = 5;
}
};
USTRUCT(BlueprintType,
meta = (DisplayName = “Test2”,
Keywords = “Test2”))
struct IWBPLIB_API FIW_Test2 : public FIW_Test {
GENERATED_USTRUCT_BODY()
/*
child struct
*/
UPROPERTY(EditAnywhere, BlueprintReadWrite)
int32 m20;
FIW_Test2() {
m20 = 10;
}
};
and the following does work, with the TArray for Test accepting the Structure for Test2
FIW_Test2 t2;
FIW_Test t1;
t2.m20 = t1.m1;
TArray<FIW_Test> t1Ar;
t1Ar.Add(t2);
I’m using 4.10
i saw this question was in the “blueprint scripting” category, so i assumed you wanted to use data compatible with blueprints. i usually avoid c++ data types that can’t be viewed in blueprints, and until blueprints support UStruct inheritance, i will continue to ignore its existence as a workflow policy.
but that’s because i focus on gameplay programming, where rapid prototyping with my data is important, and you might be working on engine programming, where blueprints are irrelevant.
yes, the gentlemen did ask in the blueprint category, and blueprints will not support the inheritence, which is a shame. Yet in C++ UBT, and UHT have no issues with doing it. It’s blueprints that need to catch up, not the rest of UE4, but that can be said of many things, lol.
I still believe that a hybrid approach, for any real work, C++, but for logic, and rapid prototyping, with a later reduction of the prototype to C++, for this Blueprints cannot be beat.
But there is always a need to keep the number of nodes in a blueprint as small as possible.
to be honest, i still haven’t even used TMaps, because they aren’t fully supported by blueprints. as an artist, im more of a visual learner, and i like to see the nodes, color coding, and details panel layout, because i have photographic memory, and its easier for me to remember how something looks than remember a bunch of text.
i read c++ code far more than i write it, but i love using blueprints, because it compresses the information visually in a way i can easily memorize, and allows me to play with the data, and playing with things i can see is the fastest way for me to learn.
TMaps, are well, ummm, just a map, not a big deal. Heck Donald Knuth was writing about them long ago (of course along with many other things!). As I think in the abstract, in terms of functions, data, how it all has to flow. Blueprints slow me down. Yet that doesn’t mean I think they are “bad”, they definitely have a place in the UE4 world. They are certainly nice for glueing things together, yet Blueprints have their limitations, especially in terms of how they allow one to think. Expand the number of function nodes that are available, i.e. in my blueprint function library in C++, there’s over 100 nodes, most of them to “compress” multiple normal nodes into one call out. And all of a sudden instead of having just one screw driver, you have 100 different screwdrivers all designed to take care of repetitive work, and instantly the thought process changes. And it’s always the thought process that is critical, not the actual implementation of that so much.
i use c++ blueprint function libraries, but i usually only put code in there that is impossible to do with blueprints, like functions for adjusting sound volume or multiplayer split screen, maybe i should use it to optimize blueprint function call overhead, like you suggest. my only problem with doing that, is that it makes it harder for me to help other people with their blueprint scripting. i like to be able to post a few event graph images, without needing to tell them to open visual studio. and so far, blueprint alone has been more than efficient enough for everything i have attempted.
also, if you want to explain TMaps to an artist, don’t just say “its just a map”, because artists call plenty of things maps: texture maps, gradient maps, world maps, ui mini-maps, and even game levels are called maps…
TMaps are more like the Math definition of Map, where a function translates inputs to outputs. artists generally don’t think of that definition when they hear the word “map”.
I think it really depends on your style of “coding” I tend to use a lot of flags, etc. So for me, when I have a node that I created say “IW: If Bool OR”, and it takes in the two bools, and does the OR or And (i.e. one node to execute for the fundamental different logic gates), etc. Then comes back on the true false execution, or others where I manipulate integers/floats based off a boolean, or another one where I set the
- Mobility,
- Parameters for materials (multiple parameters for multiple materials),
- create the Dynamic Instance Material,
- Apply the Dyn to a Mesh,
- Attach it to the owner.
I’ve eliminated many nodes, as well as a loop, to handle the setting of material parameters. others do things, such as you stated, that cannot be done in blueprints, or that I just find too bulky to do with the standard nodes. Such as doing work with time, etc. And believe it or not, getting rid of nodes really does speed up blueprints, I have yet to sit down and and do performance testing, but when you look at the call stack… yeah.
But to help others, we don’t have to tell them to open VS2015, only need to remember how I use to do it, before the new nodes came into play. But I must admit, and there is no doubt of this. When I see some of blueprint graphs posted on here. I’m like, geezus I’m glad I don’t have to do that anymore.
i would love to know how a blueprint node would look, which allows you to set multiple parameters for multiple materials. to me, that sounds like a separate function would need to be written to be compatible for each material, or you would need some kind of generic array of floats and array of colors that the function interprets. it sounds like the kind of thing struct inheritance would help with, if it was allowed in blueprints.
how would you keep a hard coded function like that from breaking, when an artist changes a material parameter name?
i would think you would need to combine names and values, into a struct, in separate arrays for each value type, so if a tech artist changes some material parameters, they just have to update some blueprint node names to match.
just have to consider what you are doing, 1 static mesh, with multiple materials, and each material can set multiple parameters. What makes this easy? When using another node that I wrote to get all the materials, and all the parameters for those materials, it just returns them already set up for use, but the node that I mentioned, So what we have is this.
struct {
Material pointer;
Array of Scalar parms (with value, and name)
Array of Vector Parms (with value and name)
Array of Texture Parms (with value and name)
}
this struct is then in a array that is returned to the caller of the Get Materials node. The Set Materials portion of hte node that I mentioned, is set up to take that same structure, then just iterate over the arrays for the parameters, and of course iterate over the array of structures, for the given mesh, using a Dynamic Material Instance that it creates on the fly, and returns.
But in terms of Materials, all materials have the same base set of parameter types, Scalar, Vector and Texture (these are the only ones that Epic allows us to have access to, The Static Bool Switch parm type, we cannot touch, and it really sucks, because with that one, a person could flip on and off at will, entire subportions of a Material, that’s where the real power would start). Of course some people would want access to the Font Parameter type as well, but we don’t have access to that either.
The reason I really wrote this node, was in (shameless plug for my spline product, and the associated blueprint library i’ve talked about), I open up all the parameters of all the materials. So let’s say, a person wants to generate foilage, or generate stairs, or an escalator, or a road system. doesn’t matter. They have access to the material parms. So instead of creating Material Instances, they just use the product, to set the parameters. remembers em, and sets em and off they go. But it allows changing of them during game time as well, etc. continued…
See I’m not a artist, i’m just an old coder. So when I look at creating Material Instances, and I think to myself, heck, I only wish to change some darn parameters… AND I don’t want to spend my life in the material editor. I want to be able to change those parameters, when ever I wish. and I want to be able to see the changes, with the lighting that is in the level, not looking at some little ball, in the material editor, thinking, ok how does that look, then compiling shaders, switching over to the level, and seeing what it looks like. When all I wanted was to change some parms!
I mean it’s just different strokes for different folks of course. Just that for me and I think for other coders, being able to just switch values around, and gettiong on with getting on, is a time saver.
of course because it’s showing the material on the static mesh as well, that also means that one can drag and drop a new material into that slot, and will update the static mesh, for taht slot, that you just dragged and dropped.
I love that part, because that allows me to try out different normal maps, with different textures, etc. And I’m not in the material editor.
are dynamic material instances that cheap, to where you could use them all over the place? i thought that would cause a lot of overhead compared to material instance constants. doesn’t every material variation add draw calls?
Here’s a link to the reference page for the nodes, that we are talking about. Please understand the way the nodes are set up currently, has changed from those screen shots, I’ve simplified it down some, from when I did this.
/iwbplib/bplmaterials.html
From what i have seen, using “stats scenerendering” and watching the draw calls, I have seen no change, except when there are multiple materials. Most static meshes that I have seen make use of only one material. I actually had to do some searching to find meshes that came with multiple materials applied to them for my testing. But let’s say, I create a set of stairs, and each mesh has one material applied, and let’s say, there are 500 stairs that are generated (yeah, it’s long way up to the goose that lays the golden egg), and makes all the steps Instance static meshs, there will still only be around 50 to 80 drawcalls. depending on how your looking, the angle of the steps, etc.
From my understanding, either the mesh is painted with the “static” way, or it’s painted with a dynamic material instance, it’s going to take the same number of draw calls, now if you have two distinct materials,that can generate more calls, but the number of parameters doesn’t play into this at all.
Guess I could have generate 1000 static meshes, with 7 materials on em, and see what we get, versus the same 1000 meshes as ISMs, and see how the 7 materials still impact it, versus 1000 static meshes that only is set up for one material. Then watch scenerendering, to see what it says.
cool stuff. i like seeing the nodes, it helps me understand the interface at a glance. maybe now that blueprints support bitmask enums, you could combine alot of those “used with X” flags.
is there any reason you used strings instead of names? those don’t seem like the kind of string you would need to manipulate or show to the player, so it seems like FName might be more efficient.
I tend to not change the “characters” from their native “engine” representation, if they are FStrings, I will leave em as such, if they are FText, or FName (fname especially for the material parms), I will only flip them over to FString, if I am actually going to use them. The FStrings are just easier to work with,and I have set up a lot of other nodes, to accept them, hence there is no conversion going on, between the nodes. The material parameter names are left alone, because of Get/Set using the same structures, as well as the internal code in the engine, wants a FName.
with 1 material on 1 mesh, it should only cost 1 draw call, for each stairs asset. does each instance of the stairs added to the spline add another draw call?
i usually combine large custom stairs into a single mesh, created in blender. does your spline tool have any way to bake down many instances into a single mesh?
with instance static meshes, it costs far less than one draw call, and I mean a whole lot less, i’ve created forests with , where there were 500 trees, all ISM, there woujld only be around 80 draw calls, now of course a lot of the “draw calls” are never going to happen, because of culling.
So long as the “stair”, or to be specific, the Stair tread, the Ballusters, and Newels, of the stair case, because they are ISMs, add far less than one draw call. per ISM.
The thing is, i’m not modeler, so, I just wanted something that I could conform “stairs” to another object (i.e. stairs going up the side of a cliff if you will), as well as making it a escalator,(and yes, the characters go up the escalator, or down) or ladder, or ramp. But that I could just create the components for the stairs, Stair treads, Walls, wall caps handrails, newels, landings, and ballusters, and drag and drop those meshes into , and have it build the stairs for me. hence one can have a libarary of components, and have stairs that look different. As well as having the flexibility, of making the stairs do weird things too, lmao. Like having stairs that hover in the air? and follow a spline? up and down, right left, etc. just allows me to generate all this in seconds, instead of the hours, it would take me in blender. Just because I’m not a modeler kind of guy.