How do I make a Material Parameter Collection in C++? If I subclass UMaterialParameterCollection, the linker complains about 5 unresolved externals (PreEditChange, PostEditChangeProperty, PostInitProperties, PostLoad, BeginDestroy). These are the virtual functions that UMaterialParameterCollection is overriding from UObject. This says I need the Engine module, which is certainly listed in my Build.cs, and my intellisense has no problem navigating to the bodies of those functions in ParameterCollection.cpp, so…?
Hi Inconceivable,
Are you really wanting to subclass it or just instantiate one?
UMaterialParameterCollection* MaterialParameterCollection = NewObject<UMaterialParameterCollection>(InParent, Class, Name, Flags);
If you were wanting to subclass - maybe just create your own class that contains one…
I’m wondering if it’s a bug. I was able to get it down to 1 error only regarding PostInitProperties.
When not calling super::PostInitProperties() inside of the function the project compiles and crashes mid load suggesting to add Super::PostInitProperties()
Yet UMaterialParameterCollection’s PostInitProperties does not reside in the public: area declaration like in most other classes. This might be causing a linker error.
Compiling causes an unresolved error because it can’t find the method due to it being by default in the private space.
Perhaps it’s a bug, I would have to make it public in a source version and check if inheritance works then.
Edit: Ok after running a source build it gets a bit more complex
UMaterialParameterCollection only has a header file.
It’s implementation resides in ParameterCollection.cpp (strange) a common shared parameter collection where the rest of the functions exist.
Maybe that’s why the postinit is private to have it be called somehow differently internally in the engine.
2 Likes
I found something that might be similar as well when working with FrdSplineComponentVisualizer and it’s menu FUICommandList - I ended up having to recreate the whole menu because I couldn’t link to the original…
So Copy/Pasting those methods from the original source into the subclassed class should work ok.
Yeah seems like a link order issue… shame, since the MPC seems like a good way to pass lots of data for instanced meshes, but not if I have to manually create all the fields or always access it through its TMap…
I think they keep the class clean in the engine and just add side structs to expand it and hold extra information like for example FMaterialParameterCollectionTrackEditor.
1 Like