Corners bleed out when generating distance field about msdfgen HOT 8 CLOSED

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

from msdfgen.

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.

from msdfgen.

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

from msdfgen.

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);

from msdfgen.

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).

from msdfgen.

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.

from msdfgen.

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.

from msdfgen.

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.

from msdfgen.