TextMesh Pro - Advanced Text Rendering for Unity - Beta now available in Asset Store

WISH LIST:

  1. Do you know when you will have a TextMeshPro Input Field ready? Unity’s Input Field cannot be alligned in the middle, only upper. I hope this is fixed in yours.
  2. Is there (Or will it be ever) a way to count the culculated TextMeshPro (UGUI or not) text height (In a text with multiple lines) so that I can use this value on its RectTransform Height which is used as a Scroll Rect. I need this because when the TextMeshPro text changes to another language the Scroll Rect Image Height should change too with the correct new Height so that It will scroll correctly till the end.
  3. About TextMeshPro - Font Asset Creator. Will it be an option to get all multilanguage characters from the font at once? For us that we make game in multiple langages and we need it to have everything inside.

Thanks,

Revised Sprite Asset Editor Panel
Had to make changes to the editor as trying to display and scroll through a larger list of Sprites was insanely slow due to how the Unity editor handles the layout of items even if they are outside the scroll area. Now instead of scrolling through the items, they are displayed as pages.

I recently bought and started using this awesome plugin in my project. First I wanted to say that it’s such a good plugin and a must have. Thank you for making it :smile:

While using it, I encountered some issues:

  • When creating font asset, if the text file for character set has new-line character the font generator goes crazy and the resulting asset won’t work! This way I can’t use a localization file as input. It also writes to log everytime encounters a duplicate letter in the file. It would be awesome if there was an option to import all of the glyphs that the font supports (unity already does this).
  • TMPro_AdvancedLayout creates a lot of error messages when first attached. It has something to do with the ScaleCurve being null. Also the default scale of the curve is so small that at first I thought it doesn’t work at all!
  • I couldn’t make a new SDF font material for the asset I created (to set different parameters like bevel etc). I’ve seen you do it in the examples. I just can’t figure it out :wink:

Also, the first time font loads it writes a lot of debug info to the console… it’s so much that the impact was visible on the profiler. Good thing that I have the source code and could just turn it off myself :smile:

You are welcome and it is my pleasure :slight_smile:

Which version of TextMesh Pro are you using? I fixed several issues with the Font Asset Creator and I believe this one has already been fixed.

In terms of adding all the glyphs contained in a font, most fonts contain too many to do that. Unity’s dynamic font system add them as you use them dynamically. There are benefits to the system and downsides. However, adding dynamic SDF Font support which will offer the best of both worlds is on my list of things. I have made several posts in this thread and the Asset Store thread about this so you can look them up for more details.

That was (is) an experimental component which has been replaced by simple scripts in the latest beta releases as the underlying data structure has changed. These new demo scripts on how to add jitter to text or warp are part of the Demo & Extra Content package on the TextMesh Pro User Forum.

That might be warnings related to some missing glyph. If it is something else and are using the latest beta release from the TextMesh Pro User Forum, please post in the support section so I can take a look at it.

I bought the plugin a few days ago… so I think it’s the latest version 0.1.44.
Hmmm… I checked it again, the font asset creation bug happened once and then I couldn’t reproduce it again! But it add these 2 boxes to the font. I assume they are ‘\n’ and ‘\r’?

The latest beta release of TextMesh Pro with support for Unity 4.6 and the new UI is 0.1.46 B3.3 which is available to all registered users of the product on the TextMesh Pro User Forum. Once you have registered, you will find the latest beta releases in the “TMPro - Alpha & Beta Releases” section of the user forum.

There were a few issues with the Font Asset Creator which have been address a few beta releases ago. The two square rectangles indicate missing glyphs from the font. With free fonts, I often run into missing glyphs where instead of leaving them empty, the designer used this empty square glyph in their place.

The characters \n and \r are never rastered since they have no visual representation. I would cut and paste the content of your CharacterSet file into the Text Input to know which characters are actually missing.

I’ve noticed that you’re using IDs for sprite tags. Did you consider adding names for sprites for convenience, so you could reference a sprite by name, not by an index?
Also, any updates on the next beta release?
Thanks!

The ID’s are nothing more than the index of the sprite in the Array. My only concerns with using names is that it will make the text input box even more crowded and hard to read with all these tags. Using ID keeps it cleaner / shorter and also avoids potential typos in the names. The same would go for <font=1> when that gets in there too.

In general, I try to keep the tag short as the longer they are the more characters you have to iterate over to parsing the tags and text. Let’s see how things go :slight_smile:

I am hoping to get this next release out in the next few days but stuff keeps creeping up. However, I feel pretty good right now. The sprite feature which paves the way for the <font=xx> feature as well as required changing a good chunk of internal data structures.

It doesn’t bother me too much, and yeah, trying to keep it short and simple makes sense. It’s just that if you have a lot of sprites, like emoticons, you’ll need to constantly look up the index.

Speaking of emoticons, I used NGUI in my last project, which also had inline sprites, but instead of sprite tags, you would define specific character sequences, which would be replaced by corresponding sprites. One advantage of this system, that instantly comes to mind, is chats and input fields. If you want to add an emoticon to your chat message, you just type in the corresponding sequence and it gets substituted with an image. What do you think of this system?

That is certainly something to consider. I’ll have to think about the best way to implement that and where to add the filtering of the text input. I could see having the users define the character sequence in some list which would then be used to do character substitutions.

It’s not very clear to me from watching the video, are these ID’s generated automatically? To me it seems they are generated automatically. What happens when I add or remove a sprite from the atlas? Will removing a sprite from the atlas turn every sprite tag in my texts invalid?

Another thing is that numbers are harder to understand by just looking at the text. Text is most often written outside of Unity in some localization software where no TextMesh Pro live preview is available. While you still need a document that shows the image<>tag mappings for creating new texts, it’s easier to understand tags of existing text.

For example:

This item costs you {0}<sprite=9>. Press <sprite=10> to continue.

vs.

This item costs you {0}<sprite=Gold>. Press <sprite=Silver> to continue.

Oh see, there is an error! “Silver” should be “ButtonA” instead. Nobody could spot this error by just looking at the text when using numbers instead.

I would prefer a sprite/font tag system where I can specify a text rather than a number.

Just like for fonts, you will create a Sprite Asset from a texture which was sliced using the Unity Sprite Editor. This Sprite Asset will reference this texture as well as a list of those sprites as provided by Unity Sprite Editor.

The Index of the sprite is the ID which corresponds the index of the sprites that Unity returns. As you can see in the image below, the Gingerbread Cookie is named Unity “xmas_sticker_full_3” which is the name of the image / texture and _3 for the index of the sprite in the array. In the Sprite Asset, the ID of this sprite matches what Unity provides.

Using names when there isn’t many sprites in the atlas may work fine but when there are 850 sprites in a texture that is likely going to be a challenge. The other issue with names is that it is easy to misspell those names in the sprite tag whereas with ID you could get the ID wrong but it is still something valid.

I am not opposed to figuring out some method to make names work. You can name the sprites in the Unity Sprite Editor and when editing the texture to add new sprites, the information seems to be preserved including the order / index. My focus was providing the ability to mix graphics with the text, as we move forward, I am open to seeing what can be done to increase the manageability of those sprite assets.

I personally would choose the “emoticon” system over the sprite-tag system. This way, when you create the Sprite Asset, instead of specifying a name, you would specify one, or several character sequences.
By default every sprite would use it’s ID with some “escape characters”, for example: !1!, !2!, :15:, :100:, etc.
If the user wished, he could change the default sequence for a sprite to anything he likes: :candybar:, gingerbread_man, =xmas_present=, etc.

Thanks for your answer. As I understand, it seems it requires pre-baked atlases? We use a workflow where artists provide images as separate textures and we use the “Sprite Packing Tag” in Unity’s Texture Inspector to tell Unity into which atlas an image goes. We don’t use pre-baked atlases in the editor, we use them in builds only (Edit > Preferences > Editor > SpritePackerMode=EnabledForBuilds).

My concern is that it’s not guaranteed that a sprite always gets the same array index as we add and remove images from the atlas (as we add/remove the Sprite Packing Tag). My idea was that this issue could be solved by using either a custom name or maybe even the sprite name rather than the sprite atlas index, because the name stays the same unless you change it.

However, if this feature limited to providing a pre-baked atlas, I see that it’s probably not going to be much of a problem with changing indices. Unfortunately, it’s not the workflow we’re used to. We really like not using an atlas during development, and would like to keep this workflow.

We really like TextMesh Pro and the new mixed font/graphics feature is also very useful and appreciated, that’s why I would really like to see it working with our workflow too.

Any thoughts about this?

I think there is a need for both implementation.

For instance when typing “:” + “)” I would most likely want the smiley face to show up. So in this case those two characters should be associated with some sprite.

I also think that having the ability to specify <sprite=id" or <sprite=“name”> is also needed. Note the name part isn’t implemented yet as I need to think of an efficient way to parse the input to look up the matching “name”.

Does the artist provide individual images (png) for each sprite or do they provide different images (png) which contains multiple sprites?

I need to explore what information is available from the Sprite Packer. It doesn’t seem like you can get a list (array) of the sprites packed in that atlas. The sprites also cannot be tightly packed since the Text / Sprites for layout purposes are rectangles. The texture that contains those sprites isn’t an asset that you can reference so when typing <sprite=“Some name”> where do you look for that sprite texture / atlas.

There is also the issue of how do you allow tweaking of the offsets of the individual sprites and scale since the information doesn’t exists in the Sprite class.

After the first release, I’ll look further into whether or not the Sprite Packer could be used and if the API for it has all the functionality that would be needed.

Right now for the first release, you will have to create a Sprite Asset just like you create Font Assets which contain all the relevant information for the Sprites to be adjusted and displayed.

Our artists provide individual images for each sprite. Basically one icon/graphic per (sprite)texture. These individual images are set to TextureType=Sprite in Unity’s Texture Importer and by using the Sprite Packing Tag, we can tell Unity that we would like to have these individual images be packed in an atlas. Depending on the number and size of each sprite, Unity might create multiple atlases.

Maybe you don’t really have to, see my idea below.

I thought so. While it would be neat to have support for that, it’s not very important for me personally.

References to individual sprites in the project stay intact after Unity created the atlas. It seems Unity magically patches/replaces such references during play or build.

Here is how I picture support for both workflows could be implemented:

A TextMesh Pro Sprite List entry would have a Sprite reference, where users can drag&drop a Sprite from the project. Implementing support to automatically add all sprites of an atlas (one texture that contains multiple sprites) to the list should be trivial, so it’s little effort for the user to add 1000 sprites to that list and is pretty close to with what you came up already.

The ID needs to be stable. Maybe implement functionality to make that number only increase per added list entry, but never let it decrease. Once a list entry has been added, it’s guaranteed that this ID stays the same no matter what. Plus the list entry also needs all your extra data OX, OY, Adv, etc. I would probably get rid of the “Sprite Atlas” field in your TextMesh Pro Sprite Asset too, because it’s not necessary anymore and does not work with the workflow we use. Since you have references to each individual sprite, you have a reference to the atlas(es) automatically too (sprite.texture).

When the TextMesh Pro Sprite Asset is loaded/created, you setup your lookup tables, I guess you just need to calculate UV’s. The Sprite references are all patched by Unity and point to the atlas at this time, in case of 1) atlasing is enabled or 2) the sprite comes from a image that contains multiple sprites.

You use the rect, texture and textureRect properties of each Sprite to figure out the UV’s. (The texture property either points to the texture or atlas). Since the Sprite List Entry contains the ID <> Sprite binding, you should have everything you need at this point.

Your Sprite drawing code needs to handle if sprites in one text are not on the same atlas. If you have this code, it should automatically work with individual textures too.

Hope it makes sense.

I’m not sure what you referring to. What offsets and scale do you mean?

Hi,

Thanks for this amazing asset.

But I have one draw call by “TextMesh”. What can I do for this ?

Thanks !

Regards,

AB