TextMesh Pro Version 1.4.1-Preview 1 with Dynamic SDF for Unity 2018.3 now available!

If you are migrating a project from the Legacy (non package manager versions) you will need to carefully read / follow the instruction in the following sticky post just below this one to migrate your project to the new package manager version of TextMesh Pro.

 

I'm still encountering the issue reported by others where text appears as blank or a white box on objects that are scaled up from 0. This is both in the case of uniform and non-uniform scaling. TextMesh Pro 1.4.1, Unity 2018.3.9f1

The code changes suggested earlier in the thread to fix this appear to already be there in my current version of TM Pro.

Any ideas?

 

Can you provide me with a simple repro project that would enable me to reproduce this behavior easily?

If it is easier, you can submit a bug report with the included project. Be sure to include the steps to reproduce and the Case # once you have it.

 

Will send the repro project via dropbox link in a just a bit.

 

Here is the repro project:
https://www.dropbox.com/s/vpk7u86lv31z7ae/TextMeshTest.zip?dl=0

Just press play and you'll see the text object scale down, then back up in a cycle. See that the text is no longer visible when scaled up.

 

@Stephan_B I think i've found a couple of bugs with the dynamic sdf support. I have a reproduction project that causes a crash. The same code worked fine on unity 2018.4.2f1 but crashes on the latest 2018.4.9f1 and any newer unity versions including 2019.2.5f1

Which to me suggests that there was a change with the unity side of things that broke this. Specifically something with
FontEngine.TryAddGlyphsToTexture()

Here is an image of what it looks like in unity 2018.4.2f1:



And this is the crash i get in 2018.4.9f1:

NullReferenceException: Object reference not set to an instance of an object

TMPro.TMP_FontAsset.TryAddCharacters (System.UInt32[] unicodes, System.UInt32[]& missingUnicodes) (at Library/PackageCache/com.unity.textmeshpro@1.4.1/Scripts/Runtime/TMP_FontAsset.cs:1093)

DynamicSDFTest.LoadFontAsset (UnityEngine.Font sourceFont, System.UInt32[] characters, System.UInt32[]& missingGlphs) (at Assets/Scripts/DynamicSDFTest.cs:76)

DynamicSDFTest.Start () (at Assets/Scripts/DynamicSDFTest.cs:33)

There is also a second bug with TryAddCharacters not setting the missing glyph array output. Which i have a workaround in the reproduction project for now.(this bug is in 2018.4.2f1 at least don't know if it effects newer versions or not)

Here is the download for the repro project: https://drive.google.com/file/d/1dOHd4_rzswiUDIaGWi46HvA8cMlRLv3u/view?usp=sharing

What i'm doing is building several font assets entirely in code, setting up fallback font assets, and populating the needed characters.Then using them on the tmp ugui object in the scene

 

I'll take a look at these tomorrow.

 

Hi @Stephan_B , are the different SDF generation modes documented somewhere? We have always used SDF16x, now I noticed there is the SDFAA which is really fast in comparison, and apparently was added for the dynamic font system. I was just wondering if there is any quality difference between them? Currently we are using just static fonts, so it probably makes sense to keep on using 16x generation, but nonetheless I'm still curious.

 

The SDF16 and SDF32 are very accurate but extremely slow in terms of generation. The SDFAA is not as accurate but fast enough to use for dynamic generation at runtime.

The lower accuracy could be noticeable on text displayed at 80 point size or greater if it has an outline or shadow. So for big stylized titles, I would continue to use SDF16 or SDF32 but for anything else use the new modes.

 

I posted an example of the quality difference in the previous page ( https://forum.unity.com/threads/ver...18-3-now-available.622420/page-4#post-4656209 ).

It's only noticeable in huge font sizes.

 

So many posts... forgot about that one. Thank you for referencing it again.

P.S. Like I mentioned in some other previous post (somewhere ) I do plan on further improving the SDFAA when I have time.

 

@Stephan_B Were you able to have a look at my repro project for the scaling issue?

 

Currently looking at it.

The issue is related to the end state of the scale where it ends up being zero.

Changing the following line to use a small value like 0.0001f will get around this issue.

testText.transform.DOScale(new Vector3(testText.transform.localScale.x, 0.0001f, 0.0001f), 0.09f).SetEase(Ease.InBack).OnComplete(() => testText.SetActive(false));

I will take a closer look to see if I can make the value of zero work.

Update
I was able to address the underlying issue where the original code will now behave as expected. The issue was related to the scale going negative due to the tweening.

 

Any chance to look at my issue yet?

 

Looking at it next (later tonight / tomorrow)

 

@Stephan_B Ok, great. Any chances you can post the necessary code changes to fix it?

 

I hate to bug you too much about it, but the bug i posted is a fairly critical blocking bug for us. Where we have been planning to get a release out by the end of the month. Have you had the chance to take a look at it yet?

 

My apologies for the delay in looking at your report. I finally got a chance to download your reproduction project and as it turns out, it is something that I have already addressed in the next release. The issue is / was an oversight on my part related to an optimization that made it into the editor which impacted the current release.

The solution to the issue is pretty simple and will require you make the following changes which I have already described in a the following thread.

I made the code changes in your reproduction project and got the following output instead of the error.



Please make those changes and let me know if you run into any other issue. As usual, I'll be monitoring the forum over the weekend.

P.S. These changes will be in the next package release which I am currently in the process of finalizing to release early next week.

 

@Stephan_B Will you will including the fix to the negative scale bug in an upcoming update? Any chance you can let me know what code changes are necessary in advance of the release?

 

That fix will be included in the release.

I did overcome the package publishing issue I ran into over the past few days (which I referenced in other posts). The plan is for one last day of testing on my end (tomorrow) and then pushing the new packages which will be version 1.5.0-preview.1 for Unity 2018.4 and 2.1.0-preview.1 for Unity 2019.x.

 

So are there any updates on the progress of the integration withUnity’s Addressables System? Having a simple and more reliable solution for dynamic text updates for any application is almost necessary since Unity claims anything published after 2019 should use the Addressables system!

 

What do you mean by "Having a simple and more reliable solution for dynamic text updates"?

The new Dynamic SDF system introduced in version 1.4.x combined with the added Multi Atlas Texture support added in 1.5.x should provide for all the flexibility needed to handle dynamic text updates.

 

The font atlastexture generated is only 4m（2048 X2048). On Android mobile phones, there is 16m in profiler. Do you know why? texture format converted to RBGA?

 

The Atlas Texture should remain 8 Bit Alpha ... check build compression / texture settings.

 

Question.
https://issuetracker.unity3d.com/is...when-entering-chinese-text-in-tmp-input-field
This issue says that it's fixed in the version 1.4.2 for 2018+ but there is no 1.4.2 in the package manager.
Changelogs does not says anything either. Where could we find this patch?

 

Use version 1.5.0-preview.8 with the latest version of 2018.4.

 

Is it possible that version 1.5.0-preview.8 uses NET 4.x System.Diagnostic.Contracts? If yes, it's breaking retrocompatibility with NET 3.5

 

I switched over to using Rider where I have noticed it is adding System.Diagnostic.Contracts ... which is annoying and should not be happening.

I will make sure those are removed in the next update. However, since .Net 3.5 was deprecated in 2018.4, we will all need to migrate to .Net 4.x for 2019.x.

 

I'm not familiar with the tech... I wonder if we could use dynamic font, is there any reason to NOT use it and use static font instead? It seems to be a lot more convenient to use. Specifically would it hurt performance on mobile?

 

Using a combination of static and dynamic font assets is the recommended workflow.

You would use static font assets where these would include all the known characters used in the project for any given language or groups of languages.

For user input / unknown characters, you would create dynamic font assets that would be assigned as fallback to your primary static font assets.

In terms of using dynamic font assets to handle user input at runtime, the performance is such that none of this would be noticeable by users.

See the following post and links along with the following updated videos.

 

So for example i want to use "NotoSansCJKjp-Medium" font, which weights 16mb. I create some static font with symbols from my app and as you said create the dynamic one for user input as a fallback. Did i get it right that i have to include in build my 16mb source font for that dynamic SDF font?

 

Yes. However, you can already create dynamic font assets at runtime. There should be several threads on the forum on how to do this. Here is one such thread.

Having said that...

I will be adding a new font asset type which will "Dynamic OS" where it will behave like any other dynamic font asset in the Editor. However, unlike Dynamic font assets where the referenced source font file is included in the build, it will not with Dynamic OS font assets.

When the font asset is first loaded on the target platform, TMP will get / cache the path and names of all font files on the platform and then provided it finds a font file matching the one referenced by the dynamic font asset, will use that font file as it source.

Just like the other font asset types, you will be able to assign Dynamic OS font assets as local fallbacks to another font asset or as global fallback. The order in which they appear in the local or global fallback list will determine which one gets used first.

If the source font file referenced by a dynamic OS font asset is not available on the target platform, it will be skipped. This will enable users to define a list of dynamic OS font assets for multiple target platforms.

A list of font files present on most major platforms is available from those companies. Most of these fonts are also available for download so you can import them in Unity to create dynamic OS font assets using them.

Using actual font assets as opposed to just some name reference, will enable users to define their Generation Settings and even tweak face metrics as needed to make sure these work well with any other font assets. Furthermore, this will ensure from a quality assurance point of view that the font file used in the editor will be the same and look the same as the one(s) on the target platforms.

Multi Atlas texture support will be available for Dynamic OS font assets as well thus enabling them to potentially handle every single glyph contained in those system font files.

I am trying to release the next preview releases of the TMP package within the next 7 to 10 days.

 

Great! When will you release these features? Can we get it in July?

 

Currently hoping to get these new releases out sometime next week.

 

Any update on the new release?

 

Trying to release it within the next few days.

 

Error occurs in 1.6.0-preview

Library/PackageCache/com.unity.textmeshpro@1.6.0-preview.1/Scripts/Runtime/TMP_FontAsset.cs(494,28): error CS0117: 'FontEngine' does not contain a definition for 'TryGetSystemFontReference'
Library/PackageCache/com.unity.textmeshpro@1.6.0-preview.1/Scripts/Runtime/TMP_FontAsset.cs(494,81): error CS0246: The type or namespace name 'FontReference' could not be found (are you missing a using directive or an assembly reference?)
Library/PackageCache/com.unity.textmeshpro@1.6.0-preview.1/Scripts/Runtime/TMP_FontAsset.cs(1054,67): error CS1503: Argument 2: cannot convert from 'string' to 'int'

 

I suspect that you are using an older version of Unity 2018.4. Some of the new features such as Dynamic OS Font Assets, require using some of the newer releases of 2018.4.

 

I'm using 2018.4.32. Those apis do not appear in the document. Are they undocumented apis?

 

Those are internal functions which landed in 2018.4.35.

 

Using Unity 2020.3.14f1 and TMP package 3.0.6 I get that warning every time I regenerate the atlas (and have to apply the workaround with the debug mode), should this be not something that is applied automatically by the "Update Atlas" dialog?

 

You should not be getting a warning as this should be handled automatically. Perhaps there is something going on with that font asset.

See if you get the same behavior with another font asset. If not, can you please provide me with the font asset in question?

 

Hi Stephan,
About the dynamic OS feature, this sounds great !

You said: "A list of font files present on most major platforms is available from those companies. Most of these fonts are also available for download so you can import them in Unity to create dynamic OS font assets using them."

Do you have an idea where to find this for Android and iOS ?
Currently I'm missing Arabic and CJK glyphs.

Thanks for your good work

 

Dynamic OS support is already available in the latest preview release which is version 1.6.0-preview.1 for Unity 2018.4, version 2.2.0-preview.1 for Unity 2019.4 and version 3.2.0-pre.1 for Unity 2020 or newer.

 

Yes I already got it.
I managed to find fonts on Android by downloading the content of the system/font folder of my device.
But I don't find the fonts for iOS.
Any idea where to find them ?

 

https://developer.apple.com/fonts/system-fonts/

 

Thank you very much @Stephan_B , I found what I needed

 

Hi, is there a way to update font asset asynchronously during runtime? I found that when I set the Render Mode to SDF32 (I need very accurate outlines), and there were some characters needed to be added into font asset dynamically. The generation process caused the entire game to be halted for a few seconds.

 

The SDF16 and SDF32 modes are very accurate but much too slow for dynamic use.

Any particular reason why you are not using static font assets that are prepopulated with the needed characters using either of these raster modes?

 

hi ,
Noto CJK adds lot of size to the project , is there any other option which i can opt for ?
thanks