The AFrame plugin is a bit rough because it simple extracts all the "d=" attributes from the SVG and aggreagtes them together into one long string, which it passes to svg-mesh-3d. So this includes plenty of M and Z commands. I suspect it's these M and Z commands that are confusing svg-mesh-3d.
I changed the AFrame plugin to treat each svg separately, passing them one at a time to svg-mesh-3d and getting a mesh back, then creating one Three.js Object3d for each . This works perfectly.
So I think there's a bug in how svg-mesh-3d handles complex "d" strings with M and Z's.
The AFrame plugin https://github.com/7dir/aframe-svgfile-component/ uses this svg-mesh-3d library to get SVG into Three.js geometry.
I encountered the problem that overlapping paths creates holes in the mesh.
overlaptest.svg.txt
The AFrame plugin is a bit rough because it simple extracts all the "d=" attributes from the SVG and aggreagtes them together into one long string, which it passes to svg-mesh-3d. So this includes plenty of M and Z commands. I suspect it's these M and Z commands that are confusing svg-mesh-3d.
I changed the AFrame plugin to treat each svg separately, passing them one at a time to svg-mesh-3d and getting a mesh back, then creating one Three.js Object3d for each . This works perfectly.
So I think there's a bug in how svg-mesh-3d handles complex "d" strings with M and Z's.