Fallback font submesh does not always respect the UI color set

I am having an issue where the initial color of some submeshes doesn't not fully respect the color set on the UGUI TMP Text component. It does not happen everywhere but the result is that highlighted text is not getting the full vertex color. Pausing in editor and changing any field will result in the text being correct. If I include a glyph in the text that is not from the fall back (in this case the fallback is for Cyrillic) that text will be the correct color but the submesh will remain dim.

 

Can you please submit a bug report with the project and steps to reproduce so I can take a closer look?

 

Unfortunately right now I'm in the middle of a push and I don't have time to send bug reports. I was hoping someone might have some thoughts though on what might cause this.

 

Can you post an image showing what you are seeing?

How are these color changes triggered? Are these buttons highlight state related?

 

The color changes should be related to being selected. So effectively highlight. This is occurring with keyboard / controller input so no mouse-over interaction in this case. If mouse interaction occurs over the element then it highlights as it should.

The particular circumstance is an initial menu item being set as the currently selected item when the menu enables. I have certainly had issues where the highlight is not applied if you are not very careful about how and when you force an object to be selected. However, in this case it only breaks on the submesh. The strangest part is simply that there is a color difference but it is incredibly faint - and as mentioned any letters that use the originally pointed at font work fine within the same element.

As I mentioned, any change to the material itself also causes it to render correctly - even though no UI / vertex color data should have been regenerated in this case (unless I've been mistaken and UGUI elements rebuild on material changes?)

Note that the 8 is full white while the Cyrillic is not. Once moving off the text and selecting it again it is correct. The 8 is in the base font asset. Also worth noting is that the fallback font is a dynamic font whereas the base font is static.

 

Any new thoughts on this one?

 

If you are able to easily reproduce this behavior, can you please submit a bug report with project and steps for me to reproduce.

This will make it easier / quicker for me to take a closer look and ultimately resolve any potential issue.

Once you get the Case # from Unity via email, please post it here.