TextMesh Pro Version 1.5.1, 2.1.1 & 3.0.1 - Now Available! for Testing!

Can you provide the steps to reproduce this null reference exception?

In terms of issuing a warning when a character is not found in the primary font asset, this is something I can add. Currently, it provide a warning when the character is not found in the primary or any of its potential fallbacks which includes any fallbacks assigned in the TMP Settings including the Default Font Asset which is LiberationSans SDF.

 

Most word processors like MS Word or Google Docs do not underline isolated spaces. As such TMP mirrors that behavior.

There is also the issue of spaces at the end of a line which also never get underlined which would become an issue if that behavior was changed.

What is the use case for <u> </u> and having the underline visible?

In MS Word, the Tab character can be underlined but not in TMP at this point.

I am not opposed to adding special functionality to support this. This will require figuring out how we want to handle spaces at the end of a line as you typically do not want those underlined.

At the same time, I would plan on revisiting how sequences of spaces are treated at the end of line in regards to whether or not they contribute to alignment or preferred width.

However, before doing anything, I would like to get a better understanding of the use case to make sure the solution fits the needs.

 

If underlining whitespaces are not going to be supported I wouldn't be mad. In my case I wanted the text have placeholders, e.g. "insert _____ here". I didn't want to use simple underscores because they would not create a continuous line (at least not with the font I'm using).

 

Like I said, I am not opposed to adding some functionality to support this type of use case which I think can be common.

Maybe I can add another attribute to the underline tag that would provide control over what happens with white spaces.

<u ignorewhitespaces=false> where in this case, white spaces would be underlined. Since tags are lowercase, I do not really like such a long attribute "ignorewhitespaces" so maybe we can come up with something better. In the future tag will be case insensitive so users could use <u IgnoreWhiteSpaces="false"> but still that is a long tag.

There are the other two cases where if the line wraps where you have trailing white spaces at the end of the line. Typically, we don't want those to be underlined. Although when using justified text you might.

Then we have the case like "This is a line of text" where spaces between words are not underlined. Using <u IgnoreWhiteSpaces="true"> could be this behavior. Not specifying the attribute would be the default current behavior.

Alternatively, the attribute could be a value instead of bool where we would have <u whitespaces="default"> <u whitespaces="exclude"> <u whitespaces="include">? Maybe we can come up with something more descriptive / better than "include and exclude".

Thoughts?

 

Ooh cool I didn't know about the default fallbacks in the TMP Settings.

Regarding the repro steps, it's really just what I mentionned in my last post:
- Create an empty project
- Generate a font asset (based on any font) with only the char "a" in it
- Remove all other font assets from the project (default fallback fonts)
- Add a TextMeshProUGUI in the scene, set its text to "ab"
- You should immediately have nullref popping, even out of runtime, when on select the object. Other nullrefs when starting the game, selecting the object, modifying its text, trying to calculate its preferred size...
(Using TMP 2.0.1 in Unity 2019.4.1f1 btw, but we already had this issue with a former version of Unity.)

Because of the NullRefs, I don't have any warning regarding the missing chars.

 

Please use version 2.1.0 which was released today.

You should no longer be getting null refs using the steps you described above.

For instance, if your primary font asset only contains the character "A" and you type "AB", assuming you didn't add any fallback in the TMP Settings, the "B" will come from LiberationSans which is the default font asset assigned in the TMP Settings. If you were to set the default font asset to null, TMP would check for the missing glyph symbol which in this case is not available and therefore you would get a space. No errors.

 

Damn, finding a good name - the biggest problem in programming! I would probably go with <u whitespaces="all"> and <u whitespaces="none"> to make it a bit shorter. I assume the default case is actually the one 99% go for, so the length of the attribute won't matter that much.

 

I just tried the last version, I'm still getting errors, but not the same:

Code (CSharp):

1. NullReferenceException: Object reference not set to an instance of an object
2. TMPro.TextMeshProUGUI.SetArraySizes (TMPro.TMP_Text+UnicodeChar[] unicodeChars) (at Library/PackageCache/com.unity.textmeshpro@2.1.0/Scripts/Runtime/TMPro_UGUI_Private.cs:1245)
3. TMPro.TMP_Text.ParseInputText () (at Library/PackageCache/com.unity.textmeshpro@2.1.0/Scripts/Runtime/TMP_Text.cs:1893)
4. TMPro.TextMeshProUGUI.OnPreRenderCanvas () (at Library/PackageCache/com.unity.textmeshpro@2.1.0/Scripts/Runtime/TMPro_UGUI_Private.cs:1608)
5. TMPro.TextMeshProUGUI.Rebuild (UnityEngine.UI.CanvasUpdate update) (at Library/PackageCache/com.unity.textmeshpro@2.1.0/Scripts/Runtime/TextMeshProUGUI.cs:224)
6. UnityEngine.UI.CanvasUpdateRegistry.PerformUpdate () (at C:/Program Files/Unity/Hub/Editor/2019.4.1f1/Editor/Data/Resources/PackageManager/BuiltInPackages/com.unity.ugui/Runtime/UI/Core/CanvasUpdateRegistry.cs:210)
7. UnityEngine.Canvas:SendWillRenderCanvases()
8.  
9. NullReferenceException: Object reference not set to an instance of an object
10. TMPro.TMP_Text.FillCharacterVertexBuffers (System.Int32 i, System.Int32 index_X4) (at Library/PackageCache/com.unity.textmeshpro@2.1.0/Scripts/Runtime/TMP_Text.cs:6727)
11. TMPro.TextMeshProUGUI.GenerateTextMesh () (at Library/PackageCache/com.unity.textmeshpro@2.1.0/Scripts/Runtime/TMPro_UGUI_Private.cs:3888)
12. TMPro.TextMeshProUGUI.OnPreRenderCanvas () (at Library/PackageCache/com.unity.textmeshpro@2.1.0/Scripts/Runtime/TMPro_UGUI_Private.cs:1640)
13. TMPro.TextMeshProUGUI.Rebuild (UnityEngine.UI.CanvasUpdate update) (at Library/PackageCache/com.unity.textmeshpro@2.1.0/Scripts/Runtime/TextMeshProUGUI.cs:224)
14. UnityEngine.UI.CanvasUpdateRegistry.PerformUpdate () (at C:/Program Files/Unity/Hub/Editor/2019.4.1f1/Editor/Data/Resources/PackageManager/BuiltInPackages/com.unity.ugui/Runtime/UI/Core/CanvasUpdateRegistry.cs:210)
15. UnityEngine.Canvas:SendWillRenderCanvases()
16.  

I have tried recreating my font with only 'a' in it, but I still get those errors. I could try again to repro it from another new empty project and send it to you if you don't have repro on your side, but I really didn't do more than my repro steps to get this result.

 

I looked at this more closely and I am able to reproduce the behavior.

The error occurs because the only font asset available only contains the letter "A" and there are no fallbacks available and no default font asset assigned either so we can't even display a space character.

I did add one additional layer where if the space character is not available anywhere, the requested character will be replaced by the End of Text \u0003 character which is a synthesized character that is always available. A warning will also be issued if you have not disabled warning in the TMP Settings.

This fix will be in the next release which will be version 1.5.1 for Unity 2018.4, version 2.1.1 for Unity 2019.x and version 3.0.1 for Unity 2020.x.

Having said all of that, I would always make sure that you have a default font asset assigned in the TMP Settings. I would also make sure that I always have an empty dynamic fallback assigned to it as well. This way, it will always be possible to add characters like space as needed.

 

Great!
I only tried 2.1.0 in my empty test project where my test font didn't have a space indeed, but there's definitely a space in the real project, so 2.1.0 should be enough actually

Thanks a lot for the quick answers and great support, really appreciated.

 

Hello, Help with Universal Render Pipeline,

Do your TextMeshPro support Universal Render Pipeline? Do you have surface shader that supports URP?

 

There is a set of URP / HDRP Shader Graph compatible shaders that will be coming.

ETA is still about 30 - 60 days but will do my best to get those out as soon as possible.

 

Hi @Stephan_B,
Great work on dynamic atlases, what if i start a dynamic atlas for icons, then once im happy with it can save that dynamic atlas in editor with all the icons as static atlas?
Is that possible? if not can you please add this feature

 

Font Asset can be switched freely from dynamic to static.

 

and they will preserve all the glyphs added in dynamic atlas (in editor) ?

 

Yes.

The main difference is that when a font asset is static it is not possible to add new characters and glyphs. As such TMP won't even try to load the font or do anything which is more efficient.

By contrast when the font asset is dynamic, when a character not present in the font asset is requested, TMP will open the font file to go look for this character to try to add it.

Again, font asset can be switched back and forth between static and dynamic in the Editor.

 

Sorry for i'm not being clear and thanks for being patient with me.

I understand the difference between dynamic and static.
What i want is:

I added a dynamic atlas so i can keep adding font-awesome icons and atlas will keep populating in editor.
once all icons added automatically in atlas, then i press a button which convert it to static atlas including persisting all the icons that were added in dynamic atlas.

This way i save time by manually generating a static atlas with all the icons i need

 

Yes. It is fine to run full dynamic with Multi Atlas texture enabled during the development phase and then as some point to convert those dynamic font asset to static.

In the editor changes to dynamic font assets are persistent while at runtime dynamic font assets always reset to their default state when the build was created.

See the following videos which cover the above workflows.

 

What is new in TMPro 3.0 vs TMPro 2.1?

EDIT: I guess nothing but 3.0 is compatible with 2020.1 and 2.1 is for 2019.3.

 

Correct.

Version 1.5.x is for Unity 2018.4, version 2.1.x for Unity 2019.x and version 3.x for Unity 2020.x.

 

@Stephan_B I've found some odd behaviour with the inputfield (prev14). In the mode "multi Line submit" after writing some Text pressing enter does nothing the first two times. The third time around the text gets cleared and a newline gets inserted leaving the inputfield in a fake empty state. This is easily reproducable. Just take the default tmpro Input field in multi Line submit mode with no further changes, write some text and then try pressing enter.

 

See if you get the same behavior with the non preview version.

 

Just tested it, still the same behaviour

 

Thanks. I'll try taking a look tomorrow.

What input system are you using?

 

I'm currently still using the old one

 

We're using version 2.1.1 and keep getting errors in empty dynamic fonts
we get a lot of
MissingReferenceException: The variable m_AtlasTextures of TMP_FontAsset doesn't exist anymore.
and

Code (CSharp):

1. NullReferenceException: Object reference not set to an instance of an object
2. TMPro.TextMeshProUGUI.UpdateSDFScale (System.Single scaleDelta) (at Library/PackageCache/com.unity.textmeshpro@2.1.1/Scripts/Runtime/TMPro_UGUI_Private.cs:4587)

Also, is there a chance we can get an option to disable persistency in editor?

 

How are you emptying / resetting those dynamic font assets?

Can you provide more insight on why you want changes to dynamic font assets not to be persistent in the Editor?

 

we have a lot of different characters and only some translations need them thus we don't want to have them pregenerated, just generated dynamic And discarding changed fonts disturbs our version control workflow

These errors appear after we created a font by right clicking on a ttf and choosing create font asset, then setting it to dynamic with multi atlas

 

By default the font assets are dynamic. Multi Atlas is disabled but you should not be having to change to Dynamic.

The error message you posted, is coming from a text object and not from a font asset so something else is at play here.

Are you able to reliably reproduce these errors? Can you submit a bug report with the project for me to look at?

 

Version of Unity:
2020.1.1f1

Version of TMP:
3.0.1

Hi @Stephan_B,
Problem: I create an empty project with input field, specify some value in the input field with a characterLimit, for example 20. I make a build (Android, IOS) when the maximum value of characters is reached, I press the Return button on the keyboard, the keyboard does not close. How can I solve this problem?

 

Is there a way now？

 

@StephenB am I correct that after packing we would know which characters are missing? Could we change the process to output this before rendering the glyphs? Packing is fast, rendering can take quite some time and I am currently wasting so much time trying to get a SDF texture out of Jetbrains Mono

and finding the Atlas Resolution sufficiently large to encorporate all text characters is really time consuming.

I just waited 10 minutes to find out with 1024x1024 half of my alphabet is missing. And yes, I know, I could have known that this will never fit.

 

The above has been requested previously and makes total sense. As soon as I have time, I will make the change where the packing results are output once packing is done thus giving you the opportunity to cancel the process early.

It was also request to display the potential packing (rects) along with a packing percentage. The packing percentage is easily doable. Not sure about the Rects.

P.S. In the latest Unity releases, I did add multi threading back for the SDF over sample modes. So that should speed up the process.

 

Noticed similar behaviour occurring on version 3.0.1

Multi Line Submit appears to insert a new line on Enter, leaving the input field in a fake empty state that can't be cleared with input.text = string.Empty (or similar) — so far I've found no solution for fixing this.

 

See the following post.

 

I am trying to reproduce this behavior without success.

What are the steps to reproduce this?

Are you able to reproduce this in the Editor or does this only happen on some platform?

 

Thank you so kindly much for the swift response!

Having run a few tests both in-editor and for Windows — it appears this only occurs when the OnFocus - Select All boolean is deselected (false) under Control Settings in the TextMeshPro - Input Field.

Wasn't able to determine if this was this intended effect for OnFocus - Select All, but can happily confirm this solution fixes the issue for me.

 

What is the current workflow for dynamic font assets w/ version control?

We want to distribute our game with empty dynamic font assets, and everytime a dev engages in playmode, the changes (font assets) will appear on git. It's a big bother for the team to weed out through the TMP changes. How do you deal with it?

 

Before creating the production build, you can Reset those dynamic font assets using the context menu.

If you have some build automation, you can also use the following:

Code (csharp):

1.  
2. /// <summary>
3. /// Clears font asset data including the glyph and character tables and textures.
4. /// Function might be changed to Internal and only used in tests.
5. /// </summary>
6. /// <param name="setAtlasSizeToZero">Will set the atlas texture size to zero width and height if true.</param>
7. public void ClearFontAssetData(bool setAtlasSizeToZero = false)
8.  

Most likely you would want to set the atlas size to zero.

 

For some reason, I'm no longer able to update font Atlas Textures on macOS Catalina. When I click the button in the Inspector, nothing happens.

When I go to examine the Atlas Material, I get the following console warning:

Code (csharp):

1. Metal: Fragment shader missing texture binding at index 0 (_MainTex / TextMeshPro/Distance Field)

I have zero clue as to what's going on. I have not updated Unity, or Catalina or anything at all. It just broke out of the blue.

EDIT: Hah! Never mind, that Metal shader warning was a complete red herring. It turn out to be some bizarre issue with Unity Editor UI settings. Got it working now.

 

Hi Stephan_B,
can i Project/Decal a Textmesh Pro text onto a 3D model ?
if not , any further plan to support this ?

 

Is there any way to increase the character limit for the link IDs? I'm using the link component for tooltips in a lengthy narrative game, and it'd be a lot easier to just grab the tooltip content straight from the link ID.

 

The Link ID should be a unique ID. These ID can then be used as Keys in a Dictionary to quickly looked up their associated text of whatever length you need.

Since the text parser has to parse / read these IDs as well as compute a hash code for each of them, the longer they are the more performance overhead. As such, these should be kept short and as simple unique IDs.

To be more specific, as your code retrieves a Link ID, you would then do a simple dictionary lookup to retrieve the lengthy tool tip text.

Using short Link IDs would be most efficient from a text parsing / processing point of view while using a dictionary to lookup the text for these ID be also very efficient without limiting how long the tooltip text associated which each ID would be.

 

Thank you! I'm still very new to programming, so this is very useful!

 

I want to use TextMeshPro to make the text of the name on the character's head in Chinese. I found that the font will not be updated after FontAtlas is full. Is there a way to delete unused characters on the screen during runtime, leaving free FontAtlas for adding new characters?

 

I presume that you have a primary font asset that is static that contains all the known text used in the project as well as a dynamic fallback font asset assigned to this primary to handle all unknown characters coming from user input or other runtime sources. Is that the case? If not, how do you have this setup?

To handle a growing number of glyphs and characters, you can enable "Multi Atlas Texture" support on the fallback font asset. This feature enables additional atlas textures to be create as needed to handle the additional glyphs and characters.

P.S. Please post these types of question in the main section of the forum as this will make them easier to find for other. This thread should be just for specific issues related to the latest release.

 

Thank you for your reply, but using "Multi Atlas Texture" will not support dynamic batching and will increase a lot of memory. It would be great if TextMeshPro could use Unity's native dynamic fonts!

 

Currently, if a text object uses 4 atlas textures, the number of draw calls will be 4 or 1 per atlas textures. If 10 text objects used the same 4 atlas textures, these will dynamically batch with each other while following the batching rules for the Mesh Renderer and Canvas Renderer / Canvas system.

Multi Atlas textures are contained in an array of textures where I plan on releasing updates shaders that will make use of Texture Arrays at which point these will only result in 1 draw call regardless of the number of texture in this array. Texture Array is not supported on older mobile devices but these are gradually being phased out of the market.

In terms of the memory footprint, whether you use 1 larger texture or a few smaller ones, the memory foot print is the same. Ie. The memory footprint of (1) 1024 x 1024 is 1MB which is the same as (4) 512 x 512 which is 256kb X 4 or 1MB. From a rendering point of view, it is more efficient to read into smaller texture than in larger textures.

So the main different until support for Texture Array is added, is the increase number of draw calls. On this subject, unless you go back to an iPhone 3GS or equivalent, there is no real performance difference between 1, 25 or even more than 50 draw calls on most mobile devices. Excessive draw calls should be avoided but whether your text results in 1, 10 or 20 draw calls, the difference won't be noticeable even on old mobile devices.

Although it is more efficient to read from smaller textures, I would not necessarily choose to use lots of 256 x 256 over fewer 512 x 512 or 1024 x 1024. The texture ready performance difference is much more noticeable between 512 x 512 and 2048 x 2048 or larger textures. Ie. If you expect a lot of user input to be handled by dynamic font assets, a size of 512 x 512 or 1024 x 1024 should be fine unless you are using a large sampling point size.

Note: Dynamic font assets atlas textures have a size of 0 when they are created and only resized to their size setting when the first glyph is added to them.

In the editor, changes to dynamic font assets are persistent but not at runtime, this means these dynamic font asset will reset to their default size when the project build was created. If these were reset / cleared before creating the final build, their size will be zero otherwise, they will always reset to whatever state they were in when the build was created. It is recommended to always reset dynamic font asset when creating your build.

BTW: I am considering adding a setting in the TMP Settings to control whether or not these would automatically be reset when creating a build.

P.S.S. Although I feel the TMP dynamic system is a better option than the legacy text system, I am still going to be looking for ways to further improve upon it. For instance, I will be adding support for Dynamic OS font assets, I would like to add some type of atlas (less) system where similar to the multi atlas system where new altas textures are created on demand, instead of these texture being per font asset, they would be for all font assets. Please keep on providing feedback

 

Hi @Stephan_B - we're currently using Unity 2019.4 but the verified Textmesh Pro version is 2.0.1. Do you know when 2.1.1 will be verified for 2019.4? Or would you recommend that we just update now?

Thanks

 

Version 2.1.1 is verified and was added as the default package version of TMP in 2019.4.10f1. As such, it would not show up as verified in prior version of 2019.4.

FYI: Version 2.1.2 should be released soon which will also be verified.