When parsing complex and large SVG files (> ~20 MB), I encountered several undesired results, as shown in the screenshot. These issues seem to concern <path/> elements, as far as I can tell.
I’m not entirely sure of the root cause—whether it’s:
SvgLoader failing to parse these elements correctly,
a clockwise/counterclockwise path issue, or
an issue with the SVG path data itself that makes it unsuitable for this use case.
In this repository, I’ve isolated some specific parts of complex SVG files that produce these results. Additionally, some of the SVG files in the repo have been optimised using the svgo library.
Logically, SvgLoader should ideally handle these edge cases as browsers do.
If this is not the case, please let me know—perhaps there’s a fix or workaround available!
Please isolate the issue into a single path that’s not being rendered correctly. “Clipping” away the non-relevant parts only visually isolates the issue, but still leaves you with 16 MB raw svg code. This is impossible to sift through.
As requested, I’ve added the part5_not_rendered.svg file to the repository and set it as the default.
This file isolates paths with a fill attribute that are not being rendered. The Three.js conversion to points (SVGLoader.pointsToStroke) works, but the conversion to shapes is not functioning as expected.
So, a fix would involve normalizing the winding order (CW or CCW) and removing degenerate triangles (collinear points).
However, even with those fixes, could the SVG paths still fail Three.js parsing? Or would that be enough to make them compatible?
I think there will always be artefacts that need to be fixed manually, though.
It may not be that simple. Both winding orders are legitimate in svg. Think of a shape having a hole in it.
As for the degenerate triangles: I assume, the author of the svg had a valid triangle in mind. It just came out degenerate. If possible, I would strive for correcting degenerate triangles, instead of removing them alltogether.
Sorry, I cannot vouch for someone else’s code or data …
You could also always use my SVG Viewer to load your models for a test.
This viewer uses SVG Loader by default but there is the TL button, in the top left corner, which allows to use Texture Loader instead. If both loaders can load the SVG file then you could see the differences between them. If only one manages to load it then try to rely on it.
On a desktop computer always try to rely on the browser console output for possible errors.
The picture of this viewer is attached below so try to hover the mouse over all buttons to get a popup description of what they do.
Probably the best choice for loading would be the URL button which reveals a text box where you can paste a URL to the model, like this for example:
Thanks @GitHubDragonFly for the sharing. You give me the idea to put the uploading file feature to this project as well.
@manthrax, no it is not seem to be a side issue but more a CW/CCW and hole/fill mismatch. When I convert path with path.toShapes(ShapeUtils.isClockWise(path.subPaths[0].getPoints())) (ShapePath.toShapes(holes Auto) in the gui controls) It fix some triangles.