[Question] Direct MSDF implementation

[Elzianor]

Hi!

I'm trying to implement your direct MSDF algorithm using the "Shape Decomposition for Multi-channel
Distance Fields" paper, p. 4.4.

I've generated the following MSDF 64x64 pixels texture:

Also I'm using the following HLSL shader to reconstruct glyph from MSDF texture:

float median(float a, float b, float c)
{
    return max(min(a,b), min(max(a,b), c));
}

float4 MSDF_PS(PS_OUTPUT_BASIC input) : SV_TARGET
{
    float3 dist = shaderTexture.Sample(sampleType, input.uv).rgb;
    
    float d = median(dist.r, dist.g, dist.b) - 0.5;

    float w = clamp(d/fwidth(d) + 0.5, 0.0, 1.0);
    
    float4 outside = float4(0, 0, 0, 0);
    float4 inside = float4(0, 0, 0, 1);
    float4 color = lerp(outside, inside, w);
    
    return color;
}

I'm just changed here mix to lerp because it is the analog from HLSL.

The result is the following:

As you probably can see the corners are not very sharp (and it is 64x64, not even 32x32 pixels texture).

I understand that without code review it may be hard to tell, but couldn't you probably point me where have I made mistake(s)?

Thanks in advance.

[Chlumsky]

Your generated distance field looks completely off, it's surprising to me that it even produces the correct shape. I would suggest comparing your code with the reference implementation.

[QuantumDeveloper]

Could you please point us to the direct msdf implementation? Just didn't find it in your repo.

[Chlumsky]

The entire repository is the implementation of the direct method only. No implementation of the indirect method was ever released publicly because it has no advantages over the other one. For example, the function at msdfgen.cpp:176 corresponds exactly to Algorithm 7.

[Elzianor]

Thank you kindly, I will try to compare mine implementation with yours.

[QuantumDeveloper]

@Chlumsky
Hi. Can you please say what is the difference between legacy and non-legacy functions (especially for direct method implementation)

[Chlumsky]

The legacy functions are the original implementation from the first version of the library. The reason I kept them in is mainly because it shows the entire algorithm in an nice readable form. The current (non-legacy) version is rewritten in a modular way using template classes, so that one common function template can generate all types of distance fields depending on the template configuration, but this somewhat obfuscates it and makes it look more complex than it really is. So to list all of the changes:

• Contour combiner template argument dictates how distances to individual contours of the shape are combined to produce the final shape distance. It also encapsulates an edge selector. When SimpleContourCombiner is used, contour distances are combined trivially as in the legacy version.
• Edge distance selector (template argument of contour combiner) dictates how closest edges are selected and which type of distance will be computed (PSDF, MSDF, ...), as well as the required pixel type.
• Finally, there is an additional optimization facilitated by the use of the ShapeDistanceFinder class template, which keeps an EdgeCache object specific to the edge distance type that stores partial results of the prior pixels and reuses them to significantly speed up the whole process.

So, in summary, when SimpleContourCombiner is used (which is the default anyway since Skia was added to the project), the output of the legacy functions should be the same but will take longer.

[Elzianor]

@Chlumsky
Thank you for the answer. Could you please also explain, why 0.5 is been substructed and then added again in your pixel shader?

float d = median(s.r, s.g, s.b) - 0.5;
float w = clamp(d/fwidth(d) + 0.5, 0.0, 1.0);

Thanks in advance.

[Chlumsky]

For traditional texture formats, the representable color values are within the [0, 1] range, but for a signed distance, we must also represent negative values. Therefore, the value 0.5 actually represents a distance of zero, values below 0.5 are negative distances and values above 0.5 are positive distances. To obtain the actual signed distance, 0.5 is subtracted. After it is then scaled, the value 0.5 is added again when evaluating opacity, because at distance 0, in the context of anti-aliasing, the pixel is right in the middle of the inside-outside boundary, so should be drawn with 50% opacity.