Official Future of Text at Unity

Thanks for the update, I saw this in the beta changelog; New 2022.2.0b13 - TextMeshPro: Added support for Color Glyphs and extracting OpenType font features.
This sounds like a pretty big deal to me (and a great new milestone), am I understanding it right, that I can use color font icons now?

 

Does this mean that we will eventually not need the TMP package? Where will the 3D Object > Text - TextMeshPro object go?

I am kind of concerned about this. I know in UIToolkit, line-height and other text features are still not implemented. Is there any timetable when these will be put in? Line-height is extremely important. Everything else from word spacing to paragraph spacing is already implemented.

Thanks for understanding

 

Thanks for the update. I am a little confused - is the plan for TextMesh Pro to be deprecated? If so, when will the replacement be available and what should I do in the meantime?

I've been waiting for over a year for full kerning support to be fully added to TextMesh Pro so I can switch my project to TMP. It seems like this feature is finally in the pipeline as per spakment's post but now I'm wondering if I shouldn't be trying to switch to TMP anymore. Thanks.

 

Do I understand this correctly: Old Text system is being deprecated. TextMeshPro is basically being made into TextCore, so it's more or less a renaming of sorts? Using tags and the workflow of using sprites and such is being kept? I am currently in the middle of creating a deep dive tutorial series for TextMeshPro (Christina Creates Games) and am wondering how this might change my plans going forward.

Did a bit of googling the day after asking this: It looks like it really is somewhat of a renaming to me. This was the most helpful thread I could find about it: https://forum.unity.com/threads/feedback-wanted-new-text-engine.1007585/ TextCore is being called a "Direct adaption" in that thread and it looks like the features are going to be the same to me.

 

Hi as @Mahunreah asked above we are also confused

please clarify
--- A new system called TextCore will be added for 2021 an higher
--- TextMeshPro will be deprecated
--- legacy Text will be deprecated
--- You are also now working on replacing the legacy text backend

you referenced 2021, please be more specific as 2021.1.0 = api 11.0.0 and higher ?

when you say "legacy Text" are you talking about Unity - Manual: Text ?

Please can you give more clear info about BIRP built-In pipeline

 

Hi @DEEnvironment I did a bit of searching into this. I think you might find a few answers in this thread on the forums: https://forum.unity.com/threads/feedback-wanted-new-text-engine.1007585/

 

Thank you for clearing it up !

 

When are the TMP preview package going to come out of preview i.e. 3.2 and 4.0?

 

@benoitd_unity
thanks for the reply

currently we have many assets that use legacy Text system in demo scenes as we still support some work in BIRP 2019.4 an when we used TextMesh the prefabs made in lower versions would break when porting up

as Legacy Text is the only system that works in all unity cycles it's my hope you will not deprecated until the new system is fully backported in place ...


Comment
legacy currently works with GizmoHandler so we can preset tgizmo Icons on/off for scene presets
it would be wonderful if TextCore could include similar GizmoHandler preset options linked into the Render Pipeline Asset

cheers

 

What is the timeframe for this?

Will there be some sort of tool that will transition our TMPro 3d text components to whatever the new component will be called and also convert our scripts?

 

Please clarify this: Will 2022.2.0b13 be able to extract OpenType font features or not?
As the change log state: New 2022.2.0b13 - TextMeshPro: Added support for Color Glyphs and extracting OpenType font features.

I'm disappointed with the timeline of this feature development. It's been SO LONG.

TextMesh Pro - *** Preview 3 Release of Version 2.2.0 and 3.2.0 Now Available! *** - Unity Forum I mean, last update is on Mar and it's been whopping 8 months since

 

The FontEngine changes required to extract data from the GPOS and GSUB tables will be backported all the way to 2020.3 and should have already landed in 2022 and 2023.

Version 3.2.0-pre.3 already contains the functionality with respect to Kerning and Diacritical Mark coming from the GPOS table as well as Ligature data from the GSUB table.

A preview 4 is in the works to address minor issues that I could not foresee when I initially released preview 3.

I concur and apologize for the delays.

I initially planned to release this new functionality shortly after the release of preview 3 (hence why preview 3 already contains the code to access this new stuff) but had to deviate from that plan due to some new requirements from Google related to Color Glyphs (Emojis) which happen to use several additional OpenType features that I had not implemented or planned on supporting at that point.

Please note, the FontEngine changes that will be / have already landed in these new releases of the Unity Editor do have support for almost all OpenType features but will require newer versions of the package to leverage.

Until then, in 3.2.0-pre.3 and future 3.2.0-pre.4 only Glyph Positional Adjustment from the Kern and GPOS table will be supported, Mark-to-Base and Mark-to-Mark also from the GPOS table and Ligatures from the GSUB table as those are the only ones support in Font Assets.

In order to support the additional OpenType Features, the structure of the font asset and related tables will need to change to expose Scripts, Features and Lookups which will also require extensive changes to the Text Parser and Layout in order to support these.

 

That's good news. Will try it and report back.

 

So, in the second quote here, what do you mean by "the TMP text object"?

 

Before I say anything else, a big thanks to Stephan for all their work in dragging Unity's text support kicking and screaming into some sort of modernity. Even for all its faults, I can't imagine having to have used the legacy Text elements for anything beyond a debug prompt, and TextMeshPro is a far superior alternative that produces pleasing results. (I remember a time when we were stuck fudging things together with a mixture of Flash-based SDF atlas generators and prayers...)


However, this transition is one that I am incredibly wary of.

For one, losing access to the source is a tragedy; there have been numerous times in the past where, in order to maintain a legacy project or work around an obscure issue, I have had to make changes or at the very least read through it to figure out what was going on. A few years ago, Unity were putting their all into open sourcing various sections of the engine to make life easier for developers, but with the current package manager strategy, that has been slowly going away (with no real reason, I might add, since the package manager can easily handle fetching from git repositories).

Secondly, I've experienced a TextMeshPro transition before (several, in fact). Obviously, this is an issue primarily with keeping older games up-to-date, but we manage a fairly large portfolio of legacy games that need to be routinely updated to meet platform holder requirements. From changes to how alignments are serialized (which required I write custom tooling to scour the project and correct them), to GUIDs being shuffled around (and the built-in GUID replacement tool not actually having the complete list of GUIDs of certain TMP versions, again requiring custom tooling), I am incredibly fearful of a core feature such as TextMeshPro being messed around yet again, for the sake of making your C# solutions easier to edit.

Finally, I am incredibly annoyed to hear that adding features is paused until this transition is complete. How many times have we heard this kind of thing from Unity at this point? While I highly praise TextMeshPro for being lightyears beyond the legacy components, it is still missing a fair number of features, some of which have been promised for a long time and continually require third-party workarounds to solve. Proper RTL support, OpenType, better kerning... I know these aren't exactly easy tasks, but the entire point of a game engine is to take some of the harder jobs away from the game developer. I fear that now, with Stephan leaving the project and everything being rolled into the UI package (a system that Unity have already been neglecting and has supposedly been in maintenance mode for some time), TextMeshPro will be lost in the mire of projects, packages and features that get partly completed before being abandoned by management, or turned into a mess that becomes nigh-impossible to recommend actually using. (How's that spline package going? DOTS? Tiny? Vector graphics? SRPs? Half the XR packages? PolyBrush? Input?)

Fingers crossed you can come up with a strategy that doesn't cause headaches to the rest of us - but I'm not going to lie, if this transition ends up being painful, it might be the thing that finally drives us away and cause us to find an alternative platform to develop on.

 

I also really want to thank @Stephan_B for all of their work and support over the years. Truly one of the best at Unity in terms of communication/support and we were spoiled. So thank you for all of your efforts to make Text better in Unity and good luck with your future endeavors.

In terms of TextCore as you mentioned @benoitd_unity not having source access to this new text system is going to be very limiting. I’m glad more opentype functionality is being integrated and that this will be better integrated into Unity. The loss of source is going to be painful. For our project we needed to be able to add custom tags, modify shader source, and inherit from TMP labels in order to add per-vertex UV channels. Without source access this would have been extremely difficult if not impossible. Please consider this as you integrate TextCore to try to keep it extensible by users.

 

Thank you for the kind words.

It was a pleasure and an honor to work with all of you and I am most grateful for all of your support over the years.

 

It’s not really my place but I have always been able to add my own functionality either through extensions or by using the library as middleware, which has been a great friend to me since I am never stuck with the latest version! Even the InputSystem, who’s internal code is a hot wired mess of internals and unsafes I extended to add my own sleuth of functionality, like accessibility options.

That being said, it’s usually more work and sometimes I straight-up copy a menu item because one line needs fixing - it’s not DRY but source is king: if it changes in unpredictable ways, you’ll still have a copy of that method that was giving you trouble.

 

Ugh, I have custom edits in TMP package. Can you allow changing of C# somehow?

 

https://xkcd.com/1172/

 

Yeah, it's funny how Unity blocks some changes (that would be beneficial to many) with the excuse of not wanting to break people's projects and other times they just break S*** to "simplify the maintenance and evolution" or something.

 

Honestly, the loss of source code access is the biggest worry for us. Transitions with different dependencies happen all the time, and we can deal with that - but odds are that on at least a few projects we'd be forced to make a copy of the final source release and maintain our own version independent of whatever updates it gets in the future. Feels like a waste of effort, and definitely a step backward.

 

I am unsure of what to think of this decision. Few years ago Unity made big strides with the goal of making the engine 'more lightweight, modular and developer friendly' by moving many things into packages, which was great. And now suddenly Unity is moving already existing package code back into the engine.
'Allows you to finally deprecate the legacy text system' - uh, what? What has kept you from deprecating it all this time? The TMP package was already available for a long time.
Not every project even needs text-ui elements.

I feel like it's a bad change. It'll bring pain to devs being unable to change / extend the code, and arguably even reintroduce more bloat to the engine again.

 

Ok. And what about bringing UGUI/TMP/UIToolkit "core" text rendering performance at least on par with the 10 years old OnGUI ?

Even in latest versions, TMP text rendering (I'm not talking about layout/parsing, but strictly about what happens in Render() when a new string is affected) is about 1.5 to 2.5x slower than a full GUI.Label() call for short (1-10 chars) strings.

For long strings, performance is simply abysmal, and it scales exponentially worse with string length.
Rendering a 500 char string takes ~1 ms, vs ~0.12 ms in OnGUI().
Rendering a 1000 char string takes ~2.3 ms vs ~0.22 ms in OnGUI().

I guess a reason is that UGUI/TMP provide more features (and maybe better rendering quality ?) than whatever the IMGUI backend is, but in terms of absolute performance for basic text rendering I can't imagine those figures are anywhere near the state of the art in 2022.

 

The performance of TMP with short strings should be on par with GUI.Label(). With longer strings and as a result of the add feature sets, it can be slower but that would have to be re-verfied.

Please note that it is important to be mindful that when profiling these things, we are potentially comparing release code which like GUI.Label() vs. user / package code which is debug code (ie. much slower than release / optimized code).

Having said that and to be certain, can you provide whatever project / scene you are using for testing this?

 

@uDamian
could you give more clear info about the plan to deprecate the legacy Text system
this is this the biggest concern in that we will not have a single system that just works in every api

at the moment without legacy Text we would not be able to have text in assets supporting older unit version on the asset store. TMP in older unity versions breaks when porting up ... the assets on the store must be load by developers from the lowest unity version they support.

please clarify any timeline about deprecation for legacy Text
how will you handle the transition

 

And here I was hoping TMPro would be untangled from UGUI so I can finally get rid of the UGUI package, since I exclusively use the 3d TextMesh Pro component.

And instead the two packages are getting merged? Why?

Can we get a world space 3d text component with distance fields without any of your UI packages? Thanks.

 

From what Stephen said, 4.0 was for UIToolkit and UGUI so that you could use the same font/sprite assets together? Will it be integrated into UIToolkit also? If so, is there a timeline?

 

@uDamian
> We actually plan to verify TMP 3.2 (as a package) for Unity 2023 LTS, which will then be supported for many years.
Are you planning to verify TMP 3.2 vs Unity 2021 LTS? We're using it for the DynamicOS font. It seems solid, but having it verified would be reassuring and desirable.

 

omg dude. please stop acting like the deprecation of the legacy text is an issue. it's deprecation has been awaited for sooooo many years now.
if you literally can't find any other way the easiest way would be to update your asset, and re-publish it with tmp again as a new asset.
people like you hold back the advancement of technology for no reason.

 

I, on the other hand, think the people that hear "omg the package manager is so great" and believe it without proof are the people holding us back, but maybe we should abstain from making such broad comments, right?

Unity, in the information they have given us here, are a bit vague on what exactly will the legacy text be replaced with. Will it be the 3d textmesh pro? (does that mean it will work without a package at all?). Will there be an easy way to convert our 3d TextMesh Pro components to the new textmesh one?

We've been trying to get clarifications on those questions, that's all. Maybe there are no concrete answers yet, which is fine, but it feels we should be able to get replies for simple things like:

 

Sad to see @Stephan_B no longer working on TMP, because his help in the forums was just outstanding. Stephan, do you mind to tell us what your new role at Unity is?

 

ok i don't get what you're not understanding.
the TMP package will be removed and the tmp 'code' will be more closely integrated into Unity (not be a package anymore)
the legacy text will be removed and the 'tmp elements' will be the standard default text elements.
(if they will be named the same as currently i don't know)

 

You see, when you say this, you're probably imaging everything going smoothly, while I (especially when I know Stephan won't be involved) imagine one day upgrading to a newer version of Unity and suddenly none of my text works anywhere and the project throws a bunch of errors, the manual says nothing about it, and I'm left on my own to figure out what the hell is going on. Which is why questions are asked here, now.

Also, I would like to note that these back and forths between package, asset, core, whatever have been annoying the past few years, every time something gets turned into a package, its actual development stops for years and no progress is being made, and then we also get told that the editor is now slower because Unity has a lot more C# code running due to the package manager.

I want the 3d Text Mesh Pro component (you know, the one that was actually the original feature of TMPro, the reason it became popular when it was a 3rd party asset), to be stable and get better, and what was announced here is that they are going to do a lot of lateral movements for years probably, for really no benefit, and will probably create a bunch of busywork for me in the process. But I guess that's Unity in a nutshell the last 5 years.

 

What kind of developer are you if you shy away from any busywork. Sure, building up on 'unchanging' things is easy, but that's not how progress is made. I for one believe moving more to C# is absolutely a good move, and once the .net migration is complete, you won't even feel a difference compared to cpp or it's neglectible. But yeah, right now, based on .net framework, it's quite slower which could be a sore spot for some devs.

 

The kind that wants to progress on their game as opposed to doing mindless busywork, because Unity can't decide whether it wants things to be packages or not while I pay for their salaries.

I understand wanting to finish games and also using Unity is a weird combination, but here I am.

 

Losing ability to modify code - optimize and fix bugs ourselves in C# instead of waiting years for Unity is a lot more important than few % of optimization from using C++.

 

The information provided is either contradictory or missing details.

Consider the following:

So TMP will no longer be a thing, but also TMP will be the replacement for legacy components? Doesn't sound right to me.

 

the *package* won't be a thing anymore.
TMP is integrated back into the core of the engine as part of TextCore.
the TMP text object (which will then be in TextCore) will replace the legacy text object

 

"Busywork" specifically refers to tasks which require effort but don't produce value. Any decent developer should avoid it. Of course, what's "busywork" to one person may be valid, crucial maintenance to another.

To Unity this is the latter, because they currently have a mess, and want to turn it into a cohesive system to be used for a decade or more. To anyone with a game project in late stages it is very much the former, because we already got stuff working and want to minimise busywork between where we are and where we can ship. (I'm personally not too concerned as TMP still works like a 3rd party plugin.)

Our (differing) interpretations aren't worth anything while they're based on incomplete information.

In any case, I dearly hope that a new system called "TextCore" will not contain components called "TMP" or "TextMeshPro" or whatever else derived from an old, 3rd-party plugin. Names should be reasonably self-explanatory without needing a history lesson.

 

I appreciate the reply @uDamian , I guess TMPro has UGUI now as a dependency anyway, so in a practical sense from a user's end having them become one package doesn't really change all that much.

(apart from some confusion when looking at the installed packages and wondering wth do I have that awful package installed)

I just hoped that at this point we would be past Unity playing around with making and unmaking things into packages and we would have actual progress, but I guess it doesn't matter now.

 

At this point, will I be able to make text in my game with TextCore without also importing "uGUI" or "TMP Package 4.x"?

I'm also curious as to why "TextCore Font Asset" starts in TextMeshPro and moves to uGUI, rather than being alongside TextCore from the start? If the purpose of all of this is to get TMP's capabilities into the core engine then surely font assets are a necessary part of that?

 

You keep saying this but it seems unmotivated, why do you feel moving code to packages is not actual progress? It may not hold up too well for TMP because it needs to be ported over, but newer features start as packages now - look at Animation Rigging. Look at the Input System. Localization is a great package and yet I've never had it complexity bog down on my own development experience because it is a package.

The package manager solves the issue of dependencies on different code bases (e.g. ECS and its many dependencies) and it's gonna get even better once Unity has migrated to .NET Core and we can create dependencies on NuGet packages (this is a thing they're working on for 2024.1+) so there's definitely a use for it.

Also @uDamian appreciate the update, really clarified some stuff

Edit:
I was genuinely interested, there's really no need to be passive aggressive :')

 

Do you really want to derail this with a lengthy rant about the package manager, Unity's general tendency of being in transition for the last 5+ years and using it as an excuse to not improve things, and how the new features suck ass (including those you mentioned).

Let's not.