(2022-12-14, 6:48)Lasse Deleuran Wrote: It seems like you ran into This issue back in 2019. It is a shame I was not made aware of it in 2019 - then I could have prioritised getting scientific notation in path commands to work back then.
It was later in 2020 when I ran into it, but true that I did not recognize it as being the same issue. But now it makes sense!
Quote:To your points
- There is no triangulation. The decomposition consists of convex polygons. The convex polygons are then split up into mainly quads, and then possibly a single triangle to complete the split of a polygon. If a polygon has many points right next to each other, then thin quads will naturally occur. The only way to avoiding that would be to introduce Steiner points. Is this desired?
The .dat file I get from my test file has an almost equal number of tris and quads (683 to 774). I'll attach the .dat so you can see what I mean. It does seem that adding points along the edge of the pattern would help, and yes, that is recommended by part reviewers.
Quote:- There should be no "extra" vertices added. The LDraw file format consists of simple straight-line primitives, whereas the standard SVG standard contains arches, circles and other non-straight-line objects. The software attempts to approximate these non-straight-line objects using straight lines.
Yeah, for some reason it did add a lot of extra vertices, both along what should otherwise be straight edges, and also in empty space between the paths. See:
Quote:- Having a toggle for no "mesh" could be added. What would the output be, if only the points should be present? line type 2 with both points the same?
I envisioned this as an LDPE extension, so I convert the path nodes to LDPE vertices (the 0 !LPE VERTEX meta). But type 2 lines could also be an option (regular lines though, not degenerate ones—basically just a wireframe of the paths).
Quote:- "points per 100 pixels" is from svg, where svg works in its own scaling system. This is from before convertion to LDraw. Perhaps I should move the input field up to avoid confusion. Having a slider would be difficult to implement, as it would have to slide between 0.0001 and 0.0002 for some input files (such as those that need scientific notation for their points) to between 1000 and 1010 for those who have designed their SVG file to be big. But there are also SVG files with both big and small curves - but only one parameter to handle them all.
Going with the "angle change" approach might solve this issue. I would just have to make binary search on the curve conversion in order to get the right amount of points. Then a slider might also work, as the range is manageable.
The more I think of it, the max angle approach seems to make the most sense, because the number of points needed depends on the steepness of the curve. Not every segment will need the same number of points, and so a raster-based method will inevitably provide too many points for very shallow curves, and/or too few for very sharp ones. This would also remove the need to choose a different precision per segment, and the 16/48-segment geometry of our circular prims doesn't really apply to Bézier curves (which cannot be circular anyway).
Quote:- The "ring" issue is annoying. It appears that Inkscape generates paths within paths, and this should flip the colour. That feature is not yet recognized. To avoid this for now, the "holes" can be made in a separate colour in order to force Inkscape to output standard paths.
Yes, in this case I believe the rings are subpaths of the larger letter. But you can also break apart the path in Inkscape, which would make the rings a truly separate path from the outline.
Quote:That is quite a list of change issues. Which one do you think is most important?
Thanks for the thoughtful reply. :-) Of course I was envisioning a more or less totally new tool, so this was not meant to be an actual request for all these changes! To me the most important would be converting path nodes to simple points (and/or type 2 lines), followed by maybe the angle-based interpolation method. If I have an accurate set of vertices, I don't really mind building the mesh myself, since I find that most mesh-generating tools require some manual refinement anyway, and it's often just as easy to re-draw whole sections.