Three.js: SVGLoader - issue with path / stroke - Cannot read property 'fill' of undefined

[mattscotty]

I've a fairly simple SVG that encounters the problem;

"SVGLoader.js:798 Uncaught TypeError: Cannot read property 'fill' of undefined"

I tried to check if the style was defined which stopped the crash, but the paths were not rendered.

The SVG is as follows;
<svg viewBox="-2.5 -2.5 35 65" width="100%" height="100%" style="pointer-events: auto;"><ellipse cx="15" cy="8" rx="7.5" ry="7.5" fill="#ffffff" stroke="#6d6e71" pointer-events="all"></ellipse><path d="M 15 15 L 15 40 M 15 20 L 0 20 M 15 20 L 30 20 M 15 40 L 0 60 M 15 40 L 30 60" fill="none" stroke="white" stroke-miterlimit="10" pointer-events="stroke" visibility="hidden" stroke-width="9"></path><path d="M 15 15 L 15 40 M 15 20 L 0 20 M 15 20 L 30 20 M 15 40 L 0 60 M 15 40 L 30 60" fill="none" stroke="#6d6e71" stroke-miterlimit="10"></path></svg>

Here's a fiddle showing the issue;
https://jsfiddle.net/mattscotty/b4g62cna/

Three.js version

• [x ] r111

Windows 10, Chrome latest.

Thanks

[WestLangley]

In SVGLoader.js, it should probably be:

if ( node.style && node.style[ svgName ] !== '' ) style[ jsName ] = adjustFunction( node.style[ svgName ] );

/ping @yomboprime

[yomboprime]

In SVGLoader.js, it should probably be:

if ( node.style && node.style[ svgName ] !== '' ) style[ jsName ] = adjustFunction( node.style[ svgName ] );

/ping @yomboprime

Yep, that seems correct. Will look into it as well as #17885

[mattscotty]

Thanks for looking in to this, I can confirm it no longer crashes, but the strokes are still not rendered

[yomboprime]

Thanks for looking in to this, I can confirm it no longer crashes, but the strokes are still not rendered

I am seeing them?

[mattscotty]

Apologies, yes they are working, I was missing the extra SVGLoader.pointsToStroke section in my code.
However for some reason in my version the strokes are having some kind of flickering effect;

Looking at it further, the 'visibility="hidden"' on the compound path is also not being respected.
The strokes on the body should have no visible background.

[yomboprime]

The strokes on the body should have no visible background.

Sorry, I don't fully understand that sentence.

About the flickering, could it be caused by z-fighting?

[mattscotty]

Sorry for the confusion.
If you look at the body of the man, there is a white background path behind each stroke.
If we take a look at the path that makes up that section, the visibility is set to "hidden", so it should not show.
If you open the SVG in illustrator for example, you will see that is is set to not visible;

Ideally it would be best to just not have it there at all, but we can't control all SVG content so we need to respect the setting as it shouldn't be visible.

The only white you should see on the SVG is the circle background for the head.

Regarding the flickering, I think you are correct on the z-fighting issue.
I'm testing with another SVG which has the same issue as mentioned above with the visibility="hidden" issue.
As it's not supposed to be rendered, I didn't realise that's what's happening.

I hope that makes more sense, thanks

[yomboprime]

Oh, now I see.

As described elsewhere, a decision was made to let the user decide the rendering of the paths SVGLoader returns.

So, in order to make invisible the paths you want, you simply check the visibility attribute in your code, where the meshes are generated.

In the loader official example, you would change the line

if ( guiData.drawStrokes && strokeColor !== undefined && strokeColor !== 'none' ) {

to something like:

if ( guiData.drawStrokes && strokeColor !== undefined && strokeColor !== 'none' &&
  ( path.userData.attributes.visibility === undefined || path.userData.attributes.visibility === "visible" ) {

(Edited to add the .attributes field)

[mattscotty]

I thought that might be the case but wanted to check my understanding of the problem.
I think it would be useful to have a method to import SVG's as is without custom code to avoid confusion.
In my example, I just want to import them into three.js as is, and I'd imagine that will happen a lot.
If you agree I'm happy to open a separate feature request.
Something along the lines of new SVGLoader().parseAdd(data, group)

Looking at it now, visibility is not available in userData and I've had to use path.userData.node.attributes.visibility.

Thanks for your help

[yomboprime]

I thought that might be the case but wanted to check my understanding of the problem.
I think it would be useful to have a method to import SVG's as is without custom code to avoid confusion.
In my example, I just want to import them into three.js as is, and I'd imagine that will happen a lot.
If you agree I'm happy to open a separate feature request.
Something along the lines of new SVGLoader().parseAdd(data, group)

Looking at it now, visibility is not available in userData and I've had to use path.userData.node.attributes.visibility.

Thanks for your help

Depending on your use case, converting a SVG DOM image to a Three.js texture is easy and is very performant. Though I understand that does not solve all cases.

Implementing the whole SVG specification is very complex. I don't know if there is a roadmap to implement more of it, but I have to say I like SVGLoader as it is right now because it is very hackable and has a lot of uses like CAD, CNC and 3d printing.