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.
14 Likes
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?
2 Likes
1 Like
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 shit to âsimplify the maintenance and evolutionâ or something.
2 Likes
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.
2 Likes
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.
1 Like
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?
Hello! I lead the UI Tech team, responsible for the âbackendâ of our 3 UI frameworks, and more recently, Text. I wanna add a bit more clarity to our transition plan here, and Iâll try to keep you all posted as the plan evolves over time (because it absolutely will evolve). This is our current plan, as of Dec 4, 2022.
First, to confirm, nothing is changing it terms of where code lives until 2024.1, at the earliest. We actually plan to verify TMP 3.2 (as a package) for Unity 2023 LTS, which will then be supported for many years.
As for the transition of TMP to the uGUI package, this will actually be for TMP 4.0. As such, TMP 4.0 will never be verified (because it will be part of the verified new version of uGUI). This merge will be a straight copy/paste of the assemblies in TMP 4.0, and weâll try to keep the paths within the package similar enough to make grafting of custom changes easier. Since uGUI is already a package, youâll still have source access to TMP 4.0 going forward.
Zooming out a bit, this transition is entirely about making TextMeshPro (more specifically, its Text tech) the singular and default text solution for everything in Unity (that we offer), that includes the Editor, Runtime, IMGUI, UI Toolkit, and uGUI. We wouldnât be doing this if we didnât believe in TMPâs future. And it simply canât be the text solution everywhere as long as it says a package - for various global reasons, in our current year of 2022.
Take performance for example (mentioned above). Itâs something that often comes up for both UI Toolkit and TMP when compared to uGUI and legacy Text. Brining TMP into core, alongside UI Toolkit, makes a lot more optimizations possible, including moving some of the heavy lifting to C++ and tighter integration with UI Toolkitâs renderer and layouting engine.
Weâll have more details as we move forward with this transition.
7 Likes
@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.
1 Like
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?
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.
1 Like
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:
2 Likes
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?
1 Like
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.
2 Likes
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.