Three.js: SVGLoader: Missing SVG specs break correct shape rendering.

[makc]

I mean, I understand SVGLoader is work in progress, but can you really get anywhere without this? my svg looks exploded :)

example:

<g transform="translate(226 226)">
      <polygon fill="#F4F7FF" points="...

in SVGLoader there is only this:

case 'g':
    style = parseStyle( node, style );
    break;

while funcs like parseTransformNode are clearly there already

[makc]

wait, there is var transform = getNodeTransform( node ); right before the switch, so it is supposed to be transformed, yet is not? then it is a bug, not a feature request

[makc]

here's the svg
3.svg.zip

here's what it looks like in 3js:

[mrdoob]

@yomboprime any chance you could take a look?

[yomboprime]

Sure, I'll look into it.

[yomboprime]

Ok, I see what happens. This is not a bug. There are some SVG features used in the sample svg file which are not implemented in the loader:

• Render effects such as mix-blend-mode:multiply, linearGradient and filter are not implemented.
• References to other nodes in the mix-blend node (a path, the gradient and the filter) (via id and xlink:href) are not implemented.
• View window attributes (width, height, x and y) are not implemented.

The combination of the view window and the filter makes it appear a translation bug, but it is not.

I'd suggest to try to edit the svg file so it has no render effects, since I think those are not goals for the loader.

[makc]

let's forget the fills for a moment,

View window attributes (width, height, x and y) are not implemented.

ok, but should not this affect all the transforms uniformly?

References to other nodes

so are you saying that SVGLoader just grabs the path from defs and places it in 0,0 ?

[yomboprime]

1st question: No, the view is only on the outer shape, not on the craters.
2nd question: Yep, that is correct.

So, implementing references to nodes in defs and the view window attributtes is needed. I can do the view window part, but I will need help with the node references one.

[Lynges]

I was just hit by this. Can't say that I know enough about svg transforms to give a hand with the node references, but just thought I would mention that Inkscape can unlink a clone and turn it into a normal path object. Maybe some insights could be gained from their approach? @yomboprime .

[yomboprime]

I was just hit by this. Can't say that I know enough about svg transforms to give a hand with the node references, but just thought I would mention that Inkscape can unlink a clone and turn it into a normal path object. Maybe some insights could be gained from their approach? @yomboprime .

Sorry, I must have missed your comment.

You are right, Inkscape can be used to convert the clones defined in <defs> as I've described in #18104, which can be useful for someone.

[TakumaKira]

Hi @yomboprime,

So, implementing references to nodes in defs and the view window attributtes is needed. I can do the view window part, but I will need help with the node references one.

I still don't get in what way you want to solve this, but I might be able to help you to get the node reference.

In SVGLoader.js > parse > parseNode, you can get the reference to the node which is called from the use tag like below.

switch ( node.nodeName ) {
  case 'use':
    const usedNode = node.viewportElement.getElementById(node.href.baseVal.substring(1));

I think it is great if we can use any svg files!!
I hope this helps.

[yomboprime]

In SVGLoader.js > parse > parseNode, you can get the reference to the node which is called from the use tag like below.

switch ( node.nodeName ) {
  case 'use':
    const usedNode = node.viewportElement.getElementById(node.href.baseVal.substring(1));

Can you provide some SVG files to test this feature? I'm not very used to use it in Inkscape (I guess it is a thing inserted automatically by the SVG editor?)

[TakumaKira]

Can you provide some SVG files to test this feature? I'm not very used to use it in Inkscape (I guess it is a thing inserted automatically by the SVG editor?)

I tried the files provided in other comments on the related issues.
https://github.com/mrdoob/three.js/issues/14569#issuecomment-408389736
https://github.com/mrdoob/three.js/issues/19168#issue-602683520
https://github.com/mrdoob/three.js/issues/18104#issue-534504023

BTW, I've never used Inkscape actually. I tried to use an SVG file downloaded from Icomoon for my three.js project. It includes defs and symbol tags, and you can select a symbol to display by adding the ID to file URL(I attached the sample file and the document). The result is not working, and all the symbols are merged. I just worked around at that time.
Of course, it will be great if I can use SVG files from Icomoon as well, but first I wanted to help to resolve this already raised issue.

[yomboprime]

Thank you, I will look into it.

[yomboprime]

It was easy to implement. I've tested the three samples though there are some glitches.

The first sample contains gradients so I cannot test it.

The second Latex sample works right, but there are some letters with winding problems:

An finally the third sample does not work, it gives NaN vertices and even doesn't load properly on Inkscape.

So I would need more files to test the defs and use nodes.

You can see the changes here: https://github.com/yomboprime/three.js/blob/svgdef/examples/jsm/loaders/SVGLoader.js

[yomboprime]

I've got two SVGs with defs from Creative Commons and I think they are sufficient to test this.
The Latex example (second file in my previous post) must have some other problems so I've removed it.

@makc Now this SVG is loaded right: