Chlumsky / msdfgen

Multi-channel signed distance field generator
MIT License
3.97k stars 412 forks source link

Corners bleed out when generating distance field #34

Closed Cultrarius closed 7 years ago

Cultrarius commented 7 years ago

Hey,

I have a problem when trying to convert SVGs into distance fields with your project. Very often, the corner or "end points" of the SVG paths are bleeding out into the distance field, as if the shape intersected itself at that point. The source SVG file can be found here: http://tiny.cc/3524iy

See the following simple shape as an example:

teardrop

The result looks like this:

teardrop_msdf_result

The problem, as you can see, is the hole in the lower left corner, which will be rendered filled as the shape itself.

No matter what options I use, the result it always the same. Could you please tell me what the problem is and how I could mitigate it?

Making the corner "smooth" by moving the fourth control point of the bezier curve around creates a good result, but it also substitutes the sharp corner with a round one:

teardrop_msdf_result_good
Chlumsky commented 7 years ago

Thank you for reporting this. I think I fixed it just now.

Cultrarius commented 7 years ago

Thank you for the quick response!

The shape is rendered correctly now, but only if I use the generateMSDF_legacy function; if I use the new generateMSDF function it creates just a black output.

Chlumsky commented 7 years ago

Please link the exact input where this happens. The one you posted earlier behaves correctly for me.

Cultrarius commented 7 years ago

I parsed the svg myself into cubic segments and did not use the SVG importer from your project, so maybe that is why it works for you. This is the test case for the above teardrop shape (I hardcoded the edge values):

Shape dfShape;
Contour &contour = dfShape.addContour();
contour.addEdge(new CubicSegment(Point2(258.599060, 396.484863), Point2(269.933899, 386.063660), Point2(410.555725, 323.508911), Point2(117.682785, 187.383301)));
contour.addEdge(new CubicSegment(Point2(117.682785, 187.383301), Point2(117.682785, 187.383301), Point2(199.505142, 441.436646), Point2(258.599060, 396.484863)));
contour.addEdge(new CubicSegment(Point2(258.599060, 396.484863), Point2(258.599060, 396.484863), Point2(258.599060, 396.484863), Point2(258.599060, 396.484863)));

Vector2 scale(1, 1);
Vector2 translate(0, 0);
edgeColoringSimple(dfShape, 1, 0);
Bitmap<FloatRGB> msdfOutput(512, 512);

// this works fine
generateMSDF_legacy(msdfOutput, dfShape, 5, scale, translate);

// this just fills msdfOutput with -infinity for all values 
generateMSDF(msdfOutput, dfShape, 5, scale, translate);
Chlumsky commented 7 years ago

In the code you posted, the last edge segment has the exact same value for all points. My program won't be able to deal with such an edge, because it for example needs to compute the direction of edges at their endpoints. I would argue this qualifies as invalid input, but maybe I should be trying to identify and remove these during shape normalization (which you didn't call anyway).

Cultrarius commented 7 years ago

Interesting, thanks. I thought that maybe the last edge was a problem.

I would suggest not removing it during normalization (unless you would replace it with a working equivalent), but to check for such a case in the validate() method. I could open a pull request if you want to.

Chlumsky commented 7 years ago

The thing is that we are dealing with floating point numbers, so more often than not, they might not be exactly equal, but maybe differ by a tiny fraction, and then I can't detect it. I can't just reject any vertices that seem "too close", because it could be intentional. That's why I think it should be up to the caller to provide a valid input.

Cultrarius commented 7 years ago

That's why I think it should be up to the caller to provide a valid input.

Exactly, but your validate() method should reflect that - if the input is valid or not.

And it is in my opinion absolutely OK to reject vertices in the same edge that are closer than a very small delta (which can also be zero), as such input usually only leads to problems with later calculations and rounding errors.