Text containing line width is wrong, so the box continuity is broken. This is due to the space between the two words. If I wrap the space in <mspace=0.6em> , everything is fixed. Why does the space character have a different width than other characters?
I found the mspace around space char workaround, but that’s pretty annoying to use everywhere I would also like to at least understand why this is happening.
I’m using Distance shader Glow effect. Looks amazing, but I need to change the blending method I suppose? So that the border lines look seamless. What would be the best way to solve this?
Thanks for the quick response.
Demo project demonstrating both issues is here (google drive).
Everything you will need is located in the /Assets/DEMO/ folder.
Versions: Unity 2019.4.18f1, TMPro 2.1.3
Should have included a demo project right away, sorry for that
@Stephan_B
Also I noticed one more issue (in our main HDRP project where we use world space canvases).
When I move further away from the canvas with the ‘Glow’ effect enabled and Glow Power being large enough, I see the following artifact on all characters:
If I move very close to the canvas, the issue disappears.
Notice how some characters have their entire “quad” glowing a bit.
This problem only goes completely away when I set Debug Settings/Sharpness to 1. That solution seems weird though, because it involves using a debug setting.
Thank you for providing the reproduction project which as usual, this made it easy for me to identify the source of the issue.
As it turns out, your primary font asset “FiraMono-Regular SDF” does not including the space character (0x20). As such, the LiberationSans SDF font asset which is the default font asset assigned in the TMP Settings is used as fallback for this space character.
Since LiberationSans is a proportional font whose space character has different metrics, you end up with that spacing issue.
Adding the space character to your FiraMono SDF font asset resolves the issue as seen below.
Adding this space character can easily be done by switching the font asset to dynamic while the text object using these characters is in the current scene. This results in the space character being requested which then get added to the character and glyph table of your font asset.
Adding new characters and glyphs in this fashion is not always possible as the atlas texture of static font asset is usually full but in the case of a space or any other white space characters which have no visual representations and thus do not need to be added to the atlas texture, we can always add them via this simply trick of switching the font asset from static to dynamic and then back to static after the characters and glyphs have been added.
In terms of the visual artifact, it is the result of the Glow Outer range being 1 where 1 is at the extreme edge of the adjacent glyphs in the atlas texture.
To resolve that, I would recommend using a smaller Outer Range value. It is important to understand that the ratio of sampling point size to padding determine the effective range of material property values like Outer Range for example. So if using a value of 0.75 doesn’t give you enough range then simply increase the ratio.
I would also recommend reducing the sampling point size from 201 to something like 90 with padding of 9 (10% ratio) or slightly larger padding to get larger ratio to get more range on the glow if needed.
I would also recommend reducing the atlas texture size to 1024 x 1024 which should be big enough to fit all those glyphs at the smaller sampling point size. This will reduce the memory overhead of this atlas texture and build size. If you can’t fit all the glyphs into a single 1024 x 1024 at this sampling point size try reducing it and enable multi atlas texture. 2 1024 x 1024 is more efficient than 1 2048 x 2048.
EDIT: All 141 characters and glyphs contained in your font asset fit in a single 1024 x 1024 with Sampling Point Size of 90 and padding of 12.
How could I not notice the space character is missing?
Thank you @Stephan_B for spotting it for me.
Also thanks for all the other tips - implementing these truly helped in getting rid of the last mentioned artifact.
One issue still remains however (one I mentioned in my first post in this topic, pardon me for cramming multiple issues into one topic ). Glow blending as seen here:
It seems to be additive, but in my case that breaks the border continuity. Is this possible to solve?
I just want the border to look like one continuous “pipe”. And then the glow to appear just in the inner and outer areas, not over other characters.
Maybe this will not be solved by simply changing the blending code, but by rendering all glow before any characters are drawn? Changed blend mode should help with overlapping glow and rendering glow before characters should eliminate the glow overlapping characters part of the issue?
A few more additional details to my previous post:
This glow blending problem I’m trying to solve is visible in the repro project I linked earlier in this thread
We intend to use this in our main, HDRP project (So I will have to modify the only SDF shader that works in HDRP ATM. Is it going to be possible to somewhat easily backmerge all changes that will be necessary to the SDF Surface HDRP shader when it comes out? Because we intend to mainly use that one after that.)
Right now I am focused on releasing the next version of the TMP package. Once this is done, I am switching to the UPR / HDRP shaders which indirectly should give us more options to deal with the blending on glow.
P.S. Trying to release the first beta of these shaders late this week / early next week.
I updated to the latest version of TextMesh Pro (there was an update that I believe is the one you mentioned in your previous reply), but TMPro Surface shader is still producing deep pink results for me. This is unrelated, just wanted to ask if surface shaders were supposed to be included?
I also updated to the latest version of HDRP.
More importantly though - do you now have some spare time to look into the glow blending issue?
Do you think the glow blending solution could make it into TextMesh Pro package version compatible with Unity 2020?
We plan on releasing our game on that version
I would also like to at least understand why this is happening.
