Closed Cultrarius closed 7 years ago
Thank you for reporting this. I think I fixed it just now.
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.
Please link the exact input where this happens. The one you posted earlier behaves correctly for me.
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);
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).
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.
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.
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.
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:
The result looks like this:
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: