Hi,
I was trying out Kiri:Moto to use as a SVG to Gcode for my Maslow CNC router. It looks like it has all the features I need for the path generation which is awesome. I love the simplicity yet it has all you need for most of what I am doing. Looking to recommend it to my sister who is a bit less techy.
However, I was having a bit of trouble with the limitations of the SVG import and it looks like these issues could be easily fixed.
The first is that the depth of the extruded item is not easily set anywhere in the GUI. My imagination would be that there would be a dialog box to allow you to set how deep/thick you want the resulting extruded item. Digging through the javascript I found that you can set the data-km-extrude property in the SVG to adjust the thickness, but it would be nice if there was a GUI method to do this. Currently it just extrudes 5 (not sure what units) for all SVGs. Do you know what units this depth is in? mm?
The second thing is that the inside/outside of the SVG import is not always correct. Again, this can be corrected by using Inkscape to reverse the path, but it would be nice to have a KM GUI option for this. This is controlled by the 3JS ShapePath.toShapes method having an argument of true. Perhaps this could also get added to the GUI above (where you set extrusion depth) so that you can easily change the definition if inside/outside to get the correct imported shape.
Yes, I can add a dialog on SVG import to ask for the depth. It’s currently set to 5mm. I elected not to do this because you can always just re-scale the part in the Z only using the scale tool.
The SVG import does not currently boolean / nest the inner and outer polygons. This is also fixable. Do you mind dropping a couple of SVGs here that aren’t importing correctly that I can use for testing?
Pushed out 3.7.D3 with a new option to repair (re-boolean) SVGs on import. It’s only surfaced in Mesh:Tool for testing right now. Let me know if it works for your SVGs.
Hey Stewart, thanks for the awesome work getting that import screen implemented.
I hadn’t thought of just scaling the imported object, but it seems obvious now. That could have worked too, but I like the option on the import screen.
You mention that SVG import does not currently boolean the polygons. While the import doesnt boolean them, if you boolean them beforehand in your SVG editor, then it works.
There are some examples in the images below. The first is two polygons stacked (I colored them different in the SVG). After import to Kiri:Moto, you just get two solids, which is pretty much expected behavior.
The second and the third look visually identical in Inkscape. They are both single paths with the center removed. However, the third I have then used the Path → Reverse option in Inkscape. After import into Kiri:Moto, the middle results in a thin shell and filled center. The third results in the expected result.
This is because the 3JS ShapePath.toShape function fills/removes the shape based on the order of the nodes (CW vs CCW). The function’s isCCW parameter to determines what ends up filled/removed.
Based on my extremely limited testing, the order that Inkscape creates shapes by default is opposite order that Kiri:Moto’s use of toShape wants, resulting in the wrong thing unless you reverse the path.
So I was just thinking the default could get swapped then add another checkbox on that import page to give people control over how it imports (in case its not the same as Inkscape default).
It took a fair bit of digging to find that it was filling based on CW/CCW so adding a setting to help out regular users would be good.
