SVGLoader + Inkscape

Hello community,

first of all thanks for developing three.js, it is an amazing tool!

Today, I encountered an issue with importing paths from an SVG created in Inkscape (saved as “plain” svg). I use the approach as in this example:

My SVG contains rectangles and paths, but only the rectangles show up. Paths are not rendered and I am wondering why. I checked the SVG file and both rectangles and paths are contained.

Any ideas?

For my application, I want to extract geometry from arbitrary SVGs. The only option I see now is to load the SVG as texture. However, this seems less “elegant” then direct parsing of the SVG as geometry.

Can you please share your SVG in this thread? Besides, please try it with the latest dev version of SVGLoader since there was recently a bugfix in context of the “close path” command (Z).

Hey Mugen87,
thanks for the fast answer!

This is the SVG I am using:

   viewBox="0 0 378.29001 368"
         style="stop-color:#ff0000;stop-opacity:1;" />
           rdf:resource="" />
       d="M 7.0041363,-69.314933 V 295.07849"
       style="fill:none;stroke:#000000;stroke-width:10;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
       d="M 371.6304,-70.265668 V 294.12776"
       style="fill:none;stroke:#000000;stroke-width:10;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
       d="M 7.2369663,-64.973998 H 371.6304"
       style="fill:none;stroke:#000000;stroke-width:10;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
       d="M 6.915554,288.08599 H 371.30899"
       style="fill:#7f0000;fill-opacity:1;stroke:#000000;stroke-width:10;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
       style="fill:#7f0000;fill-opacity:1;stroke-width:10;stroke-miterlimit:4;stroke-dasharray:none" />
       style="fill:#ff0000;stroke-width:10;stroke-miterlimit:4;stroke-dasharray:none" />
       style="fill:#ff0000;stroke-width:10;stroke-miterlimit:4;stroke-dasharray:none" />
       style="fill:#ff0000;stroke-width:10;stroke-miterlimit:4;stroke-dasharray:none" />
       d="m 62.196638,23.218014 c 0.771511,2.073718 1.272807,4.271146 2.31453,6.221151 0.780697,1.461392 2.098027,2.560394 3.086043,3.888222 1.327353,1.783878 2.685053,3.552599 3.85755,5.443506 0.0025,0.0039 7.705444,13.980555 7.715101,13.997592 1.772566,3.126651 3.299199,6.419366 5.400573,9.331728 2.034996,2.820367 4.70281,5.11927 6.943592,7.776438 2.132954,2.529307 4.150138,5.156133 6.17208,7.776441 1.578873,2.046116 3.035523,4.18662 4.629063,6.221151 2.26484,2.891612 4.72332,5.627563 6.94359,8.554083 1.1265,1.484831 1.92756,3.206244 3.08604,4.665867 5.28142,6.654267 11.77865,12.649937 17.74473,18.663447 2.05737,2.07372 4.11473,4.14744 6.17209,6.22115 2.31453,2.33294 4.48022,4.82622 6.94359,6.9988 1.6649,1.46837 3.60038,2.59215 5.40057,3.88822 1.54302,1.8145 2.88127,3.82863 4.62906,5.44351 1.36704,1.26307 3.10432,2.04659 4.62906,3.11058 4.20698,2.93567 5.39963,3.49833 8.48661,6.99879 2.27511,1.51756 2.95542,4.25304 4.62907,6.22115 0.66084,2.87696 3.83926,2.86733 5.40057,4.66587 1.22118,1.40673 1.97335,3.17048 3.08604,4.66586 0.43643,0.58654 1.07736,0.99205 1.54302,1.55528 0.82318,0.99567 1.47771,2.12653 2.31453,3.11059 2.12433,2.49807 4.7938,4.52235 6.94359,6.99879 1.32265,1.52362 2.52314,3.15271 3.85755,4.66586 0.72488,0.82197 1.54302,1.55528 2.31454,2.33293 1.54302,1.55529 3.08603,3.11058 4.62905,4.66587 0.77152,0.77764 1.59606,1.50528 2.31454,2.33293 1.08435,1.24911 1.99204,2.64768 3.08603,3.88823 0.92582,1.04981 6.36497,6.26974 6.9436,6.99879 0.93676,1.18027 1.4148,2.67905 2.31453,3.8882 4.73404,6.36225 -0.11999,-2.21538 4.62906,5.44351 0.60956,0.98304 0.82457,2.20537 1.54302,3.1106 0.35924,0.45259 1.06455,0.45612 1.54302,0.77763 1.15673,0.77729 1.85234,2.48883 3.08604,3.11056 0.46005,0.23185 1.05508,-0.16394 1.54302,0 0.3522,0.11834 1.96708,1.98273 2.31453,2.33295"
       style="fill:none;stroke:#000000;stroke-width:15.56935501;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
       d="m 121.63806,-3.7370623 h 132.0855"
       style="opacity:1;fill:none;fill-opacity:1;stroke:#00ff00;stroke-width:15;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />

It looks as follows:

It was drawn with Inkscape and saved as plain SVG. The “rect” elements are rendered, but not so the paths (black and green lines).

I tried the SVGLoader from both the master and the dev branch and both show the same behaviour.

I am wondering if this is a desired behaviour since the paths are not closed. Also there does not seem to be any interpretation of the “stroke-width” style argument in the Loader.

I tried some more. If I close the path in Inkscape it still does not show up. Only when I fill the area within the closed path, then this area shows up as a mesh. So, the Loader does not consider the “stroke” (border with width > 0) only the “filling” of a path.

Yes, I’ve tested your SVG on my computer with SVGLoader and the green and black lines are not rendered. However, a contributor is already working to enhance SVGLoader so stroke settings are supported, see:

Hello, I’m ‘the contributor’ :slight_smile: The code is ready, I’m just waiting for the linked PR to be merged to create my PR.

@yombo Sry, I forgot your are active in this forum :sweat_smile:

Awesome work, @yombo!
This saves me a lot of headaches. As soon as the PR is merged, I will test it and report if it worked for me.

@Mugen87 Dont worry! That was my first post haha :slight_smile:

@LuBo All right! :ok_hand:

Thankfully I am not crazy (certainly not more than normal), the SVG loader doesn’t seem to work well at all, certainly with paths. I have been fighting with inkwell and three.js to get my graphics to work consistently however the current SVG loader in threejs simply isn’t reliable. What’s more, between browsers (edge vs chrome) the results are often different even with the same renderer which surprised the heck out of me.

@pr0cs Can you please share one of your problematic SVG files in this thread?

I have a variety of svg images, almost all of them exhibit some form of corruption, each will display different than inkwell and all use paths exclusively.

I’ve attached screenshots from IE11 (don’t have edge on this machine, but it too displays differently than chrom) and Chrome. I’ve included what the image SHOULD look like in inkscape.

I’m effectively using the svg loading example so I’m not doing anything fancy with the SVG, I can provide my source but I’m not sure there is much value as I’m sure you will see the same corruption effect.

Hopefully this will help, threejs needs a good vector image loader and SVG is very well supported but the current svg loader isn’t reliable enough in it’s current state.

The svg file contains numbers in exponential notation. By manually editing them, I’ve managed to make Chrome look like your IE11 screenshot.
I will investigate more…
Modified svg:

Thanks, I did notice that with a variety of export->re-import to different formats I could repair a number of images to a semi-usable state but even then the display on different browsers would often be different. Oddly Chrome would display the image flipped and inverted which you can somewhat observe in my screenshots.

Just by inverting the order in wich the imported paths are rendered, I’ve obtained this:
So the shapes are ok, it is a problem of the rendereing order, which is not implemented. Right now the paths are imported and it’s up to the application to decide render order.

Probably the SVGLoader should provide the returned paths in the correct rendering order.

Wow, very close!
I presume this is yet another issue that is well outside the scope of the changes you’re getting merged in correct? Is there an issue logged around this or are developers expected to adjust their render order themselves?

I guess nobody thought of this before.
If we work out the order, it could be implemented. It’s just that I’m not an SVG expert, contributors do what they can.

Well I appreciate your effort, at least I know what to look for in my svg files to fix a lot of the issues and I suspect that if I manually adjust the order either by editing the files or revising my shape generation code that I can make most of my data work as I’m expecting.
Last few days I was pretty disappointed, thinking I’d have to switch engines or even worse go back to 2d which wasn’t something I wanted to do, at least I have some insight what is going wrong. Cheers!

Thank you. You can change objects order in Inkscape indeed, in the objects list. Good luck!

Also, what is the attribution for the car svg file? I would include it in a future PR that solves the rendering order.