TextMesh Pro is now free and to be integrated

Short answer Yes. See my reply to your other post and this post on the TextMesh Pro User Forum

 

Hi Stephan !
I have a issue, I using textmesh pro to create ListView, background and text for item in listview is completed, but i need function load sprite from network, example: item in listview have a sprite background, string name and avatar downloaded from network.
Example: Sprite Background: <sprite=1> and Avatar: <sprite="http://www.demoapi.avatar_demo.png">
Thanks !

 

With the sprite tag you can specify the name of the sprite asset and index or name of sprite. For instance <sprite="Name of Sprite Asset" name="Sprite Name">. The sprite asset must be located inside of a Resources folder and at the location identified in the TMP Settings file which you can change.

So with the information above, you can reference any sprite asset and sprite contained within it. Then the next step is to dynamically add a new sprite asset or sprite inside of an existing sprite asset.

If the .png you are downloading contains multiple sprites, I would create a sprite asset that matches the layout of the sprite in this texture that will be downloaded and then at runtime, replace the texture that the pre-create sprite asset references by the new download texture. Provided the layout of the new texture / sprites contained within it match, it will just work as the sprite asset simply defines where the sprite are within a texture and how to align them in the text. The content of the texture is irrelevant to the <sprite> tag and functionality.

If this .png only contains a single sprite then it is trickier as you will still need to create a sprite asset ahead of time. Hopefully the sprite / textures you will be downloading are all of the same format / size and if so, you will then need to write these new sprites into the texture that the sprite asset is using.

Several TextMesh Pro users have done this in the past. The following post on the TMP user forum covers some of the information I have provided here.

P.S. I would suggest asking in the "Unity UI & TextMesh Pro" section of the forum if anyone has done this and could share their code or experience. Also posting in that part of the forum will help other Unity / TMP users search and find this type of information more easily.

 

Oh ! Thanks, I tested with with <sprite="Name of Sprite Asset" name="Sprite Name"> and worked
Now, I reading TMP_SpriteAssetImporter.cs to create TM_Sprite in runtime and add to spriteInfoList in TMP_SpriteAssets
I hope it will work
So, Thank you very munch !

 

You don't need to use the Sprite Asset Importer which is actually editor only.

A Sprite Asset is nothing more than a data structure that defines where certain sprites are located in a texture. When TextMesh Pro does its layout pass, it simply reserves a place in the text and creates a quad for this image / sprite using the information contained in the sprite asset for that given sprite. TextMesh Pro has no idea if the texture is empty or if whatever sprite or image at those UV coordinates is even valid.

Assuming the sprites / images that you will be downloading are all the same size, you would create a Sprite Asset as usual where the sprites / texture would be sliced using the Unity Sprite Editor in a grid matching the size of your images. This texture could be empty or maybe contains some placeholder sprites. Then at runtime, you would be adding these new images in the texture which is referenced by this sprite asset. To do that you would be using one of the Texture2D functions like GetPixels() and SetPixels() to read from the image you are downloading and then writing into the texture referenced by the sprite asset.

 

Huh, I wrote example code for GetPixel and GetPixel and worked, but I think, with texture have height and width size is 128x128 then I need loop while or for with 128*128, so fps is drop when I change or add texture.

 

Look at the other API functions like GetPixels or GetPixels32 which are more efficient.

Although reading / writing into a texture does have performance overhead, you should only be doing this once per sprite as you add them into the texture.

 

Oh. Righ now, I will try with GetPixels and GetPixel32
PS: Ok, when I change GetPixel and SetPixel with loop for to GetPixel32 and SetPixel32 then time reduced from 13ms to 5.65ms
I will back to ListView code and test with 1000 item
Thank you very much !

 

Hello !

For some fonts Text mesh pro does not work with content size fitter.
some part of character over flow.

it might be potential bug.

1- Created Textmesh pro UGUI.
2- Assign "Bangers SDF"(built in) font asset.
3- set metrical preset to "Bangers SDF Drop shadow"
4- attached content size fitter with horizontal and vertical fit = preferred.





please check K is Overflowing


if its not bug please tell how to make it work.

 

Preferred Width is calculated from the xOffset of the first character to the xAdvance of the last character. Word wrapping also uses this xAdvance position to determine if a character fits in a line or not.

For most fonts, the xAdvance position ends up after the glyph. However, in the case of Bangers, whoever designed the font decided to have the xAdvance result in these characters / glyph overlapping.

So from a word wrapping and preferred width calculation, what you are seeing is correct.

Note:
The bounds of the text which can be checked via the TMP_Text.textBounds property represents the bounds based on the font metrics which is from xOffset to xAdvance and top Ascender to lower Descender.

The mesh bounds which can be access via the TMP_Text.bounds property represents the bound of the geometry of the text which in the case of the image above would encompass the whole letter K and shadow.

 

So its coming to the that full year, and I imagine the integration project started...

Is there any news on how that is going? Kinda getting a little annoying that I'm still using ugui components that always need the default text component gutting out for tmp ones (TMP only has the text, dropdown, input default prefabs done and has been hardly anything new or improved since last year).. plus I still get minor layout/prefab saving bugs that don't seem to happen with the original text components like rect position changing or not saving properly, and whenever tmp added to components always to have some weird negative values (new projects with fresh tmp versions tried.. maybe i'll submit a bug even though tmp is still not officially in the engine).

Anyway what I really want to know is are we going to see this integration happen anytime soon 2018.1? .2? .3 :// ? Because it would be about time we have proper TMP replacements for Buttons, Toggles etc and other projects like the ugui extensions had integrated replacement so all the old text components can be thrown out for tmp ones already. (as you already know things are a little messy with the asset store tmp being dll crap and the old one having source files which can be preferable....meaning projects like ugui extensions can't just easily support one version for everything as they do with the default built in text component.. )... soo how far away is that still?

 

As per the following post there will be a new version of TMP included with the Unity Editor in 2018.1 (expect to see it with beta 3 or 4).

In terms of your feedback about buttons and all, we can't replace UI.Text by TMP simply because of legacy and other users still using UI.Text. Should we consider adding additional options in the UI - Create menu for each option that uses a text component and have a TMP version listed?

In terms of the Prefab and RectTransform issues, that is a known bug affecting many UI components including TMP. This is not a TMP bug but as usual exposed by TMP. There are several posts about this in the "Unity UI & TextMesh Pro" section of the forum with additional information and updates.

I have made a few posts about the new text system. Here is one of them. As per those posts, I am still working on the new text system but no firm ETA yet.

 

That sounds like a great idea/option. I think it would be cool to even have 1 further option, and that would be a preferences toggle (perhaps?) where a user could choose: Both, or Exclusive: Text / TMP. (thus, hiding the other if an exclusive is chosen*)

 

All I can say is that there should be an immediate shift to using TMP first in all and any menu options with a swift marking of depreciated for all legacy text.

The only reason anyone would not be using TMP right now is because they don't know about it I think. Why else would people refuse a clear quality boost for same performance?

So be a bit forceful about TMP, put it in the primary positions of exposure.

 

Yes that is what I was getting at.. and would be very useful to have more TMP premade components added in, I always feel like maybe I should make this a default prefab button/toggle etc once setting it up with TMP, but then its not going to be in the same context menu as rest of the ugui component defaults etc.

Will TMP get any future features to make handling other languages ..alot easier.. or text packs that are setup for it.. I have a project where alot of ugui stuff is already setup with language support and unfortunately it uses the old text components for those areas simply because it just works for all the languages. Where as TMP needs this entire somewhat messy art of.. 1) finding fonts that have the character support with the languages and letters required, and then 2) learning to set it all up... I think that this is an area that should be improved with this going to be integrated, as it still the one area where the old ugui text component ..just works.. which yknow is what is ideal if font quality wasn't an issue. So it should be more streamlined with perhaps another way selecting the language supported needed for some key default fonts.. some simple quality controls/performance/size tradeoffs etc.. but nothing like this technical font language setting up process..it needs a setup wizard... leaving in the advanced option of going in to fine tune things still though

I'd agree, but as mentioned the one area where the default text component still has a very valid use is the multi language handling just works.. even if it does look blurry and not very crisp in some use cases. I'd be fine with blurry and not very crisp for all other non English lettering if TMP just handled that stuff on detection and worked for all other languages aswel though Bonus if a variety of fonts could be found for it that are all guaranteed to work.

 

Could the existing text component have an option to use SDF or not? To me that would be nice. Or better yet, allow us to drop in a font asset and it figures out whether to use SDF of old-style itself. I know it would require some additional work, but since you're adding this natively (and I'm not familiar with it ) I see no reason for them to be handled completely separately - can the SDF stuff not be strictly a superset of the old method in terms of its code / Inspector interface?

If not then sure, have different components with their own listings. Persinally I'd prefer "Text - Raster" and "Text - SDF" than having a brand name in there, though. If it's natively integrated then there's no need to highlight that it once was a separate thing.

 

The TMP Text components can already use different types of font assets. Currently these can be bitmap or SDF but nothing would stop us from supporting other types down the road.

The existing text components will eventually fade into the sunset. Even the TMP components will eventually be replaced by new text components designed to leverage the added functionality of the new text system. As I have stated before, I continue to be mindful of the fact that we will need to transition to these new components and want to make sure we provide as smooth as possible transition without having to give up functionality.

 

The new text system will include a hybrid dynamic font system which similar to the legacy dynamic font system, will allows users (developers) to set Font Assets as static or dynamic. When set to dynamic, the system will be able to get glyph and character data from the source font file, raster and add new glyphs to the font asset and font atlas texture at runtime. Just like with the legacy dynamic font system, this process does result in potentially significant performance overhead. When set to static, the system will not do anything to the font asset and as such this will provide for best performance.

The new system will be different in that it will enable users (developers) to populate their Font Assets while working in the Unity Editor where these additions can be made persistent. You will still be creating your font assets to define the source font file, settings and characters to include. However, unlike today these font assets could be left empty or partially populated where you expect to finish populating them while developing and / or testing your project / game or be assigned as fallback to other now static font assets where these will be used as catch all in release version of your project to ensure any missed characters can still be displayed.

The main idea behind the new system is to

(1) Provide best possible performance and quality which will always come from creating these static resources ahead of time.

(2) Make it much easier to populate these font assets while working on your project. Provided the character(s) you are requesting (typing) exists in the source font file, the font asset is set to dynamic and there is room to fit the new glyph in the font atlas texture, it will just work. Make it so you don't have to learn about unicode yet () New users / developers won't even have to know (initially) what is going on behind the scene.

(3) Provide for a flexible fallback system that can use static and dynamic font assets where developers (you) have complete control over what gets added, when, from which source font file and in which font assets using some predefined settings. Ie. I am not a fan of missing glyphs coming from some random font file that you had no idea was even present on some device or platform.

This new font system is actually fully dynamic where you could create a font asset which is empty and let it get populated at runtime by the end users. Although the system will be able to do it, it doesn't mean you should use it that way. My recommendation and the goal is to have font assets that are static which include the bulk if not all of the characters used in your project. This will ensure best quality and performance. Then for those few characters that were overlooked and coming from user input, they will be handled and added into fallback font assets set to dynamic. Although there will be that performance cost, this should mostly / only happen in conjunction with user input which is slow (humans don't type that fast) and as such should hide this performance cost and provide from a smooth end user experience.

Quote from one of my previous post ...

 

Well that does sound much better.. the performance cost is just one time right.. per new character shows up? cached for the duration of the running game/app? So not really a performance hit at all barring the initial first time hit per character?

yeh that wouldn't be great, especially if you never even get to hear about it happening from end users who just thought you were terrible at using a consistent font for things.

Well if its only checking that stuff based on those characters being used in TMP component in editor, for the most part that is likely only going to be English...as the other language translations are swapped in during runtime so yeh will there be some way of showing it some file(s) that have translations that it can use to make sure most stuff is generated for the build. Without having to fill TMP text components with all these translations just for the sake of making sure the system picks up on it?

Well I'll try it out anyway, it sounds better than how it works with supporting dynamic font stuff now.

 

I am assuming that before your project / game is released, that it will go through some testing and QA where in some Unity Editor session someone will be looking at the text for the languages you are planning on supporting. Besides checking for possible rendering issues, you should also check for layout issues. Some of those German word are pretty long Basically over the development / testing and QA process, you should be able to get pretty much all the text / characters covered. Then even if that did not happen, the system would be able to handle it with the performance cost which would happen anytime it runs into a character that isn't already included in the assigned font asset or any of its fallbacks.

It should work smoothly and make the process of populating these font assets much simpler. It is a hybrid system in the sense that instead of relying 100% on dynamic, it will shift the balance where hopefully the bulk of the text / characters will be contained in static font assets and the dynamic part of the system used mostly for characters that were overlooked in conjunction with user input.

P.S. At some point in time, it could be cool to see if we could use the Analytics system to perhaps capture this glyph / character data.

 

Hi Stephen, this new system sounds really great and I'm definitely looking forward to it! Can you provide an ETA or general timeline for these new features?