Mostly tweaking editors / clean up at this stage while trying to address as many reported issues as possible which helps me further test the new system and changes.
Planning on creating a new video in the next few days to cover key changes to Font Assets, Sprite Assets and their Editors / Inspectors. This will give me another good opportunity to further test everything as issues tend to surface when I am about 10 minutes into recording. Murphy’s Law always lurking around when recording videos or during demos / big presentations looking to trip you up
What great news! It sounds like it will be out soonish (at least, before I try to release MY app in January).
Quick question: after I download my translations.json file and compile my list of unique characters in it, I’d like to be able to put all those custom characters I want to render in one file, and then manually trigger the SDF to re-render with the same settings, and those characters. Is that going to be possible with this fancy dancy new dynamic system? I hope it will!
Sorry, the assertion that we know “all known characters” in a given game is silly. If you’ve worked on any large scale social mobile title, you know that ALL the characters will be used eventually. So I’ll reiterate the OP’s question:
How do you deal with getting all the characters in a font atlased without being an expert on Unicode character ranges?
Yet another reason Unity Text is better because of workflow, regardless of performance. TMP is a huge pain in my ass. I’d rather drop my fonts in a project and just USE them than deal with all this atlasing crap. I’ve spent HOURS today trying to get Japanese to show up on my screen.
You should know all the known text used in a given project. By known text I mean all the text in your menus, UI, dialogues, etc… that is everything with the exception of user input or dynamic data coming form some outside source.
You should know all this text because at some point this text will need to be provided to someone for translation / localization. BTW: Good localization tools usually have functionality to extract all the known text for the purpose of making it easy to provide to localization / translators.
Characters coming from user input or unknown external sources are handled by dynamic font assets most of the time assigned as local fallback to a primary static font asset or as global fallback in the TMP Settings. There are many other variants / potential way to structure this with the new Multi Atlas Texture feature but the key is dynamic font assets.
To handle CJK, create a dynamic font asset using the NotoSansCJK font and enable Multi Atlas*1 support on it and done. That is not the most efficient way since everything is dynamic where it doesn’t need to be but every single character in this font file will be displayed if it exists.
I realize that having to learn about Unicode or text may not be exciting but that is no different than having to learn about efficient modeling and how to create geometry or how to efficiently manage lighting / lightmaps, etc. or how to write good code. Text is another area where some expertise needs to be developed just like many other aspects of game development.
Of course, I want to make the system more user friendly and more intuitive but it remains important to learn / understand the details at some point just like it does in terms of programming.
*1 Multi Atlas support is available in version 1.5.0-preview.x for Unity 2018.4 or version 2.1.0-preview.x for Unity 2019.x or version 3.0.0-preview.x for Unity 2020.x
Its now become that for TMP. Quite frankly this workflow introduces unnecessary complexity. Everything is fantastic until it comes to fonts.
Right now i have a 136 MB Font asset just to support Japanese. I need ALL characters all hiragana, katakan, and Kanji characters. I managed to download a NotoSanaJP.otf and use the Font Asset Creator to generate the monstrously large font asset after including the hex codes for punctuation, katakana and hiragana.
I literally found no example of how to do this anywhere else. So I hope I did it incorrectly because 136 MB font asset is 0% usable in any game.
The NotoSansCJK.otf is about 5 times larger then the NotoSanaJP.otf so the generated file will be way larger. either way i don’t not have Multi Atlasing in my current version nor can i update right now. So i set my atlas resolution to 8192 this is the only way I can fit the characters in and it still looks bad
First in order to minimize size, your primary font asset should only include the Japanese characters known ahead of time in the project. Ie. only those in menus, UI, dialogue, etc. Everything else coming from user input or other sources should be handled dynamically.
This primary font asset could be static (best for performance) where you might be able to get away with a 1024 x 1024 or 2048 x 2048 (depending on the number of known characters, sampling point size and padding which for CJK should not exceed 90 point size and could still look good at 48 but you will have to test that). This primary should have a dynamic fallback with Multi Atlas enabled on it which should enable it to handle everything else contained in the font file. This dynamic fallback (at shipping time) should be Reset (via the context menu) to make sure it is empty with its atlas texture at size zero.
Note that changes to dynamic font asset in the Editor are persistent but not in builds. As such, these dynamic font assets get reset back to their initial state (empty with atlas at size zero) for each play session. This ensures that even with multi atlas texture enabled, these dynamic font asset won’t grow to some crazy size over time.
The NotoSansJP-Regular.otf is 4MB. Your static primary assuming 2048 x 2048 should be 4MB and then the dynamic fallback with Multi Atlas (0kb). With this configuration, the contribution to the build size would be about 8MB and be able to handle all the characters contains in this font asset.
Indeed. The key is making sure this dynamic fallback is Reset (if desired) before you create the final build as while working with it in the Editor (good for testing) it will get populated.
