TMP text gets random mask artifacts

Hi - I'm looking for some help with a bug I'm having with TMP 2.0.0 (also in 2.0.1 and
2.1.0-preview.3) where it seems some of our font materials become broken and start to act as if they're being masked out, but they're not.

It looks like this:



Some interesting discoveries:

- The holes appear to be in screen space:



- The holes only show in the Game view, not the Scene view:



- When switching the font back and forth in the editor, some font/material combos show the issue, but some don't:



- The holes appear even if everything else in the scene except the camera is disabled:


(I've hit the files per post limit, so more info in next post)

 

(cont)

- Changing the shader on that material to something else and back again fixes the problem:



This problem also happens in the Player. When you get it there, toggling fullscreen mode off/on, or switching resolution, also fixes the problem. But otherwise it persists on all instances of that font.

As for what triggers the problem, I'm not sure. But here's a gif of it happening:



I've been banging my head against the wall with this for a few weeks now so hopefully someone here might help. We're using unity 2019.3.0f5.

 

Are you using a mixture of <TextMeshPro> and <TextMeshProUGUI> text objects where these objects might share the same material?

 

No I don't believe so, though we do use both types of text objects, we use different materials for UGUI and regular text objects.

In fact, the bug happens after spawning some world-space (non-UGUI) text objects it appears. In the last gif you can see the number 16 pop up, then the camera changes, and then we switch the UI, and that's when the bug appears. The material used for the '16' is one of the ones that has the issue.

 

If you have a case number for a small bug reproduction example, please leave it in this thread and Unity can see what the problem is quickly.

 

Unfortunately I don't have a clear repro. In my experience reporting bugs without a repro to Unity just gets them immediately closed.

 

That's fine, all of these repro's are available to unity developers. What happens is the repro goes to QA, which is a different set of devs. They can close it or pass it on. But if you leave a case number in the thread and a developer is interested it can help them to poke about (they can retrieve it based on case number).

Just a way to safely get a project sent vs zipping and weird urls etc.

 

Is this material common to both sets of text objects?

 

No, it's a different material. You can see the different materials in the OP in the gif under "When switching the font back and forth in the editor, some font/material combos show the issue, but some don't".

The material/font combos that show the issue in that gif are:
- font: 'small', material preset 'Hind-Regular Atlas Material' (used in UI texts)
- font: 'themed', material presets 'themed Material buffName' & 'themed Material damage' (used in world-space texts)

But let's say we were using the same material in both sets of text objects (it's possible it's happening unintentionally somewhere that i'm not aware of). Is this not supported/recommended?

 

The issue comes from the MeshRenderer and CanvasRenderer having different requirements where these two renderers fight over material settings like ZTest, etc. Ie. the material can't be set to two different things at the same time. It is like saying the material needs to be blue and red at the same time.

Just for testing purposes, assign two completely new different font to these objects and see if the issue persists. Then using these same two fonts, create different material presets and see if the issue appears again. By process of elimination we should be able to isolate the culprit.

The issue could be caused by batching too (for some reason) but let's see what the above test results in.

 

Thanks for your help Stephan: I actually found a rogue text object that was using the font in world space. Seperating my fonts and materials into seperate versions for canvas and world space appears to have fixed my problem.

 

That would do it ... those rogue text objects can reek havoc