When importing an SVG and using ExtrudeGeometry to extrude it, the resulting mesh has errors in the top and bottom faces if there is a negative bevelOffset. In my case am using a negative bevelOffset that matches the positive bevelSize to ensure that the 2d footprint of the SVG is unchanged. I see negative values are allowed in the example so I assume this is supported. The erronious facets seem to span concave sections of both the shape's exterior and holes.
Take a look at this CodePen to see what I mean. Specifically look at the top and bottom/mouth of the dog. Perhaps an issue with buildLidFaces() in ExtrudeGeometry, since the beveled sides seem correct.
In the codePen I use r120 but I also see this issue with dev and r111.
I have also tried:
Removing all curves and using an input SVG with only straight lines
Manually creating the shape object from the shape and holes from the SVG
Many different SVGs
And see the same artifacts.
Using zero or more bevelOffset gives the correct result, but I would like the ability to inset as shown in the extrusion example.
Since this is my first issue report to this repo I apologies in advance if I'm missing any info or have misused this form.
MacOS 10.14.5 Mojave
Intel Iris Pro 1536 MB
The dog example is a bit complicated. Are you able to make a simpler shape that shows the issue?
Sure, I replaced the dog in the codePen with a circular ring.
Thanks! Do you mind adding DAT.GUI too so we can easily see what's happening?
No problem, done.
With the wireframe it's a bit clearer. Looks to me like the lid faces are being miscalculated.
Seems like the SVGLoader
's parser is not closing paths correctly...
Perhaps, though the artifacts occur not just at the closure points, and everything looks great when the bevel is disabled. I'm inclined to think the issue is more related to the way the ExtrudeGeometry applies the bevel. Specifically I suspect an error in the way the inset boundary points of the top and bottom faces are being computed.
Regardless, can you give a very rough timeline as to how quickly these sorts of issues tend to be addressed? Depending on how comfortable you are with unfamiliar folks poking around in your code, I could be inclined to work on it since I need this for my use case, though it would be great to get someone more familiar to at least point me in the right direction.
can you give a very rough timeline as to how quickly these sorts of issues tend to be addressed?
@Hertafeld Not quickly. Maybe not at all, to be honest.
This feature was added in #14233 to prevent extruded text from bumping together when bevels are used.
Problems with collisions were acknowledged in https://github.com/mrdoob/three.js/pull/14233#issuecomment-435988892.
A guess is triangulation of the front face breaks when vertices are translated and the front-face boundary self-intersects. That is just a guess. I have not studied this.
You may be better-off using modeling software and importing your models, but please have a go at investigating this if you are up to it. :-)
I appreciate the transparency.
A guess is triangulation of the front face breaks when vertices are translated and the front-face boundary self-intersects. That is just a guess.
This seems close to what's happening, but not quite. With the example I prepared, we shouldn't see any self-intersection until the negative width of the bevel exceeds the thickness of the donut. However, we see facets poking out where they shouldn't even with very small negative bevelOffset (eg try 2 bevelSize and -2 bevelOffset). It's clear that the top face is NOT self-intersecting but the issue remains.
One silver lining seems to be that the beveled section looks correct, and might have the information we need. If I were to dive in, my first approach would be to try to pull out the points that make up the topmost and bottommost layers of the bevel, reconstruct the path of the lids, and triangulate this.
...or perhaps not. I've updated the codePen to view the sides and lid materials separately, and the sides are broken as well.
Still might be worth my diving into. I've come to threejs after building a modeling pipeline as you suggested, but it is quite slow and running in the browser would be phenomenal.
My current pipeline begins by insetting the SVG path, then expanding it with a sphere (minkowski) to create the bevel. I think the quickest way for me to get what I need in-browser is to use another library (eg PaperJS) to compute the inset of the SVG (which will properly handle self-intersection and whatever else is happening here), then toss that to ThreeJS's extrudeGeometry with a positive bevel.
Thanks all for the quick responses!
Most helpful comment
...or perhaps not. I've updated the codePen to view the sides and lid materials separately, and the sides are broken as well.
Still might be worth my diving into. I've come to threejs after building a modeling pipeline as you suggested, but it is quite slow and running in the browser would be phenomenal.
My current pipeline begins by insetting the SVG path, then expanding it with a sphere (minkowski) to create the bevel. I think the quickest way for me to get what I need in-browser is to use another library (eg PaperJS) to compute the inset of the SVG (which will properly handle self-intersection and whatever else is happening here), then toss that to ThreeJS's extrudeGeometry with a positive bevel.
Thanks all for the quick responses!