Undesired results when parsing large SVG files

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!

Best

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.

Thanks vielzutun.ch for the reply.

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.

Let me know!

OK, your part5_not_rendered.svg contains 7 tags.

Each of which specifies 2 separate triangles (note the “Z” in the middle of each line):

I’ve gone through the first 4 <path> lines. I’ve split my findings into two Excel sheets, attached below.

Triangle 1 looks OK, ccw
Triangle 2 is a degenerate - all points apparently collinear.
Triangle 3 looks OK, ccw
Triangle 4 looks OK, CW!

Triangle 5 looks OK, ccw
Triangle 6 almost degenerate - all points close to collinear.
Triangle 7 looks OK, ccw
Triangle 8 seems OK, CW!

I’m beginning to see a pattern here.

svg.xlsx (25.3 KB)

3 Likes

Thanks for this analysis! :slight_smile:

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.

Best,

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 … :wink:

3 Likes

Can you try rendering it with material.side = THREE.DoubleSide and see if the missing triangles come back?

@vielzutun.ch awesome detective work! :slight_smile:

1 Like

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:

https://github.com/Jonathan-J8/threejs-svg-parser/blob/81e8b9a3481a957c04c8673d298c4ebcb5755bcd/public/part4_optimized.svg

Then just hit the Load button and wait for a minute or so if necessary (longer wait than this might have some uncaught error in the console).

2 Likes

I made a github page out the repo, like that anyone can test/debug svg files:
https://jonathan-j8.github.io/threejs-svg-parser/

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.

For example, from @vielzutun.ch’s analysis:

  • Triangle 3 is CCW (hole CW) → not rendered
  • Triangle 4 is CW (hole CCW) → rendered

I think it come from SvgLoader who interpret some triangles as holes instead of fill shapes. I have to dig into the source code to see that in action.

Have a look at this post re. “fill-rule” . I’ve seen “fill-rule” specifications in files of your repository.

1 Like