Is changing MaxNumParameterCollectionsPerMaterial from 2 -> 4 a bad idea?

Development Rendering
, ,
1

We’re considering changing changing MaxNumParameterCollectionsPerMaterial from 2 -> 4 to save significant time across our team merging down MaterialParameterCollections. Our game cooks fine for PC with this change, and a quick look at performance doesn’t show anything obviously slower on a midrange PC. Are there any gotchas here we should watch out for? Is this a bad idea? Thanks

Chris

2

Hi there,

From what I know, this should be fine if you are not running into any major issues on your side. However, our usual recommendation is that people try to use MPC Instances to avoid going over the limit. Have you tried looking into those?

3

Hi Tim, thanks for the info. We’re working on a project with lots of MPCs, so this is an attempt to avoid having to do all the refactoring work to end up with far fewer MPCs.

4

Just for clarification, is an MPC Instance something other than an MPC?

5

I see they’re a distinct class. Can you provide any info on their usage? I’m not turning up much.

6

Hi Chris,

I should have clarified my wording earlier. We want people to start using Material Parameter Collection Instances in the future, as this feature has not yet been officially released. However, it should be in a good enough state to be used. That also means we do not have any public documentation for the feature, although I have the following notes from the developer who worked on this feature as part of our audio framework:

Our change allows you to create related UMaterialParameterCollections in the editor and override them with each other in material instances. This is done by deriving a new collection from an existing collection. The new collection’s base collection parameter layout matches the layout of the existing collection, so the new derived collection can be used in place of the existing base collection in a material instance. Meanwhile, UMaterialParameterCollectionInstance is the dynamic piece of UMaterialParameterCollection that allows you to set parameters in a collection at runtime. Each derived collection that is in use gets a UMaterialParameterCollectionInstance at runtime, so you can dynamically set each one’s parameters differently.

To use it in C++, you call UWorld::GetParameterCollectionInstance with the MPC you want to set parameters on dynamically, then set the parameters through the instance. A blueprint interface for this does not exist yet. We plan to use derived parameter collections to allow instances of the same materials to respond to different music. For example, we might have two songs playing near each other, each providing beat information to associated nearby visual effects and whatnot. This change allows us to avoid doing something that might require you to increase MaxNumParameterCollectionsPerMaterial, such as having a single material that has to decide which parameters to use from several parameter collections.

I hope that information helps you get started if you are interested in using MPC Instances in your project. We would also be happy to hear any feedback you might have, so please reach out if you have any.