When extruding this SVG of a shape with a hole, three of the extruded faces are connected but the fourth (the one extruded from the hole) is separate. Here are some screenshots to illustrate the issue:
The SVG is made up of two paths, the inner path is the hole:
The extrude creates two surfaces instead of one. The blue surface, made up of the outer wall, top and bottom, and the green surface, made up of the inner wall.
Here I believe you can see part of the problem with the triangulation. The red vertex should connect to the blue vertex. The blue vertex is "non-manifold" it doesn't connect to another triangle on the top layer.
Here is the same surface after running a repair so that it is now a single surface. Note the two vertices from above are now connected.
Here is a JS Fiddle that reproduces the problem, you can see the triangulation problem here too if you zoom in on the same spot
This is occurring with the latest dev branch (r98) as you can see in the fiddle.
A note on this: The triangles above violate the following rule in the STL specification: "Vertex-to-vertex rule. Each triangle must share two vertices with each of its adjacent triangles. In other words, a vertex of one triangle cannot lie on the side of another." A triangle vertex is lying on a side on the screenshots above, this occurs both it the mesh generated by ThreeJS from the extrude function and is also the case in an STL file exported by the STLExporter.
Should the ThreeJS mesh follow the vertex-to-rule of the STL spec? If not, I assume the STL exporter should at least export a valid STL.
To clarify, on the path defining the hole, an additional vertex is inserted on each segment during the extrusion process.
Vertices of the Shape (the curved segments are on the outer edge)
Vertices of the Extrusion
/bump
I found same problem.
These surfaces make small noise.
var shape = new THREE.Shape();
shape.moveTo(-2,-2);
shape.lineTo(-2,2);
shape.lineTo(2,2);
shape.lineTo(2,-2);
shape.lineTo(-2,-2);
shape.moveTo(-1,-1);
shape.lineTo(1,-1);
shape.lineTo(1,1);
shape.lineTo(-1,1);
shape.lineTo(-1,-1);
/ping @Mugen87
/ping @yomboprime
Any interest in pursuing this? Is this an SVGLoader
issue or an extrusion issue?
Sincerely, I don't grasp the problem.
@yomboprime This is my understanding of the issue: Either in the loaded STL, or in the extruded geometry, or in both, the triangulation is invalid:
"Vertex-to-vertex rule. Each triangle must share two vertices with each of its adjacent triangles. In other words, a vertex of one triangle cannot lie on the side of another."
So this is invalid.
Thanks.
After debugging a bit, I've seen that the second subpath (corresponding to the hole) has line segments with the start and end points equal (i.e., the line segment has degenerated into a point). This happens in 1 of every 2 line segments in the hole subpath.
Then, I've read the svg file and so it happens in it. For example, "L131.4, 132.3L131.4, 132.3".
It does not happen in the other subpath.
So I wonder if this is not a problem with the source SVG. I would ask @napter to check the svg, and if possible find a valid smaller svg that reproduces the error.
Edit: I would say definitely it is not a problem with the extrusion.
Most helpful comment
Thanks.
After debugging a bit, I've seen that the second subpath (corresponding to the hole) has line segments with the start and end points equal (i.e., the line segment has degenerated into a point). This happens in 1 of every 2 line segments in the hole subpath.
Then, I've read the svg file and so it happens in it. For example, "L131.4, 132.3L131.4, 132.3".
It does not happen in the other subpath.
So I wonder if this is not a problem with the source SVG. I would ask @napter to check the svg, and if possible find a valid smaller svg that reproduces the error.
Edit: I would say definitely it is not a problem with the extrusion.