SVGLoader + Inkscape

LuBo · March 18, 2019, 3:12pm

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: https://threejs.org/docs/#examples/loaders/SVGLoader

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.

Mugen87 · March 18, 2019, 6:46pm

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).

LuBo · March 19, 2019, 1:57am

Hey Mugen87,
thanks for the fast answer!

This is the SVG I am using:

<svg
   xmlns:osb="http://www.openswatchbook.org/uri/2009/osb"
   xmlns:dc="http://purl.org/dc/elements/1.1/"
   xmlns:cc="http://creativecommons.org/ns#"
   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
   xmlns:svg="http://www.w3.org/2000/svg"
   xmlns="http://www.w3.org/2000/svg"
   id="svg90934"
   version="1.1"
   viewBox="0 0 378.29001 368"
   height="368mm"
   width="378.29001mm">
  <defs
     id="defs90928">
    <linearGradient
       osb:paint="solid"
       id="linearGradient96959">
      <stop
         id="stop96957"
         offset="0"
         style="stop-color:#ff0000;stop-opacity:1;" />
    </linearGradient>
  </defs>
  <metadata
     id="metadata90931">
    <rdf:RDF>
      <cc:Work
         rdf:about="">
        <dc:format>image/svg+xml</dc:format>
        <dc:type
           rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
        <dc:title></dc:title>
      </cc:Work>
    </rdf:RDF>
  </metadata>
  <g
     transform="translate(0,71)"
     id="layer1">
    <path
       id="path90936"
       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" />
    <path
       id="path90936-3"
       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" />
    <path
       id="path90936-6"
       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" />
    <path
       id="path90936-6-7"
       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" />
    <rect
       y="-64.973999"
       x="7.2369661"
       height="352.27277"
       width="20.374128"
       id="rect95501"
       style="fill:#7f0000;fill-opacity:1;stroke-width:10;stroke-miterlimit:4;stroke-dasharray:none" />
    <rect
       y="-64.973999"
       x="27.611097"
       height="15.715944"
       width="344.01932"
       id="rect95503"
       style="fill:#ff0000;stroke-width:10;stroke-miterlimit:4;stroke-dasharray:none" />
    <rect
       y="-49.258057"
       x="347.00427"
       height="335.06436"
       width="24.626114"
       id="rect95505"
       style="fill:#ff0000;stroke-width:10;stroke-miterlimit:4;stroke-dasharray:none" />
    <rect
       y="270.13516"
       x="21.641127"
       height="15.671166"
       width="325.36316"
       id="rect95507"
       style="fill:#ff0000;stroke-width:10;stroke-miterlimit:4;stroke-dasharray:none" />
    <path
       id="path97026"
       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" />
    <path
       id="path97284"
       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" />
  </g>
</svg>

It looks as follows:
svg

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.

Edit:
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.

Mugen87 · March 19, 2019, 9:56am

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: https://github.com/mrdoob/three.js/pull/15922#issuecomment-472233034

yombo · March 19, 2019, 8:13pm

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

Mugen87 · March 19, 2019, 8:15pm

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

LuBo · March 20, 2019, 12:52am

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.

yombo · March 20, 2019, 7:23am

@Mugen87 Dont worry! That was my first post haha

yombo · March 20, 2019, 7:24am

@LuBo All right!

pr0cs · March 24, 2019, 11:28pm

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.

Mugen87 · March 25, 2019, 10:06am

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

pr0cs · March 25, 2019, 3:07pm

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.
broken
car

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.

yombo · March 25, 2019, 3:59pm

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:
car

pr0cs · March 25, 2019, 4:02pm

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.

yombo · March 25, 2019, 4:08pm

Just by inverting the order in wich the imported paths are rendered, I’ve obtained this:
imagen
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.

pr0cs · March 25, 2019, 4:12pm

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?

yombo · March 25, 2019, 4:14pm

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.

pr0cs · March 25, 2019, 4:25pm

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!

yombo · March 25, 2019, 4:30pm

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

yombo · March 25, 2019, 4:40pm

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

Topic		Replies	Views
SVGs with holes inside hole failing to load properly with SVG Loader Questions loaders , geometry , svg , svg-loader	1	478	February 27, 2023
SVGLoader.parse() errors Questions svg , svg-loader	2	2219	March 18, 2021
SVGLoader doesn't load svg Questions svg , svg-loader	7	3392	February 10, 2020
How to deal with Shapes from self-crossing SVG path? Questions geometry , svg , svg-loader , shapes	0	468	May 10, 2022
SVGLoader stroke and other params support Questions	1	1764	January 31, 2019

SVGLoader + Inkscape

Related topics