UMG widgets that use a Material that is itself using a Material Parameter Collection will not display correctly. It screws up whatever the parameter is ultimately plugged in (opacity, color, etc).
I noticed the problem on a fairly complex material but was able to reproduce it in even the most simple setup as shown below.
In the example, “TestScalar” has the same value as the 1 constant. If the constant is what is plugged into the Emissive, the material shows up correctly on my widget (white). If I plug in the MPC in the Emissive, the widget is completely black.
Unfortunately this has been backlogged for now as our resources are currently dedicated elsewhere. I have bumped the community interest on this bug report, however I would not expect a fix for this error any time in the near future.
Unfortunately, as stated before this has been backlogged and probably won’t be addressed in the near future. I don’t have a timeframe of when this will be addressed, however I wouldn’t expect it in the next few months.
While this is still an issue, the following work around might help.
On the Event Construct node in the Widget blueprint, create a dynamic material instance for each material that needs to use a collection parameter. Replace the collection parameters in those materials with regular material parameters. Then, in the Event Tick node, you can call “Get Parameter” from the material parameter collection, and manually update the values in the dynamic material instances to match the value in the parameter collection.
It’s not pretty, but it allows you to use parameter collections to set the values, rather than direct references. The functionality is there, it’s just a little awkward to set up.
That said, it would be nice if Epic put some bug fixing and cleaning up work into the areas that really need it, such as UMG widgets.
Another workaround if you’re just using it for changing a couple UMG colors at once (not for runtime changes). You can replace all your collection params or vector params with a material function that contains your default values as preview. Then just change the default values in the MF when you want to adjust globally. That’s what I did to drive things like button background color and button border color in my project.
I think I have the same problem. I have materials for all HUD marker types, deriving from one base material which uses a Material Parameter Collection for picking different colors if color blind mode is enabled. The routine that draws the markers is in C++ where I draw them with DrawMaterial(). Changing parameter values in the collection does not have any impact. The changes do not arrive in the material instances used.
If this is the same bug and obviously reproducable, then I wonder why it is marked as “resolved” and “unable to reproduce”:
I did some further digging and found that the “No repro” comes from our internal testing, which is on a later build than 4.13. This may be fixed in a later engine version but was fixed by a separate change, not something direct.
The no repro was in 4.14, not 4.13. It may be fixed by the next release. If it is not fixed within that release, please let me know and I’ll be happy to take another look.
Since this issue is a little outdated, and the bug entered has been marked as resolved. For tracking purposes, would you mind creating a new answerhub post with all the details of your specific issue and how we can reproduce it in a new blank project?
This allows us to better manage the issue as a whole, and if these are possibly unrelated. Just respond with the link to your newly created post and either myself or another team member will assist you.
