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 material being reset in Editor

Discussion in 'UGUI & TextMesh Pro' started by Menion-Leah, Apr 2, 2019.

  1. Menion-Leah

    Menion-Leah

    Joined:
    Nov 5, 2014
    Posts:
    189
    I'm facing a recurring issue since I started using TextMesh Pro (first in-engine version).
    Basically, some TextMeshProUGUI components lose their Material Preset setting every time I open their containing scene in the editor.

    If I save the correctly configured scene, I switch to another and then back to the first one, those TMP components reset their Material Preset to the default one. If I save the scene immediately after opening it, I can see that the .unity file differs this way, from:

    to:


    I initially thought it was related to GameObjects being loaded from AssetBundles, but currently it's not limited to them; it looks like it worsened a little bit by switching to the new Prefab System, but it could just be a coincidence.

    It only happens when those GameObjects are active in the scene.

    I double checked the whole solution and I don't have any script that use ExecuteInEditMode, ExecuteAlways or runInEditMode.

    FileId and GUID referred in the first (correct) snippet are easily traceable to the desired FontAsset - Font Material; FileId in the second snippet (automatically set by Unity Editor when opening the scene) does not match any Font Material in the project.

    I'm currently using Unity 2018.3.11f1.

    Does anybody ever experience a similar behavior?
     
    Last edited: Apr 3, 2019
  2. Stephan_B

    Stephan_B

    Joined:
    Feb 26, 2017
    Posts:
    6,595
    Can you provide me with a Repro project for me to look at?
     
  3. Menion-Leah

    Menion-Leah

    Joined:
    Nov 5, 2014
    Posts:
    189
    Hi Stephan,

    I'm really out of time in the upcoming days to be able to put together a repro, but I'll try to provide you with a test project as soon as I can.

    Thank you
     
  4. Stephan_B

    Stephan_B

    Joined:
    Feb 26, 2017
    Posts:
    6,595
    Most likely the issue is bundle related.

    Just for testing, make the following changes in the LoadFontAsset() function in both TMPro_Private.cs and TMPro_UGUI_Private.cs.

    upload_2019-4-3_12-23-36.png

    upload_2019-4-3_12-23-59.png

    I suspect the atlas texture coming in from the bundle is a different instance and not the same as the one from the font asset itself.

    This change will have other adverse consequences so this is just for testing to see if this is what might be causing the material preset getting reset. Make sure you revert these changes afterwards.

    If that doesn't work then, I'll wait for your test project.
     
    Last edited: Apr 3, 2019
  5. Menion-Leah

    Menion-Leah

    Joined:
    Nov 5, 2014
    Posts:
    189
    Thanks for your advice.

    I suppose in TMPro_UGUI_Private.cs you meant to replace the line 552; unfortunately, the subsequent lines are not called when this material replacement takes place (I tried logging, it doesn't enter in the if body nor in any previous if, but material is replaced anyway). I also tried changing line 300, in "OnValidate()", same results.

    I also updated TMPro from 1.3.0 to 1.4.0, nothing changed.

    I also discovered that this bug happens only in two contexts:
    • when scene is opened in the editor, and the GO is active
    • when the GO containing the TextMeshProUGUI script is active self but not in its hierarchy, and the disabled ancestor gets activated

    If this text-related GO is inactive itself and it gets activated (by clicking on the checkmark next to its name), no material replacement happens.
     
  6. Menion-Leah

    Menion-Leah

    Joined:
    Nov 5, 2014
    Posts:
    189
    I found the culprit: of course it wasn't TextMesh Pro, so sorry for wasting your time.. but thanks, without your advice I would have never been able to spot it.

    Basically, I wasn't aware that if you inherit from Button your MonoBehaviour's Awake will be called also in the editor.
    What happened was that my custom buttons were keeping track of initial material assigned to their label (in order to replace it when needed), and they did this assignment during Awake.
    Reading from .fontMaterial triggered GetMaterial(), and there a new material instance was created (line 757).
     
  7. Stephan_B

    Stephan_B

    Joined:
    Feb 26, 2017
    Posts:
    6,595
    Glad you were able to identify the source of the issue.

    I have had many users over the years get tripped up by the fact that accessing Renderer.material results in an instance of the material being returned whereas accessing Renderer.sharedMaterial does not. So in keeping with this established convention in Unity, accessing the .fontMaterial vs .fontSharedMaterial results in the same behavior which is certainly not always obvious
     
    Menion-Leah likes this.