TextMesh Pro Feature request: optional automatic creation of fallbacks if characters don't fit in atlas

Facts:
We can create new font assets from code automatically, and TMPro automatically adds characters to fallbacks if they can't fit in the main asset and there are fallbacks present.

Problem:
Those fallbacks have to be created beforehand, without us knowing if they are needed or how many will be needed.

Workaround:
Manually create - or from code on startup - a reasonable 2 or 3 1024x1024 fallbacks for each font, since atlases stay at size 0 until really needed. However, this seems cumbersome to prepare (either have custom code creating fallbacks on startup or have many dummy font assets in the project to serve as fallbacks).

Solution:
TMPro doing this for us.
I would like to suggest adding a checkbox and atlas sizes below the fallback list:




This way we could define that fallbacks should be automatically created with a certain size.

This would make the use of the Dynamic SDF require even less setup from users.

Please let me know what you think, Stephan, and what limitations/conflicts you see. And thanks for all your work on TMPro.

Best regards,
Daniel

 

Just letting you know that although I haven't replied until now, that I did read / see this post last week.

Right now I am leaning towards finishing adding support for Font Assets to use an Array of atlas textures. These atlas textures will all be of the same size / settings.

If you take a look at the Glyph Table, you will notice glyphs have a Atlas Index property which is 0 right now but will ultimately point to the index of the atlas that contains the glyph.

Similar to your suggestion, it will be possible to define (per font asset) if additional atlas textures should be created when the current atlas is full.

 

Ah, that sounds even better since it's done on the same font asset. Avoids possible mistakes when inadvertently using different settings per fallback.

Will the additional atlases be able to have a size different to the original atlas? I ask because our default atlas for Chinese is small at 256x256 since we don't expect Chinese characters when the app is not in Chinese (just the ones for the language name), but when additional atlases are created dynamically (when the language is actually Chinese) they would almost surely need to be bigger or we'd get 20 atlases.

Cheers!

 

Hi @Stephan_B, I know it has been a long time but is there any chance TMPro can have what I described above? i.e. The auto-generated fallback atlases (textures) having a different size from the default atlas.

We are now using 2.1.3 and noticed the new options:


But sadly this doesn't address the use case above. Maybe there's a technical limitation for having different sized textures...?

Thanks!

 

Multi Atlas Texture should address your use case other than you would still need to create / assign those fallback prior to build.

Having Multi Atlas Texture enabled means new atlas textures will be created as needed. These textures will be the same size as the size defined in the Generation Settings of this fallback.

The Clear Dynamic Data On Build means they will be reset back to zero size so this fallback is empty and thus not contributing to build size.

This means you still need to create and assign these dynamic font assets as fallbacks to your primary font assets or global fallbacks but with multi atlas texture and clear dynamic data on build, you only need one per as these can grow to essential handle every single glyph contained in the font file they reference.

Again, keep in mind that changes to dynamic font assets are persistent in the Editor but not in builds where these dynamic font asset will always revert back to their ship state at the start of each play session.

 

Hi @Stephan_B, thanks for the reply. I understand the new features but what I mean is creating the atlas textures with a specified size, so it could be different from the default size. But no problem, we were revamping our system to take advantage of the automatic atlas creation and I figured I'd ask this. We'll make do without that. Thanks!

 

The reason why the multi atlas textures are all the same size is so that we can take advantage of Texture Arrays in the future. This will result in 1 single draw call regardless of the number of atlas textures used by this font asset.

Note: Since this all pertains to fallback font assets, the size of their atlas can be different than the primary font asset provided the Sampling Point Size to Padding ratio is the same.

With regards to atlas texture size, it is a trade off between texture lookup speed which is faster for smaller textures vs. number of draw calls if you end up needing more atlas textures as a result of the sampling point size vs texture size being too small where you can't fit many glyphs in them.

For example, using a sampling point size of 90 with atlas texture size of 256 x 256 means that we can fit perhaps 10 glyphs in that atlas which will quickly result in more atlas textures getting created. On the other hand, if I increase the atlas texture size to 512 x 512, then I can fit a lot more glyphs in them.

In terms of texture size efficiency, 1024 x 1024 is sort of the sweet spot if you expect to need to handle a good amount of glyphs per play session in such fallback. However, if your sampling point size is smaller, then using a 512 x 512 might be best as the texture lookup will be faster on mobile and the cost of one potential extra draw call marginal.

It is all sort of a balancing act between all of the above. Just make sure you keep a consistent sampling point size to padding ratio so outline, dilation and other material property values results in the same visual appearance when using material presets.

 

Thanks a lot for the detailed reply and suggestions!

Ah, that is very good to know. It was one thing that worried us a bit when using fallbacks.

We are already using fallbacks with different sizes from the default, actually. I think TextMesh Pro is improving this workflow a lot.

We have a decent approach when any language is selected: all text components use base fonts that have dynamic fallbacks and we change the fallbacks of those base fonts dynamically based on language. We add all characters in the full translation for that language immediately when the language is selected (if the user later uses more characters in text fields, those are added at that point because the font assets are dynamic). If the chars don't fit in a fallback, we create a copy of the font asset as another fallback (the new dynamic atlases will replace this part).

Our main trouble right now is the menu where all the languages are displayed simultaneously in their respective sets of characters. Loading multiple large atlases that only have a few chars can be costly (hence the question of using a small 256 atlas for starters and then creating additional larger ones when selecting the actual language for the whole interface). But we can probably handle that with smaller font assets used just for that menu (or sprites for the names, which I don't like a lot).

 

With Multi Atlas Texture enabled, you should not have to use more than one dynamic font asset as fallback to those base / primary font assets. With Multi Atlas Texture enabled, the dynamic fallback will be able to handle all characters and glyphs present in the font file. Plus if these characters are coming from user input, there is no need to try to prepopulate the fallback since adding new glyphs is much faster than user in put / typing.

Are you using multiple fonts / font assets in this language menu?

How are you handling the resources for all these languages? For example, do you include all font assets for every language in the project / build or do you load those resources from some external source or bundle or something as needed?

 

Yep, Multi Atlas Texture solves that. I won't have time to revamp our system right now, but when I do fallbacks would be used only for the original purpose of having a backup if some char is not in the main font, not to fit many characters in multiple textures. Knowing that the multiple atlases might fit into 1 draw call in the future is also great!

The characters used in each of our apps/games come from a translation file. When the user chooses the language we create a set of the unique chars used in the translation and prepopulate the atlas of each font used in that language, adding all the characters to avoid hiccups later. We get a small freeze choosing the language, but never again.

User input may add to that, so we let it auto fill as required.

Yes. The language names are written in their respective languages. Right now it's only latin languages + Chinese, so not a huge deal, but with more languages like Japanese it would be costly with all the large fonts/atlases loaded in memory just for that screen (besides that probable temporary freeze). Creating special font assets just for the few characters that show up in the languages menu would be enough to fix this.

They are all included in the build and I expect we'll continue to do so. For the fonts to be dynamic we need the original .ttf files as well as the font assets, but that's expected.

As far as my original question is concerned, you have already justified why the atlases should have the same size, and I can see how to reimplement our system when I can, so all's well.