Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

TextMesh Pro Text stops rendering on iPad after some animations.

Discussion in 'UGUI & TextMesh Pro' started by zubrjosh, Feb 13, 2018.

  1. zubrjosh

    zubrjosh

    Joined:
    Oct 6, 2017
    Posts:
    7
    I am fading TextMeshProUGUI alpha in and out with mechanim, it works fine for the first three windows of my UI but after that it breaks and no longer renders at all. It works fine when I am running the scene in the editor, but when built to iPad it consistently stops rendering at this point.

    There are 4 animations per window.
    Off - GameObject off.
    On - GameObject on.
    Open - Fading in text and other elements (other elements DO appear).
    Close - Fading out text and other elements.

    I'm building in Unity 2017.3.0f3 on an iPad Pro.
    Xcode is version 9.2.
    I am using Metal as graphics API and have turned off multithreaded rendering.

    Is this a problem with my player settings or just an incompatibility with iPad?
     
  2. Stephan_B

    Stephan_B

    Joined:
    Feb 26, 2017
    Posts:
    6,595
    See if you get the same behavior with a desktop build? I suspect the alpha value or something in the animation doesn't reset.

    In terms of this being a potential iPad specific issue, that is highly unlikely is the text would not work at all. The fact that it renders points to something else. To add to things to test, see if no using Metal makes any different or not using IL2CPP. At this stage we are just trying to rule / isolate where this issue might be coming from.
     
  3. zubrjosh

    zubrjosh

    Joined:
    Oct 6, 2017
    Posts:
    7
    Desktop build works the same as in the editor.
    Each window has it's own TextmeshProUGUI (or several) game object, and some of the animations don't use fading but the text still does not appear (sorry, I should have mentioned this in my original post. Some windows are dropdown notifications that just scroll in and out of view).

    Unfortunately I am using ARKit for this app so I need to use Metal. I've tried to build with OpenGLES but Xcode refuses to build, even if I have removed all ARKit elements from my scene.

    Edit:
    I've made a change to one of my windows, adding a new TMPro game object and it seems to also not be rendering now. Is there any known issues related to having too many TextMeshProUGUI objects in one scene? Perhaps it could also be the GameObject names, right now they are all default so I can find them in the Hierarchy view search easily.

    Edit 2:
    It seems like renaming all of my TextMeshProUGUI game objects has resolved the issue. I'm not sure if this means the issue was related to mechanim (since it worked fine on desktop & in the editor) or if it is an iPad related issue. Sorry I can't narrow it down more.

    Edit 3:
    OK, it seems to be occurring again! My test build was not using ARKit before but now that I'm using the ARCamera it seems to be having trouble again. I've been using a separate camera for UI, not sure if that could be related?

    Edit 4:
    Nevermind it happened again!

    Edit 5:
    Okay, it seems like it might be related to the font that I am using? I changed all my TMProUGUI components to use a different font and they all worked fine while the ones using the previous font still had problems. I'm going to try reimporting the font and recreating the font atlas. Could be related to using an .otf font? I am using FF Utility Pro which has been provided in .otf.
     
    Last edited: Feb 14, 2018
  4. Stephan_B

    Stephan_B

    Joined:
    Feb 26, 2017
    Posts:
    6,595
    Where in world space are those object? Coordinate wise?

    Take a look in the debug section of the Material Inspector of those text objects with the old font assigned vs. the new font assigned. Are you using the same shader? Also look at the Clip Rect values as seen below.

    upload_2018-2-14_11-37-6.png
     
  5. zubrjosh

    zubrjosh

    Joined:
    Oct 6, 2017
    Posts:
    7
    All objects are 0 on the Z I think, X and Y vary.

    Using Distance Field shader for all fonts. The same issue has risen again while using LiberationSans. UtilityProDebug.PNG
    Clip Rect values are identical to the ones in your picture.

    I'm going to try using default Unity text elements. Unfortunately there is a deadline looming and there are other areas of the project that need working on.
     
  6. Stephan_B

    Stephan_B

    Joined:
    Feb 26, 2017
    Posts:
    6,595
    I have a feeling that the animations might be leaving the material in a strange state which is why font assets work at first and then eventually stop.

    Another possibility... Do you have text objects that are both in overlay space or screen space and then some in worldspace? Ie. a mix of text object which share the same font asset and material? If so, create a material preset for the the worldspace text objects and assign it to them and then a different material preset for the other text object in screenspace overlay or camera.

    As usual, if none of these apply, I would encourage you to submit a bug report with the project attached. This always makes it much easier to identify the source of the behavior and provide a quick solution. If you do submit a bug report, please provide me with the Case #.
     
  7. zubrjosh

    zubrjosh

    Joined:
    Oct 6, 2017
    Posts:
    7
    Yes, we have some labels that are in world space, but they use regular TextMeshPro not UGUI.

    Using different materials seems to have solved the issue! Thanks for your help!
     
  8. Stephan_B

    Stephan_B

    Joined:
    Feb 26, 2017
    Posts:
    6,595
    The reason why this was happening is because you have (minimally) two text objects using the same material but requiring different ZTest settings. So the Screenspace Overlay objects and the Worldspace objects are fighting over this ZTest. Since the material can't be both at the same time, you end up with strange behaviors.