TextMesh Pro Text Mesh Pro Font Asset keeps auto-changing

@Stephan_B Our Text Mesh Pro Font Assets keep showing up as changed in our source control. No one is touching the assets nor any TMP settings. It always has something to do with the "UNITY_UI_CLIP_RECT" shader keyword being added or removed. If we accept the change one way, it ends up eventually showing as changed back the other way.

What is causing this? What can we do to prevent it?

Thanks!

 

This is not set specifically by TextMesh Pro and most likely the result of the Canvas / UI system. For this shader keyword to change, I would assume a 2D RectMask is being enabled and disabled which results in this change.

What version of Unity are you using? I would suggest testing in Unity 2017.1 and 2017.2 to see if the behavior persists.

 

We have been seeing this at least since in 2017.2 as well as 2017.2p1.

 

This behavior is the result of a change in 2017.2 where the 2D RectMask now uses a shader keyword. This is done by the Canvas batching system and as such would affect all materials.

As Unity batches these materials, it is setting and un-setting this keyword and depending on the order of these batches, it may end up where the last batch sets or unsets the keyword. Ie. this will appear to be random.

This behavior also affects all materials used by the canvas. Since the UI Default material is an instance which does not live in a user project, you are not seeing this behavior. But if you were to assign a specific material to any object or use a persistent asset like a TMP Material Preset, then you will see this behavior.

Since this behavior will affect anything that uses a material that is persistent in the project (not only TextMesh Pro) I would suggest submitting a bug report on this. Please post the case number.

Hopefully, the UI and / or Graphics team can figure out an alternative way of handling this which doesn't result in dirtying persistent materials in the project when using a 2D RectMask.

 

Thank you for the explanation! Bug report submitted with test project.

Case 967024

I hope you can help speed up the development of a solution! It's been causing crazy merge conflicts for us in source control and we don't want to ignore random materials that could have valid changes as well.

 

Same problem here.

 

I'm getting this too.

 

Just an update from Unity "We have fixed this problem and it should not appear in the latest version (2018.1.0b8)."

I requested if a backport is possible since we are in no position to move to 2018 beta and they replied with this

"After talking with our developers, a backport for 2017.2 and 2017.3 is possible. We will let you know when the fix reaches a backport release "

Hopefully it'll show up soon!

 

Hooray! We've been hit by this as well, when we have one scene that uses a clipping rect and another that doesn't.

 

This is fixed in 2018.1 for certain. I believe this is also the case in the latest release / patch of 2017.3.

What version of Unity are you using?

 

I am using 2017.2.0p4. Please backport the fix to 2017.2 (or 2017.3) .

 

I have asked internally to see what the plans are in regards to a backport on this behavior.

This might be on a low priority (in terms of backport) given this is just an annoyance in terms of source control and not a breaking bug per say. But like I said it is an annoyance at any rate.

 

How about LTS Release 2017.4.0f1?

 

It is my understand that the fix for this will be back ported down to 2017.2 and 2017.3. Not sure when the change will land but keep looking for it in a subsequent patch for those.

 

For what it's worth... the fix still doesn't appear to be in 2017.4.2.

It seems the target audience for the LTS branch (serious dev teams) are the particular target audience annoyed by this bug, but yet no love.

 

I'll ask around internally to get an update on this.

 

I'd really like to see this fixed also. It consumes a lot of time, constantly checking diffs. I'm on 2017.4.2 as well.

 

Having it in 2017.4.2f2.
Not seeing it in the latest patch.

I hope it will be implemented in a future patch of 2017.4.

 

Hey Stephan, another LTS release and still no mention of this patch. Any feedback internally? Getting kinda silly now.

 

I have asked again internally. Will provide update as soon as I get an answer.

 

We just upgraded to 2017.4.2f2 and are pretty disappointed by this bug.

We have a team of a dozen designers that do regular prefab work and now their git checkins are littered with these thrashes. We had tried asking the team not to check in these specific types of changes, but when you're a non-technical person already intimidated by git, it is really easy to accidentally screw up a checkin and loose work.

The UI system should not be modifying assets from the project when in play mode.

 

FWIW this is our biggest day-to-day annoyance. We're anxiously waiting for a backport.

 

So um... I don't want to prematurely put away the pitchforks yet, but I pulled 2017.4.4f1 and I think maybe this is fixed there.

I still don't see this particular issue mentioned in the patch notes for 2017.4.x, but I stopped and started our project maybe 10 times this afternoon and didn't receive any squirrely diffs in my font assets.

Anyone else noticing that?

 

Honestly i'm not sure why it took so long to get out. but i'm looking at our internal dev branch code base and the latest release 17.4.4f1 should have the proper fix included.

 

As per @phil-Unity's feedback, it appears fine to store the pitchforks back in the shed in this case

 

I'm using Unity 2020.2.1f1 and I'm having this issue. However, instead of one line, GitHub tells me that the diff on my font asset is so large that it won't display it by default. I've committed it once thinking it was because I updated Unity, but it happened again. Anything that can be done to resolve this?

 

What are you seeing specifically?

 

If the change is that large it sounds like the asset content is changing, like are you sure it's not just a dynamic font asset that's getting new glyphs added to the asset?

 

@Stephan_B It looks like a variable called

_typelessdata

is being constantly autochanged. I had discarded Unity's previous attempt at autochanging, but when Unity booted up again today, it changed it again (tho I don't know if it changed it on load, or if it changed it after I changed the two selected files in the screenshot).

So the autochanges seem to consist of some random position / size changes, and the majority of it is this big huge change the

_typelessdata

variable.



Though come to think of it, Unity has made some other autochanges recently that were really annoying. I have a canvas meant to just show a number on the screen. For some reason, the default causes it to display a warning. So naturally I changed its setting to just "TexCoord1" so that the warning goes away. I saved it and committed the change. Next time I change that scene and save it, GitHub reports that the value was changed back to the invalid one. So after a while of discarding that change over and over again, I gave up and decided to just let it stay at its invalid value that it kept insisting on shoving in there. And it's been fine since. It doesn't seem to cause any bugs, and it hasn't been randomly changing values constantly.



However this TextMesh Pro autochange thing is a different animal. I've committed this autochange already, but it autochanged it again for seemingly random reasons. I feel like it's going to keep autochanging no matter how many times I commit it. I think I first saw this error back in September 2020.

 

@tessellation thats a good question. I would say no, because the font is one I downloaded from the internet and then unzipped and pasted into my directory. So unless there's something going on that I'm aware of, I don't think so.



Also I just realized that this is happening only with the WorkSans font, and not the Stonicorn font. The only difference I can think of is that I'm using WorkSans to display text, but I'm not using the Stonicorn font for anything currently.
Coincidentally, I'm using the WorkSans font in a Text right under the Canvas that is also having autochanging values.

 

This _typelessdata should be the atlas texture data. I

Is your font asset static or dynamic? Can you post an image of the font asset inspector?

Can you confirm that you are using version 3.0.3 of the TMP package?

Ignore this warning It was implemented a long time ago.

 

So I found a consistent way to make it autochange the file (after discarding the changes of course):
1. Click into GitHub
2. Click into Unity
3. Click back into GitHub
4. Click back into Unity
5. CTRL+S in Unity
6. Switch back to GitHub, and the autochanges will show up

@Stephan_B I changed the font asset in question from Dynamic to Static, and now, after committing the autochange once for the final time, I can't get it to autochange using the above described method. Thanks for your helped!

I did get this message tho when changing it to Static, which I assume I can safely ignore:

 

Changing the Font Asset from Dynamic to Static will result in silencing those changes but it will also prevent new glyphs from being added to the atlas texture which is the whole purpose of dynamic font assets.

Dynamic Font Assets will change as new characters and glyphs are added to them in the editor. That is their purpose. Static font assets are static.

 

I dont plan on adding glyphs to it, so it works. But if I were, what would the solution be?

 

Ok, but why do we need to sync this "dynamic" font atlas? That has no sense. And we cannot easily ignore it through .gitignore because this texture is a sub-asset of the font asset.
I would prefer to have Player behavior when the dynamic atlas is truly dynamic and generated at runtime, so that texture is created and lives until Editor closes.

Is there really no way to ignore texture atlas changes?

 

My workaround is to create an empty dynamic font atlas, then set up my version control to ignore future changes to the file. If I need to edit the font asset, I

* Un-ignore the file
* Revert changes to the file (making the font atlas empty again)
* Make the desired changes
* Commit the desired changes, without committing any dynamic data because the font atlas is still empty
* Ignore the file again

It's really messy and awkward but it works. I agree a better solution is needed for version control.

 

You could vote here
https://forum.unity.com/threads/tmp...anges-in-source-control.1227831/#post-7826655

 

I hate to revive old threads but I too think this is extremely annoying.

 

This not only annoying actually created a conflict and everything looks messed up.

The file 'Assets/TextMesh Pro/Examples & Extras/Resources/Fonts & Materials/Electronic Highway Sign SDF.asset' seems to have merge conflicts. Please open it in a text editor and fix the merge

 

There is a way to fix this:
https://forum.unity.com/threads/tmp...anges-in-source-control.1227831/#post-8935509