Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Bleeding when using Bold and Underlay Effect

Discussion in 'UGUI & TextMesh Pro' started by xelanoimis, Apr 20, 2020.

  1. xelanoimis

    xelanoimis

    Joined:
    Oct 29, 2013
    Posts:
    39
    Hi,

    I get a bleeding from the glyph above when using Bold the Underlay Effect with Offset Y = -1.

    If I reduce the Offset Y to -0.8 or less, or if I remove the bold option, the issue is no longer present.
    Also it depends on the position on the screen. Like filtered sprites mapped too close to other things in the texture.

    Check above the 'T' character from "Short" in the picture below.
    upload_2020-4-20_19-56-22.png

    upload_2020-4-20_19-59-13.png

    Above the 'T' glyph in the atlas there's the '_' and I think that bleeds in.

    I also had to adjust some parameters for the font, because by default it was not well aligned, like Ascent Line from 27.00195 to 42. With the original values, this issue was not present, but the font was displayed too high. Anyway, I thought these values (like Ascent Line) are just placement options and they are not used to sample differently from the texture.

    More of my params:
    upload_2020-4-20_20-2-1.png

    upload_2020-4-20_20-24-20.png

    It happens in an empty scene with just one text.
    I can attach the font asset if needed.

    I can live with an offset of -0.8, but I just wanted to know if this is a bug, or if I have missed something.

    Thank you!
    Alex
     
  2. xelanoimis

    xelanoimis

    Joined:
    Oct 29, 2013
    Posts:
    39
    Unity 2019.2.12f1
    packages says TextMeshPro 2.0.1 (up to date)
     
  3. Stephan_B

    Stephan_B

    Joined:
    Feb 26, 2017
    Posts:
    6,595
    The effective range of material properties is defined by the Ratio of Sampling Point Size to Padding. In the case of Underlay for example, this defines how far the underlay can go at a value of -1 to 1.

    As values get near -1 or 1, you are effectively at the edge of the adjacent characters and can potentially see this bleeding. Although some logic is used in the Material inspector and shader to limit the range to valid values to prevent such "bleeding" or the material blowing up where the text turns into a blocks, it is generally a bad idea to use those maximum values.

    When you find yourself using material property values approaching these maximum values of -1 to 1, it is an indication that your ratio of Sampling Point Size to Padding is too small. The solution is to regenerate the font asset to increase this ratio.

    A ratio of 10% is typically fine where a good balance between sampling point size (quality) and padding (range of those material properties) is achieved.

    When creating new font assets, think of how they will be used. Will it be used to mostly display plain text without any outline / shadow / etc. or will it be used to titles with large outline and shadow. This will ultimately determine how you want to balance sampling point size to padding ration. For plain text, a smaller ratio will maximize sampling point size. For titles and big text with visual FX, a larger ratio will give you more effective range but since this padding is larger, you will have to either reduce the sampling point size or have fewer glyphs in the atlas texture.

    P.S. Latest release of TMP is version 2.1.0-preview.8. Preview 9 will be released later today or tomorrow if I run into any unforeseen issue in my final testing today.
     
  4. xelanoimis

    xelanoimis

    Joined:
    Oct 29, 2013
    Posts:
    39
    Thank you Stephan, for your answer. For now, I'll just reduce the Underlay to a 0.8 to get rid of the issue. I would regenerate the font with more padding, but I have this feeling that at some point I tuned some glyph offsets to look better spaced - cant remember which ones, nor the original parameters the font was build with.

    As for why the bleeding happens, I'm curious why the underlay effect causes it. I understand why a bold or border effect could cause it, but I thought the underlay is just a redraw (or pass in shader) of the same original glyph, with a flat color, at a shifted position. If the original glyph has no problems, the "shadow" glyph should be fine too. If so it could be drawn as far as you want. But maybe there's more to it and behind the hood it's not a redraw. Would be interesting to know the cause though. I've worked on a Font library myself years ago, using FreeType, but not with distance field shaders.
     
  5. xelanoimis

    xelanoimis

    Joined:
    Oct 29, 2013
    Posts:
    39
    I've looked into the shader and got it.
    It's all in one pass (best for performance). The underlay just use the texcoord2 with the indicated offset from the original mapping. It gets very close to the upper glyph and, depending on the position on the screen, that may bleed in sometimes. Indeed more space around the glyphs would help.

    float x = -(_UnderlayOffsetX * _ScaleRatioC) * _GradientScale / _TextureWidth;
    float y = -(_UnderlayOffsetY * _ScaleRatioC) * _GradientScale / _TextureHeight;
    float2 bOffset = float2(x, y);
    ...
    output.texcoord2 = float4(input.texcoord0 + bOffset, bScale, bBias);
    ...
    float d = tex2D(_MainTex, input.texcoord2.xy).a * input.texcoord2.z;
    faceColor += input.underlayColor * saturate(d - input.texcoord2.w) * (1 - faceColor.a);


    Thanks, consider this mystery solved :)
     
  6. Stephan_B

    Stephan_B

    Joined:
    Feb 26, 2017
    Posts:
    6,595
    Glad you took the time to look at the shaders.

    They indeed only use a single pass where the ability to add outline, shadow and similar FX are a by product of Distance Field which involves a manipulation of the distance data. This is very efficient compared to multi pass.