2
$\begingroup$

I'm puzzled by the process that Blender uses to convert splines (from an imported SVG) to meshes.

This is the original SVG:

enter image description here

and as (Inkscape's) SVG

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!-- Created with Inkscape (http://www.inkscape.org/) -->

<svg
   version="1.1"
   id="svg18603"
   xml:space="preserve"
   width="161.75391"
   height="203.45117"
   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
   xmlns="http://www.w3.org/2000/svg"
   xmlns:svg="http://www.w3.org/2000/svg"><g
     id="g18609"
     transform="matrix(3.7795276,0,0,3.7795276,-299.94922,-532.48241)"><path
       id="rect443"
       style="opacity:1;vector-effect:non-scaling-stroke;fill:none;stroke:#3465a4;stroke-width:1;stroke-dasharray:none;"
       d="m 92.915776,140.88597 
          l -10.234001,2.29289 
          a 5.4865675,11.632576 0 0 1 1.056266,6.86056 
          a 5.4865675,11.632576 0 0 1 -4.376477,11.39207 
          l 2.773474,33.28427
          h 37.263872 l 2.76004,-33.11942
          a 5.4865675,11.632576 0 0 1 -4.37648,-11.39207
          a 5.4865675,11.632576 0 0 1 1.05627,-6.86056
          l -10.34975,-2.31924
          a 8.6428194,4.9179537 0 0 1 -7.72873,2.72076 8.6428194,4.9179537 0 0 1 -7.844484,-2.85926 z" />
</g>
</svg>


that then gets converted to a mesh that looks like this (check and compare the portions highlighted by the red and orange dots):

enter image description here

The spline as it was imported from the SVG via file -> import looks like this:

enter image description here

which is closer (if not exactly the same) in logic to the SVG.

What's the logic used in the SVG to spline to mesh process, and can it be controlled (ideally via python)?

$\endgroup$
1
  • $\begingroup$ The image of the SVG has been converted to PNG. It might be helpful to see the actual SVG, specifically its XML code. $\endgroup$
    – user143855
    Commented May 30, 2022 at 16:24

1 Answer 1

5
$\begingroup$

The resulting visible mesh topology is the direct consequence of the bezier curve type it was created from.

If a segment after being converted to mesh has multiple points along it's length like illustrated, it means it is was actually interpreted as curved and not a straight line.

If it visually looks like a straight line but still outputs multiple points, then you should check the curve handles for those points. A true straight segment will have Vector handle types, whereas a curve segment may have Free or Aligned handle types.

Notice the red colored handles to the right, indicating the Free state of the selected bezier handles, despite being in a linear position. The ones on the right have a green color indicating Vector handles producing the expected straight line.

enter image description here

You can control the handle type for selected vertex by entering Edit Mode in a Bezier curve, selecting the handles and pressing V or from the Control Points > Set Handle Type menu.

See Reducing internal faces generated by extensive curve extrusion? for curve cleanup techniques.

Inspection of the provided blendfile revealed that the handles for the segments in cause that produce multiple points rather than a single edge are zero sized and coincide with their parent vertex.

Upon further investigation I found out that for some reason Blender's SVG importer algorithm seems to misinterpret straight segments that immediately follow a curved segment. For those first straight paths after a curved path handles are imported as having zero sized length and coincide with their parent vertex, producing these undesirable or unexpected results.

The following paths after straight segment path already produce the clean results one would expect.

enter image description here Notice the circled first straight paths after curved ones have invisible handles (overlapping the start and end vertex) causing visible tesselation of the curve fill, resulting in triangulated output with lots of lines, as opposed to a clean topology for the segments following those.

$\endgroup$
6
  • $\begingroup$ thanks for the answer. I’m afraid I’ll have to disagree: if you check the SVG source (the “d” attribute), the straight lines are indeed straight. They are “h” or “l” path commands (see developer.mozilla.org/en-US/docs/Web/SVG/Attribute/…). They are nonetheless split into smaller segments in one case, and kept as one in the other. No multiple points in the source, nor hidden curves. That’s why I find the result surprising, and I would not call it a direct consequence. Would you want to give things a second look? $\endgroup$
    – simone
    Commented May 30, 2022 at 21:20
  • $\begingroup$ Both segments that have lots of points have zero sized handles on import, which Blender always interprets as free handles regardless of set path type, so the answer still holds $\endgroup$ Commented May 30, 2022 at 22:50
  • $\begingroup$ Sorry if I'm bugging you. If you closely check the SVG (which I've edited for clarity) you can see that it only contains arcs (the "a" commands) and straignt lines (the "h" and "l" commands). I've gone back and re-done the process and saw that the SVG import is kinda ok, but where strange (t me at least) things happen is in the spline to mesh conversion. Somehow I would expect this step to be more "respectful" of the original SVG source. I.e.: straight lines should become a single line in the final mesh? Am I wrong here? Just trying to understand. $\endgroup$
    – simone
    Commented May 31, 2022 at 4:27
  • $\begingroup$ If you import your SVG and immediately extrude it using the bezier curve Geometry > Extrude you'll see that the extra faces in straight segments are already there before conversion to mesh, so if anything is to blame is either the importer, or Blender's bezier skinning algorithm, converting to mesh step is only making more visible the geometry that was already there imo. Why it happens on those segments I cannot say, inside blender what I see different is that for those two straight segments handles are zero sized and coincident with their parent vertex $\endgroup$ Commented May 31, 2022 at 9:05
  • $\begingroup$ ok - then it's the SVG import step that does something. Would you know how to control that or the best I can do is look at the source? And I'd be glad to accept the answer if you added a couple of lines to the answer reflecting these last comments $\endgroup$
    – simone
    Commented May 31, 2022 at 9:31

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .