Question Text missing on Apple M1 mac builds

Hi, we've run into an issue with players reporting missing text when playing on the new Apple M1 macs.

This seems to be a similar issue to sharing materials between UI and mesh components but we've run into that and fixed that earlier.

Has anyone run into an issue like this? There's nothing useful in the logs that players send us and we don't have a device to test it in house (yet).

The texts shows just fine when the build is run on the macs from the previous generation.

 

Do you have one of those M1 macs around for testing?

I would suggest testing some examples scenes using different shaders to see if this issue might be shader related. You can try a few of the scenes included in the TMP Examples & Extras.

I would suggest checking texture size as well. See if a 1024 x 1024 atlas works fine.

P.S. I'll see if I can get my hands on one of those M1 mac for testing.

 

We are also experiencing this issue, only affects M1s.

 

Could you please submit a bug report as this is something our iOS Team needs to look at and most likely our Graphic team as well.

Has anyone been able to check if this is Metal specific or perhaps texture size related?

 

Hi Stephan, this is indeed Metal specific, using -force-glcore launch option fixes the missing text issue.

The interesting bit here is that the previous generation Macs use the Metal API too and the issue does not appear there.

 

Thank you for testing the above.

We will indeed need a bug report on this for the Graphic / team handling the support for Metal to take a look at this.

 

Hi, just checking if a bug report has been submitted for this issue, or if there has been any fixes? We're starting to have customers report the same bug with our application. We don't currently have an M1 powered machine to test.

 

I am seeing several bug reports related to the M1 but nothing specific to text that I could find.

Can we get one of you in this thread to submit a bug report on this?

 

Thanks, our project is sensitive and far too big to upload, but for now here is a (cropped) screenshot from our customer, running Big Sur on an M1 powered macbook. Not sure how useful this is, but the text/ui settings are:

Canvas:
Screen Space Overlay
Pixel Perfect
Constant Pixel Size

Text:
Font - OpenSans-Regular
Style - Normal
Size - 22
Rich text yes
No material

 

Are you using Overlay shaders/materials for your Overlay Canvas? This fixed the issue for us.

 

No we aren't using any shaders/materials - did applying one fix the issue??

 

We acquired and M1 machine in order to deal with this issue and found that our problem stems from a shader render pass not executing correctly, which seems to affect the displayment of the text (i.e. probably the rendering of other shaders). Disabling the faulty shader will cause the text to work without issues.

The "faulty" shader, used for a heatmap feature, is correct and is working flawlessly on both Windows machines and Intel Macs, but explicitly not on the M1 running Metal (forcing OpenGL will cause it to work). In editor mode, i.e. when the shader is enabled and visible, it is throwing the following warning multiple times when simply moving the mouse:

Code (CSharp):

1. Metal: Fragment shader missing buffer binding at index 1 (_Data / Custom/Heatmap)

During run-time when rendering the shader with input data, the following warning is thrown every frame and the shader is visibly not rendered correctly:

Code (CSharp):

1. Property (_Data) exceeds maximum allowed array size (1149). Cap to (1023).
2. UnityEngine.Material:SetVectorArray(String, Vector4[])
3. TaxiwayNodeMap:SetMaterialProperties(Material, Boolean) (at ...)

We have verified that the array does in fact not exceed the maximum allowed array size as the fed value is clamped. Are we doing something wrong here or can a Unity dev point us in any direction? The fact that this is working flawlessly on our other Uniy builds makes it difficult to debug. Appreciate any help we can get!

 

I have the same issue on my Mac M1, the font works fine when running in the editor, but when I do a build run one of my fonts goes missing (and when it returns to the editor ALL my game fonts are missing until I re-run the game in the editor)

If I create a new material preset for that font and assign that preset then it works (even though it's the exact same settings for the presets). But the default material preset does not draw at all on the M1.

I'm running Unity 2020.1.17f1 with TMP 3.0.3 and URP.

(my previous build from 3 weeks ago worked without issues on the M1 but that was running Unity 2019.3 and SRP, not sure what TMP version)

 

I tried a whole bunch of things to reproduce it in a clean project, even dragging the same font from my other project but it all worked fine (except that when you add fallback fonts to the font it starts causing drawing issues in the editor on a M1)

 

Ok managed to reproduce it after a bit more investigation...
turns out it happens to the font that is set as the Default Font Asset under Project Settings -> TextMesh Pro -> Settings -> Default Font Asset

Weirdly only happens on the Mac (and from what I understand it's only the M1 chips, that's all I have to test with), Windows works fine.

Not sure if it's to do with the combination of fallback fonts as well as I do use that too for both Project Settings and on the Font themselves.

 

Can you submit a bug report with that repro project?

 

I wasn't able to reproduce it on my test project, only happens on my main game project.
Still trying a few things to see why it does it in one project and not the other.

 

I gave up on it, but for anyone else having the issue, to resolve it I removed the font that was having the issue from here:
Default Font Asset under Project Settings -> TextMesh Pro -> Settings -> Default Font Asset (I just set it to none)

And then did a build & run and the font showed up again.

 

Was that font used by any other object in the scene where text disappears?

Do you have any text objects that are displaying the square missing glyph? Perhaps this fallback was used by some text objects.

Does the issue still occurs if you assign some other font asset in its place?

 

I had 3 main fonts (Bold, Medium, Light) (each with a few fallback fonts).
Light was set as my default font and that one disappeared on the Mac M1 build.
I then changed the default font to Medium and then all my text that was using the Medium font disappeared and the Light font came back.

I have multiple objects using the fonts and all objects that used the font disappeared.

No. Sometimes some players Aliases will have a missing glyph as I display their Steam Alias in-game.


*NOTE*
It only doesn't show for the text where the font is using the default material, so a font with a custom material assigned to it would still show.

 

Any font asset using the default material?

Check if the shader assigned to the default material makes any different. Ie. the Mobile Distance Field vs. Distance Field.

 

Yes, I already tried changing that, but it didn't make a difference.

 

That means it is unlikely shader related.

Can you compare the default material with the inspector in debug mode in your project vs. your test project where the issue doesn't occur? Maybe we can spot something different between the two.

 

We're having this in our project. Users on M1 Macs are reporting that they cannot see the interfaces. It seems like most of our UI in the game doesn't display (images and text)

Has this been fixed yet?

We're on Unity 2020.3.5

If anyone at Unity is actually looking into this then I can share the github repo. It's been six months since this problem was reported though :/

M1 Mac users can solve this apparently by opening the game with Rosetta, which simulates the old Mac architecture. But this obviously isn't ideal.

 

We're also seeing this issue of some TextMeshPro texts not visible on non-M1 2019 model (but working fine on 2018 MacBook Pro):

Update:
Our issue was related to having 3D text objects and UI text objects sharing the same TMP font - resulting in the UI texts losing out. See https://forum.unity.com/threads/tmpro-text-is-not-visible-on-a-device.636085/

Note, for us, this did not occur with Mac OS 10.15.x to 11.2.1 but appears on 11.3 or higher and it appears to be device specific i.e. not a problem on a MBP 13" 2019 running 11.3.1, but is a problem on a MBP 16" 2019 running 11.3.1.

 

We're seeing this as well. Fonts were working fine on M1 in our project until recently. Not sure at all what happened to break things for M1. Regardless, do you guys need just a bug report so that you have something to track against and so that your managers can understand that you're spending your dev time on something that affects actual users?

OR

Do you SPECIFICALLY need a repro project in a bug report?

You guys are super vague about this. Please be clear.

 

Side note: for us the breakage only occurs on TMP text rendered in Unity UI (does not affect 3D text placed in the scene).

 

Just tested this. Removing the default font asset revealed that one of our TextMeshPro - Text (UI) components contained a character (/u2019) that the assigned font did not support. We now suspect that the fallback font system may be a factor in fonts not working correctly on M1 devices. (The issue didn't appear on our M1 device until after the text with the missing character made its way into the project... though we also use the inline formatting features that could contribute as well.)

Removing the default font asset and replacing the offending character (right-single-quotation-mark) with a standard ASCII apostrophe did NOT, however, fix the issue for us.

 

I got some more details about our situation with M1.

• I found that there were several more of the /u2019 characters (as well as two other double-quotation characters) that were not supported in our main font.
• It turns out that the ONLY characters that were rendering correctly were those that relied on the fallback font. Only Canvases with the aforementioned characters actually rendered anything - and only the characters in the fallback font.
• When I say "nothing rendered", I mean nothing. It looks like there is no text at all (no squares/boxes).
• Everything works fine in Intel macOS.

Would love some sort of guidance if anyone has ideas for things to try.

I do not have a small repro project and due to the nature of the fact that our M1 is in a completely different state than the engineer (me) working on the project, it is unlikely that we're going to have one anytime soon.

 

As I mentioned in my last post, our M1 test device is in a different US state from me [the engineer] and it is currently only setup to test builds (no Unity install or project configured).

Do you have any ideas as to what I could try here?

 

I tried that. It didn't repro. If I recall correctly, I created the test scene by dragging the offending text to a prefab, created a new scene, and added the prefab. The only other thing I can think to test is taking the scene with the broken text, duplicating it, and removing everything but the UI to see if that still repros (as opposed to the prefab route)...

 

Do you happen to be using a mixture of <TextMeshPro> and <TextMeshProUGUI> object where these potentially share the same font asset or material preset?

 

Yes. That was something I was going to ensure in the next test scene - keep all TMP use cases in the scene. In the previous test where things worked fine, I had only included the UGUI instances.

In our broken scene, our UGUI usage involves the TextMeshPro - Text (UI) component and the game-space (3D) text uses the TextMeshPro - Text component.

All instances share the same Font Asset and Material Preset.

Could this be the culprit?

 

Yes. This is an issue because you have two renderers (Mesh Renderer and Canvas Renderer) fighting over the ZTest on that shared material. Since the ZTest requirements are different for Overlay vs. World Space and depending on timing, you potentially end up with some text objects disappearing.

The solution is to make sure you use a different set of material presets for Overlay objects and WorldSpace objects. These objects can all still share the same font asset but you have to assign a different material preset to these.

The timing part of this is due to how each device / platform potentially handles batching as in some cases, the material ZTest being changed after the device has rendered those object is fine but in other case, this change on ZTest happens sooner (not sure why exactly) which then renders in some objects not rendering.

This behavior (mixture of text objects in different spaces sharing the same material) has been known for a while but (appears) to be a different issue based on the report from the author of this thread which seems M1 specific.

 

Is it different, though? Or is it possible that the way the M1 "interprets" the code ends up causing the issue to repro 100% of the time?

The only device we've encountered this issue on is the M1 Mac. Intel Macs are fine (it's even the main development machine) and we've not seen any issues when running on a small selection of Windows devices. It only cropped up on M1.


If this is a known issue, I have two questions for you:

1. Is this restriction documented anywhere?
2. Can you adjust the code to do one of the following:
   • Detect when the user has the same Material Preset set for the two different component types and Warn them in the Inspector or at Build time?
   • Create specific material asset wrappers that enforce "This is for UGUI and not 3D" and vice versa so that users cannot accidentally happen upon this issue?

 

It could most certainly be the same issue on the M1 where due to some difference in how rendering is handled it happens 100% of the time.

It would be great if you could check if using separate material presets makes the issue go away or not in your case. This would confirm whether or not we are dealing with the same issue.

This is known but not necessarily a bug but rather the result of several objects sharing the same material where the ZTest is overridden by the various renderers. This is essentially the same as changing a color property on a material shared by multiple objects which results in all objects changing colors. However, in the case of a color property, this is fairly easy to observe whereas the change in ZTest is not.

There have been numerous threads on the forum about this over the years. It was also documented in the FAQ on the old TMP website and referenced in one of the sticky posts in this section of the forum. However, since the old TMP forum is now gone, I will most certainly need to update the sticky.

Having said that, I would love to find a way to detect / warn users about this potential behavior but given this happens at the renderer level which all have their own batchers, I haven't been able to find an easy / reliable way to track this. This is further complicated by the fact that materials can be created at runtime, loaded from bundles, modified via code, assigned to objects created at runtime, etc. I will most certainly keep looking for ways to detect this to warn users but most certainly, we need to better document this.

As per the above, let me know if the issue occurs if you use separate sets of material presets for Canvas object in Overlay space vs. other objects in World Space?

 

I should be able to test for this later this week/early next. Hopefully separating the materials will do the trick! I will update here when I'm able to verify.

 

Reports seem to indicate: SUCCESS!

It does appear that [for us, at least?] using the same Material for TextMesh Pro-rendered text in 3D and 2D (Overlay) contexts at the same time results in no text rendering in the 2D (Overlay) space for M1 Macs.

This also explains why the fallback font was properly rendering glyphs that weren't in the custom-created font asset! It had its own, separate Material that was never being used in non-2D contexts because that those texts had full glyph coverage in the assigned font!

 

I have a potential fix for this issue which appears to be related to how the Canvas handles setting the ZTest when using Screenspace Overlay. This behavior also varies per platform, graphic API and devices.

Additional testing on this will be required but the potential fix appears to resolve the issue on the M1.

This fix will be included in the next preview release of the TMP package which should be released next week.

 

Had this issue on my MBP M1 with the latest preview of TextMesh Pro v 3.2.-pre.1 I ended up setting the LiberationSans SDF (and fallback) Material to : TextMeshPro/Distance Field Overlay to get around it not displaying text on my M1.

Seems to work just fine for me on this setting.

 

Any news on when the next version of TMP will be released with the fix for this issue?

 

It will be available next week.

 

I've been following this thread and implemented a fix with additional materials in my project for now.

Has there been a new release of TMP with a fix? If so which version because I cannot find anything that has been updated since August. Thanks in advance.

 

Is there any news on when the fix for the issue will be released?
If it will be further delayed, can we get a hint on what part of the code should be modified to make it work as a workaround?

 

This should be fixed in the new preview release which should be available within the next few days. I am currently going through the release process.