(2022-12-14, 4:21)N. W. Perry Wrote: Is svg2ldraw the same as svg2dat? It could simply be that I had forgotten there were two different utilities out there. But now I am remembering that I once tried to use svg2ldraw and couldn't get past uploading the source file.First. It seems like my hosting provider is having trouble with the redirect. While I try to get through their support, svg2ldraw has been made available here (more reliable link for now)
Trying again just now, I have some better luck, and I can offer at least some thoughts/observations:
- As has been said before, the triangulation seems very non-intuitive: lots of spidery mesh with many very thin triangles, for example. There are also many extra vertices added, often at seemingly arbitrary places.
- Because of this, it wouldn't be as simple as converting 3 and 4 lines to corner points, because you'd also have to clean up the extra ones.
- So, I do think it would be good to return only the nodes from the svg file itself: endpoints of straight segments, and any nodes added to Bezier segments. Generating the mesh could be a user-selected option.
- Perhaps a more interactive way to adjust the interpolation of Bezier points? Would it be trivial to implement a slider? I'm also not quite sure what "points per 100 pixels" means in relation to LDraw—I would be thinking more in terms of either maximum angle between segments, or approximating the 16/48-sided resolution of curved LDraw geometries.
- The program does not seem to recognize inner rings of an svg path (for example, it renders the letter 'o' as a solid circle, not a hollow ring).
Can the program only handle whole files, or would I be able to copy the SVG code of a single element in Inkscape and work with that alone?
Here is a file I used for testing (change .txt to .svg) so you can see what I mean. In this file, most of the letter paths have already been hand-simplified in Inkscape, but any letters that are repeated have not (e, a, i, r, G). I used a setting of 200 to simplify the curves before I approached what I'd consider an acceptable resolution, which feels like a lot.
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.
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?
- 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.
- 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?
- "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 "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.
That is quite a list of change issues. Which one do you think is most important?
The code is in public domain. Anyone on the planet - and even off planet - is allowed to contribute to it. This should technically allow all issues to be solved extremely quickly.