Fallback Font Assets, Material Presets and Instanced Materials

Unity Engine
1

OK, that title was a mouthful.

I’m trying to understand some details regarding material presets and fallback assets and instanced materials.

For now I have one font asset (static) for all languages but Simplified Chinese. For SC I have a second fallback asset. It is listed in the fallback font asset for the main font asset.

I do not create any material presets for the SC font asset. I create material presets for my main asset for decoration.

In general, when I display Simplified Chinese, I can see the system working quite well: the styles match quite closely, and I don’t think about material presets.

However, when I generate an instanced material (by modifying outlineWidth for example) on an object with the main font asset, then change language so that the fallback SC asset is used, I no longer see the effect of my instanced material properties. So changing outlineWidth while displaying Simplified Chinese won’t do anything. If I change the language back so that the main asset is displayed, outlineWidth works just fine.

I see this most often with faceColor so I have moved all of my color adjustments to color (so its vertex color which is already per object). But for outlineWidth, I have no way to change the shared material’s outlineWidth as far as I can tell (perhaps with keywords directly?).

Is the behaviour I’m seeing expected? Specifically, is it expected that when you instance the material on an object, then go to fallback font assets, the instanced material link is “lost” (until you return to the original font asset)?

Thanks for any information!

2

Just for my understanding, any particular reason for modifying the outline width of the primary font asset which results in an instance being created as opposed to using a material preset of that width?

There is definitely an issue when using material instances and fallbacks.

1 Like
3

I think there is not a good reason. It worked like this in the past: we’d decide “this font needs a tweak in this situation” and we’d throw that tweak during the gameplay into the code.

At this point, we could probably extract those cases into Material Presets, and carry a reference to the Material Presets we need to apply at runtime.

That is probably the correct fix, thank you for asking the question which shifts my perspective.