Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Official Future of Text at Unity

Discussion in 'UGUI & TextMesh Pro' started by benoitd_unity, Nov 2, 2022.

  1. Kamyker

    Kamyker

    Joined:
    May 14, 2013
    Posts:
    1,085
    Asking again, even with tight integration in the engine couldn't you ship the C# code in asmdef instead of .dll to still allow edits?

    What about TextCore (or even whole Unity Core) being a built-in package to enable source access?
     
    Last edited: Dec 8, 2022
    Noisecrime and MasonWheeler like this.
  2. Stephan_B

    Stephan_B

    Joined:
    Feb 26, 2017
    Posts:
    6,595
    I am on the consulting side at Unity in the Accelerate Solutions team doing mostly Project Reviews to help our customers resolve and / or identify potential issues in their projects to ultimately help them achieve the results they seek, ship better games / apps and hopefully increase their chance of success.

    P.S. Thus far every single project I have reviewed has been using text. About 90% of them using TMP, some using UI.Text and 1 still using NGUI.

    In these reviews, I get a much closer look at the challenges our users face not only with respect to text but almost every aspect of development in Unity.

    Like I said before, I remain passionate about text and will continue to provide assistance whenever I can. I remain and will always be grateful for the amazing support all of you have shown over the past years.
     
  3. uDamian

    uDamian

    Unity Technologies

    Joined:
    Dec 11, 2017
    Posts:
    1,231
    If you use text through UI Toolkit (not a package!), then yes, you won't need the uGUI or TMP 4.x package.

    You're right, technically "TextCore Font Asset" is and always has been in Core, alongside TextCore. I just wanted to clarify the difference between TMP 3.2 and TMP 4.0. I'll clarify.
     
    angrypenguin likes this.
  4. uDamian

    uDamian

    Unity Technologies

    Joined:
    Dec 11, 2017
    Posts:
    1,231
    We've actually tried this in the past, with UI Toolkit itself. We shipped (past tense!) UI Toolkit both as core modules (dlls) and as a package (com.unity.ui) which contained assemblies (also dlls) that would actually override the core modules when installed. With this approach, you could have a newer or modified version of UI Toolkit overriding the modules that shipped with core Unity.

    We did this because UI Toolkit is such a core feature (used by the Editor itself) that it can't live as a simple leaf package. It has to be below the EditorWindow class, for example. Text will be no different (is no different when it comes to TextCore).

    But as you can see, we had to move away from that approach and back into only shipping UI Toolkit as core modules. The reasons for this are numerous, but it ultimately comes down to deep rooter infrastructure limitations that led to very high maintenance costs and a major source of instabilities (and bugs).

    There are ongoing plans to address these limitations but it's a topic well outside the scope of this thread or in any way specific to Text. It's not a question of why we don't provide source access to TextCore. It's a question of why we don't provide source access. It's a topic better discussed on the Scripting subforum.

    That said, if you absolutely want to keep source access to TMP, there will be a way to keep TMP 3.2 (after some modifications on your side) working alongside TextCore in 2024+. It will be a choice between having control over the source code or using what comes out-of-the-box with Unity.
     
    orionsyndrome likes this.
  5. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    15,616
    Nice. And always will be..?
     
  6. uDamian

    uDamian

    Unity Technologies

    Joined:
    Dec 11, 2017
    Posts:
    1,231
    "Always" is a strong word. :) But I can say it's as likely to stay in Core as Prefabs.
     
    angrypenguin likes this.
  7. Swah

    Swah

    Joined:
    May 13, 2015
    Posts:
    80
    We've got a project we intend on maintaining for multiple years, that already shipped, and currently has both the old Text and TMP text.

    If I understand correctly, we'll want to move to TextCore for _all_ text we're using. Will Unity provide easy ways to migrate both Text and TMP to this new component? Or will the transition from TMP to TextCore be seamless, and developers won't have to update their assets themselves?

    Thanks.
     
  8. HugoBD-Unity

    HugoBD-Unity

    Unity Technologies

    Joined:
    May 14, 2018
    Posts:
    492
    Hi @Swah! We intend to make the transition as seamless and automatic as possible for users.

    Users that modified the source code of Text Assets (TMP_FontAssets, TMP_SpriteAssets...) will be more impacted as those assets will no longer live in the package.

    That being said, changes to other parts of the system should still be possible, and we'll try to expose the necessary APIs to help ease the transition.
     
    AcidArrow and Swah like this.
  9. Noisecrime

    Noisecrime

    Joined:
    Apr 7, 2010
    Posts:
    2,051
    You know what would be really nice for your customers is if Unity spent some time when we arrive at this point to create a 2024+ compatible TMP 3.2 package, with the modifications you mention. That way the numerous developers who will end up having to go that route wont all be trying to write their own version - in other words Unity does it once instead of it being done numerous times by numerous developers which is such a waste of time.

    I'm not entirely happy with these changes as I've been used to being able to modify and learn from the source code of TMP for many years. While I can except that ultimately we will lose access to 'core' aspects of TMPro, what concerns me more is losing source code access to things like components, where I most often make changes. This wouldn't be so bad if Unity was responsive to requests, but that's really not the case.

    Additionally Unity has a tendency to private or internal so many methods that extending or adding custom versions of say components is impossible, without reflection or wholesale duplication of the code. I wish Unity would take a careful look at this, carefully considering the value of using internal or private classes/methods.


    Edit - few hours later
    The example below appears to have been addressed by TMP 2.1.6, though via an alternative method that isn't 'strictly' as simple to implement particularly for existing dropdown gameObjects. The method ( 'PlaceHolder' option, that requires additional graphic gameObject) is one I originally dismissed for various reasons and hopefully isn't due to any specific reason for my project that I've forgotten about.

    However the point of the example wasn't to get this specific issue addressed, but to show how important it was for developers to have the means to make such changes that it appears we will lose completely unless we want to be stuck on an old version and that alternatives even with having access to underlying source code isn't as straightforward.

    I hope that Unity will take this and any other examples seriously enough to give consideration as to how developes can avoid being locked out of making such changes in the future with this change to internalising the entire TMP codebase.



    A Typical Example
    I actually came to this forum to post a request for an improvement I had made to TMP_Dropdown script that is now essential to my projects ( though I've not checked if the feature has been added in recent version of TMPro, but I doubt it ). Its a very simple offset to skip the first n items in the optionList, so that the first option can be a 'descriptor' of what the options regard, but where the descriptor is too long or does not make sense as a header/label above the dropdown.

    It would appear from what has been written come 2024 I will be unable to retain this essential code change unless I stick with TMP 3.2 (modded). Whilst in this case I am forewarned, beyond 2024 if I run into the same situation of needing to modify source I would have to back port a project to use the TMP 3.2 (modded) which becomes so much more difficult.

    Again this might not be so bad if Unity were more responsive to change requests, but even then I'm actually doubtful that this small change (approx 4 lines of code in TMP_Dropdown) which is absolutely essential to my project would be approved or deemed worthy!

    As an alternative I looked into simply making a custom version of TMP_Dropdown. Ideally it would be an extension, but the class is internal and methods private! So i'm stuck with duplicating the code to make a TMP_DropdownCustom script, but guess what, as it sits outside of the TMPro package it runs into problems as it relies on other internal classes ( TweenRunner ). So it looks like I'll have to duplicate that file too, but no idea if there are more errors to be fixed.

    As can be seen, while modifying the source code package of TMPro is not ideal, its going to be the best approach. However the real concern comes once all of this is internal and locked away as I'm not sure I could even accomplish the same thing and I'm back to the whims of Unity approving a change request!
     
    Last edited: Mar 16, 2023
    ontrigger likes this.
  10. uDamian

    uDamian

    Unity Technologies

    Joined:
    Dec 11, 2017
    Posts:
    1,231
    I hear you.

    There's a lot of nuance around TMP and its future. It's a choice between:
    1. source access
    2. velocity of new features/improvements
    3. deep integration and leverage by other core Unity features (UI frameworks)
    and we could only realistically optimize for 2 of those 3. If we chose source access, we would lose on either velocity or integration (or likely both).

    It's not that we don't see the value of source access. Every demo project or hackweek I've done I've benefited from having source access to Unity as a whole. But most users don't pay for Unity so they could write their own game engine. We need to still deliver new value to all users and we still need to consolidate the various tech stacks we spun up.

    And even if TMP source access is maintained, you still don't have access to many other core features of Unity. TMP doesn't exist in isolation - and that's a good thing. It means we believe in its value and its future and we want to base our entire tech stack on top of TMP. But we need to change the way we work on it - for now - to make this possible. The alternative would be abandoning TMP and creating yet another text backend.
     
  11. Kamyker

    Kamyker

    Joined:
    May 14, 2013
    Posts:
    1,085
    There's a lot of nuance around Unity and its future. On a long enough timeline Unity will fall behind without source access and completely free contributions from userbase that happen in other engines like Unreal, Godot, Bevy.
    Push all tech stacks to go for source access and C#. Performance difference is tiny and will be even smaller once Unity moves to NET Core in 2024-2025.

    Simply take advantage of source access. With this large userbase you'd have 10x velocity of new features/improvements/bug fixes by accepting pull requests. Not only that but users would get what they really want instead of what Unity thinks they want (like UI Toolkit mess for web developers).
     
  12. Noisecrime

    Noisecrime

    Joined:
    Apr 7, 2010
    Posts:
    2,051
    Thanks for the reply, however the problem with this stance is Unity has frequently shown itself to abandon features for long periods of time ( e.g. Terrain, UGUI etc ) that means the velocity of new features/improvements are ZERO!

    While I'll admit I don't see TMP ( TextCore ) being abandoned completely, I do not see it having the necessary 'velocity' for new features/improvements to combat the loss of source code access, especially since as a whole other text sub-systems ( IMGUI and the new UIToolkit ) will demand more attention from Unity developers for the foreseeable future!

    The intention of my post above was to illustrate how important source access can be and the hope that Unity might try to find a middle ground. For starters that means stopping marking everything Internal or private ( in C# domain) and especially not native. Consider what methods and classes the community often edit or expand or would want to modify and work to make these accessible and ideally overloadable. Its still not ideal, but it would be more than we are proposed to get at the moment.

    Alternatively perhaps it is time Unity started to open-source some internal native code where appropriate and where licensed code does not apply. I assume TextCore is going to become a module of sorts, so it feels like it could be bundled out of the core engine in such a way that developers could modify it and certainly the parts that were already exposed are free from any licensing concerns.



    A great example of Unity going the wrong way here is static batching ( see thread ). It was discovered by the community two years ago that it had been utterly broken since at least Unity 5.x, maybe earlier, where by it sorted and batched meshes not by some distance factor (or something more appropriate) but by the arbitrary instanceID of the gameObject!

    At the time the community worked out how to vastly improve the results and performance, though having to use reflection to access internal C# methods. Then not long after Unity claimed to have fixed the problem ( the fix was gratefully received but pretty barebones and non-optimal ) it was discovered in a version prior that the C# methods used in the community workaround had been moved into the Unity core, thus preventing said solution from working at all!

    Now the community is stuck with a slightly better solution than before, but one which still falls short of the more optimal algorithms that could be used. This is because at the time only a simple change could be made to guarantee it wouldn't break legacy projects and in my opinion we will now be stuck with that for many years or more.
     
  13. AcidArrow

    AcidArrow

    Joined:
    May 20, 2010
    Posts:
    11,631
    Unfortunately what I hear here is "We want to bloat the S*** out of TMP until it is an unusable mess, to bring it more in line with our other features".
     
    koirat likes this.
  14. optimise

    optimise

    Joined:
    Jan 22, 2014
    Posts:
    2,114
    @uDamian Any plan for TextMeshPro to add gc free SetText APIs that can directly pass FixedStringxxxBytes?
     
  15. Unifikation

    Unifikation

    Joined:
    Jan 4, 2023
    Posts:
    1,079
    Did Material Variants have any role in this decision?
     
  16. Unifikation

    Unifikation

    Joined:
    Jan 4, 2023
    Posts:
    1,079
    Why not burstify and jobify the old canvas system's constraints and resolves so that can at least be faster on all hardware with multiple cores, whilst you spend the next 10 years making two more UI systems?
     
  17. uDamian

    uDamian

    Unity Technologies

    Joined:
    Dec 11, 2017
    Posts:
    1,231
    I don't see the connection between what I said and this conclusion. If you want me respond, I'll need more details on how you got there.

    It's actually the complete opposite. TMP is _already_ bloated. It has A LOT of features. While useful and valuable, for sure, it was not a sustainable level of feature creep to keep doing this in an isolated package that nothing else in Unity is based on. Keeping TMP as a package may have been the right call from the perspective of a TMP/uGUI user, but it was not the right long term approach from the perspective of a UNITY user. I understand it's a nuanced trade-off, especially in the short term, but if you love TMP, why would you not want to see this tech used _everywhere_?

    It's on the roadmap, once we finish the transition to TextCore.

    Because it would indeed take 10 more years if we kept improving IMGUI, uGUI, and TMP while trying to ship UI Toolkit/TextCore. And we absolutely don't want it to take 10 more years.
     
    spakment and optimise like this.
  18. optimise

    optimise

    Joined:
    Jan 22, 2014
    Posts:
    2,114
    If I understand correctly, the concern here is the source access. I guess because of currently UI Toolkit editor and runtime are written at C++ land and causing TextCore also being forced to write in C++ to tightly integrating with UI Toolkit. It seems like only way to do it is to transition to C# and make TextCore and UI Toolkit as package. If just only move TextCore to C# to provide source access looks impossible.
     
  19. uDamian

    uDamian

    Unity Technologies

    Joined:
    Dec 11, 2017
    Posts:
    1,231
    On the topic of open source, I don't have much more to add to this. It's not a TMP-specific topic. It's a much bigger Unity-wide topic. Nobody denies the advantages of open sourcing, but there are other factors, and they won't be solved in this thread.
     
  20. Unifikation

    Unifikation

    Joined:
    Jan 4, 2023
    Posts:
    1,079
    How about thinking about it as just finishing the UGUI product, then?

    What a thought. This performance issue with Canvases has been an issue for nearly 10 years, and Unity has had the tech to solve this problem for 5, and this optimisation can be done by a single person. One of the reasons for wanting nested Prefabs (for 10 years!) was the hope it'd help solve this performance problem.

    Try thinking about it like this: Physics2D jobified and burstified much of its constraints and resolving, and it's something that can be done by a single person, and, in the case of the performance issues of Canvases being all in this one area, can yield massive gains, and finish the product.

    You could, given it's an older tech and approach that's being dumped, even open source this so someone in the user base could do this!?
     
  21. Unifikation

    Unifikation

    Joined:
    Jan 4, 2023
    Posts:
    1,079
    Whilst you figure out that web technologies are inherently 2D and the world increasingly wants 3D dynamic and never more animated UI systems, why not add a lightweight TMP object with only a Transform rather than the big RectTransform, so diegetic amazingness can be done lighter and faster?

    Please make a Lite TMP object with only a 3D Transform


    Take a moment to think about the world of games and their UI desires. ... because UI and response textual graphics are increasingly required/desired in diegetic ways, to keep up with the Jones', and ever more stylistic and animated. All things that TMP and SDF with a mere 3D Transform are better suited for than any other technology available or in consideration.

    Yet the move... go and use the ideas of the Editor's web tech/approach for game UI... deliberated, designed retrogression into 2D.
     
  22. CaseyHofland

    CaseyHofland

    Joined:
    Mar 18, 2016
    Posts:
    610
    So... I just wanted to say, I like the new UI system. It took some time to adjust but what works best for me is to skip the UIBuilder entirely and just write out my inspectors via CreateInspectorGUI and this is totally viable.

    I thought the issue was deeper than "just jobify", I remember there being a lot of hype around UIToolkit drawing only what you see on screen (even in a 100000-item sized shop) and a need to bring all UI under 1 reusable banner, hosting editor and runtime alike.

    Personally I do hope they make the UI Builder easier to use around USS coupling. I don't like the string coupling so much. I'd much rather have an object picker more akin to what you'd see in a regular inspector. It made sense for Hyper Text but Unity can just 'run code' so why be married to it?

    It also takes me too long to move a box 50 pixels over in exactly the way I want. I think my biggest frustration is that I can't use calc. I once wrote a layout that needed to scale based on height (we wanted to be hip and not have a vertical scrollbar) for which I used calc(100vh - x) A LOT, and this was perfectly viable. Calc to me opens up a lot of creativity.

    We haven't made the switch over to using UI Toolkit for UI, but that's a big commitment we're simply not ready for. Sometimes I personally try to make small bits of UI using Toolkit but I always end up going back to what I know - I haven't looked through the new UI learning course yet though, so I'd like to come back to it one day.

    I'd hope the Canvas system stays for a long time though: I enjoy the new UI System but it's so different and bold compared to the old one that I find it very slow to adjust. As I get more and more comfortable though, I do want to use this eventually for everything, but it's a bit like coming from Dutch then learning Chinese.
     
    Unifikation likes this.
  23. Unifikation

    Unifikation

    Joined:
    Jan 4, 2023
    Posts:
    1,079
    Culling of various sorts solves excess drawing issues. All solved problems, Apple obviously leading the way in demonstrating how to do this with big scrolling list and async prefetching. All of which somewhat already works with long lists of TMP scrollers, too.

    The issues with performance of nested canvases and many constraints is that the solvers are thread grabbers and slow. So merely shoving them off to a job on another thread means huge amounts of hiccups and hitching will be gone, forever.

    Secondly, jobifying the entire solver for dirtied layouts, with consideration for burst optimisations, would be relatively easy code - and an ideal demonstration of jobification and bursting, and gain huge amounts of performance... again, all off the main thread.

    And leave us with the ability to go deep and have fun with canvas oriented layouts in diegetic spaces, plural, since that's an area where UGUI simply has no rival.

    ---

    Agree with your other comments. There's a reason a LOT of other engines took and ran with the canvas and constraints methodologies... it's creative, literal and extremely WYSIWYG Editor friendly, whilst being the best way to make (AND EDIT!) responsive layouts, quickly and easily, too.

    All it needs is performance, which is just a burst of jobs and burst compilation friendly conversions away from it being a flyer.
     
  24. Unifikation

    Unifikation

    Joined:
    Jan 4, 2023
    Posts:
    1,079
    @uDamian

    What would be required to get Unity to Open Source UGUI/Canvas features such that we, the users, could optimise, jobify and burstify their resolvers, constraints, dirtying, etc?
     
    Noisecrime likes this.
  25. CaseyHofland

    CaseyHofland

    Joined:
    Mar 18, 2016
    Posts:
    610
    I am, of course, not uDamian but expect to hear not a chance.

    Unity at large doesn’t seem interested in open sourcing at this point in time. There have been many discussions about this in the forums already and with Godot and Unreal being the masters of open source it gets brought up more and more, but “licensing” and (most likely) “investors”.

    We have better luck starting our own suite of open sourced tools as a community really, but managing that’s a fulltime job
     
  26. Unifikation

    Unifikation

    Joined:
    Jan 4, 2023
    Posts:
    1,079
    This is a mere system that's becoming obsolete, being replaced/deprecated, was originally created outside Unity.

    There's a lot of reasons this might be far easier than carving off and open sourcing something deeply integrated into the engine, like Animation Legacy.
     
    MousePods likes this.
  27. Ramcat

    Ramcat

    Joined:
    Aug 16, 2014
    Posts:
    95
    I've been gone from Unity for 6-8 years. In my short time back I've noticed the intensity @Stephan_B has exhibited in supporting text (and TextMeshPro). Stephan, you have been a great support to many people. I'd like to have a hundred clones of you for any project. Best of luck in your new adventures.
     
    Stephan_B likes this.
  28. Andy-Touch

    Andy-Touch

    A Moon Shaped Bool Unity Legend

    Joined:
    May 5, 2014
    Posts:
    1,479
    Huge thank you to @Stephan_B for his bottomless amounts of knowledge and enthusiasm to improve text in Unity and games. Any studio that has a sit down chat with you, in your new role, is very lucky! :D

    And thanks to the UI team for being open and honest about this transition and future plans. Helps us to plan ahead!

    So with features seemingly paused during this transition; does this mean we have to wait even longer for proper RTL language support in vanilla Unity Text/TMP/TextCore? Its been requested since UGUI first shipped almost a decade ago! :confused:
     
    Last edited: Mar 29, 2023
    cxode and Ramcat like this.
  29. Znol

    Znol

    Joined:
    May 10, 2020
    Posts:
    6
    Pier-Luc_Artisan and Unifikation like this.
  30. enhawk

    enhawk

    Joined:
    Aug 22, 2013
    Posts:
    833
    What is the fate of Bitmap Fonts? Currently these are only supported by Unity Text (depreciated). If Unity Text is removed, will support for Bitmap Fonts be removed from Unity?
     
  31. Jonathan-Westfall-8Bits

    Jonathan-Westfall-8Bits

    Joined:
    Sep 17, 2013
    Posts:
    252
    Out of curiosity what issues do you have with stuff like RTL Language support?
     
  32. Ukounu

    Ukounu

    Joined:
    Nov 2, 2019
    Posts:
    209
    Every few years I check TMP to find out if it finally can resort to installed system fonts instead of displaying square blocks for unknown languages, and every time I find out it still can't. Old Unity Text component is still vastly superior when you have to deal with numerous localizations and correctly displaying user input in every possible language.

    Like, you distribute a game on Google Play in 130+ countries, and user can input a name for their in-game character in their native language, and that name then should be displayed in character's stats. Very simple and very basic task, isn't it? With Unity's default Text engine it indeed is, and can be done in a few clicks. But trying to achieve the same functionality with TMP becomes an absolute and messy disaster.

    I wonder if this issue will be solved when TMP is incorporated into Unity core text engine? Or it will forever work the same way as TMP - either define a correct font asset for every single language in the world, or you are screwed?
     
  33. Jonathan-Westfall-8Bits

    Jonathan-Westfall-8Bits

    Joined:
    Sep 17, 2013
    Posts:
    252
    It is improved in UGUI 2 with more improvements in UGUI 3 Preview.
     
  34. Unifikation

    Unifikation

    Joined:
    Jan 4, 2023
    Posts:
    1,079
    Where are you seeing this information?
     
  35. He is sarcastically trolling.
     
  36. Jonathan-Westfall-8Bits

    Jonathan-Westfall-8Bits

    Joined:
    Sep 17, 2013
    Posts:
    252
    Unity already released an official forum post about this a while back.

    [Edited]
    https://forum.unity.com/threads/2023-2-latest-development-on-textmesh-pro.1434757/

    Not sure if you mean I am trolling or Unifikation is trolling.

    I was actually being serious. Screen shot attached below.
    The package name is Unity UI 2.0.

    The technically package name for those wanting to install UGUI 3 is
    com.unity.ugui

    The improvements are very noticeable after changing the Editor Sharpness settings.
    Faster rendering on switching tabs, Text Code supports for being able to do text effects like bolding, changing color, and more using Text Tags without the need to code them.

    Shader Graph support. There is now a system to make Shaders for UI. I made UI for health that is a skull bottle with liquid blood in it. As the health of the player goes down the liquid drains, but it is all just a Unity UI Image with no animation. It also has liquid collision in the UI so yeah major improvement.
     

    Attached Files:

    Last edited: Sep 24, 2023
  37. Oh you were genuinely serious with the "improvement". Sorry, my bad.
     
    Unifikation likes this.
  38. Jonathan-Westfall-8Bits

    Jonathan-Westfall-8Bits

    Joined:
    Sep 17, 2013
    Posts:
    252
    Hey, no problem there are trolls on all forums so I get it.

    The link I dropped goes to a forum post that will have more explanation coming. As far as I know they are planning on editing and updating that one when it gets the next update to Unity UI version 3. By the looks of it and due note I could be reading the changes on the repo to source code wrong, but seems like VFX Graph might be having some cool stuff coming to UI and talks about audio systems updates for UI.

    Like click a button and be able to have an audio file play with no code needed.
    The audio thing I am assuming come after the Audio API update which has been real nice.

    Audio started getting updated in 2023.2 beta. There is a thing called Audio Containers now.
    Both Audio Clips and Audio Containers actually inherit from a new C# class if I remember right called Audio Resources.
    the changes are really nice and fun to play with. Between the foot step sound playing system with the Audio Containers and the built in editor for music play list in Unity for making sound tracks for your game it is a huge step forward for Audio Tools.
     
  39. IDK, I use Fmod for ages, one of the first thing (besides removing Unity Version Control and Visual Scripting packages) I do in a new project is disabling audio and installing Fmod. They won't beat it in this century.
    I checked that random audio asset, well, in typical Unity fashion, they skipped the standard inspector and wrote a custom editor for it. Because in Unity every single asset needs to have different style editor with different usage... I don't really understand, they used to have UX people at Unity, I guess they got booted instead of the managers.
     
    AcidArrow and Unifikation like this.
  40. Unifikation

    Unifikation

    Joined:
    Jan 4, 2023
    Posts:
    1,079
    Is this with TMP and their SDF shaders?
     
  41. Jonathan-Westfall-8Bits

    Jonathan-Westfall-8Bits

    Joined:
    Sep 17, 2013
    Posts:
    252
    So to be clear TMP is no longer a package from Unity 2023.2.

    TMP was integrated into the new system called Text Core.
    Unity UI Package 2.0 is the introduction of Text Core.

    So Unity UI 2.0 has Text Mesh pro systems and features, but more integrated into the editor making it a lot easier to add new features, fix bugs, and so forth for the developers at Unity.

    So when I say UGUI 2 aka Unity UI 2 I mean the new systems where TMP is part of the editor now.

    Unity 2023.2 and newer Unity UI 2 = newer TMP systems.
    The SDF shaders does work with the new system.
    In Unity 2023.2 with Unity UI 2 add a shader graph and change it's mode to canvas.
    Canvas is meaning UI Canvas.

    So as confusing as this seems UGUI 2 = Unity UI 2 = Text Mesh Pro 3.2 with a lot better systems.

    I think that confusion of those three having seperate names is one reason why they did this.
    Now you only need to know one name Unity UI Package.
     
  42. Unifikation

    Unifikation

    Joined:
    Jan 4, 2023
    Posts:
    1,079
    Interesting. I'm avoiding 2023 and not at all happy with the performance of anything after 2019.LTS, which was very slow compared to prior versions.

    TMP Shaders are (before the Shader Graph versions) slow. Dealing with TMP shaders in Shader Graph is not something I want to bother with...
     
    laurentlavigne likes this.
  43. joolsa

    joolsa

    Joined:
    Mar 20, 2013
    Posts:
    10
    Actually I think this has been implemented, but it's very under-documented. Note: I have not tried this. Apparently they are "Dynamic OS" fonts:

    https://forum.unity.com/threads/how...ic-font-source-to-build.1358672/#post-8572868
    https://forum.unity.com/threads/font-createdynamicfontfromosfont-not-working.1253064/
     
  44. Jonathan-Westfall-8Bits

    Jonathan-Westfall-8Bits

    Joined:
    Sep 17, 2013
    Posts:
    252

    The new Shaders seem to have a very good Performance improvement when they updated them with the release of Text Core. Due note I haven't done a pure performance test on just them, so can't give an accurate number sorry.
     
  45. Ukounu

    Ukounu

    Joined:
    Nov 2, 2019
    Posts:
    209
    Not really. "Dynamic OS font" still requires you to manually set up fonts and manually write code for every single language out there, one by one. If you didn't set up font reference for some specific language, in TMP you will get empty squares instead of text, while Unity's default Text engine will just fall back on whatever font a user has on their device.

    So with TMP you are basically required to rebuild on your own a huge slice of functionality that exists already and works out of the box in default Unity's text engine. Default functionality that nobody ever asked to deprecate or remove, on top of everything.

    This single critical issue makes TMP pretty much unusable for me, and if in the future TMP will be completely replacing Unity's default text engine, it would become a major problem for all developers dealing with user text input on global (worldwide) scale.
     
    Last edited: Sep 25, 2023
  46. Jonathan-Westfall-8Bits

    Jonathan-Westfall-8Bits

    Joined:
    Sep 17, 2013
    Posts:
    252
    Couple things to unpack here.

    That actually sounds like a bug. There is a fallback for the device you are building to.
    In you text settings check to see if the fallback font is set for device native fonts.
    Should be in the TMP Settings under project Settings.

    Also see if your Atlas population Mode is set to Dynamic OS for the Atlas population Mode or if it is set to Static.


    Second thing is might check out the Localization Package and see if anything there helps you.


    Out of curiosity what things are you worried about being deprecated in the new Text Core System.
     
  47. Ukounu

    Ukounu

    Joined:
    Nov 2, 2019
    Posts:
    209
    Unity correctly displaying any random text in any random language out of the box, without any additional set up. Which I have explained in detail above already.
     
    Unifikation likes this.
  48. Jonathan-Westfall-8Bits

    Jonathan-Westfall-8Bits

    Joined:
    Sep 17, 2013
    Posts:
    252
    Okay just making sure there wasn't any other feature that might need to be looked into.
    I gotten so used to using text Core and UI Toolkit sometimes I forgot the process of the older UI tools.
    Wanting to make sure I didn't forget anything important.
     
  49. Unifikation

    Unifikation

    Joined:
    Jan 4, 2023
    Posts:
    1,079
    If it's working well for you, you're probably using a subset of the former abilities that's compatible with what's there.
     
  50. andyz

    andyz

    Joined:
    Jan 5, 2010
    Posts:
    2,251
    Any plan to fix the lack of pixel snapping that is there for UGUI but is inconsistant for small text rendering meaning a 1 pixel change in height (Text label, or window for deep nested text) can make it look worse or at least render quite differently?!
     
    Unifikation likes this.