This is great! There is, however, one potential issue with this implementation stated here:"Faces are sorted back-to-front in a very approximate way according to the Z centroid".In certain cases, this can lead to showing the back face and hiding the front face because the centroid position is not sufficient for figuring out the Z order of triangles.Other than this minor issue, it's a great implementation.

 Yeah, the painter's algorithm fails with certain geometries, like when polygons intersect each other, or when they overlap in a certain way.Maybe I should compare min positions rather than centroids, but I don't think that would fix those cases.I think the only real fix involves splitting up the polygons for the failure cases, which seems complex.
 Centroids is a reasonable approximation, if your geometry is not very coarse. PlayStation games often used this because the hardware lacked a depth buffer.
 You're right! The min positions won't resolve the issue either and, unfortunately, there is no trivial fix for it.Handling intersecting polygons, as you said, is a bit more complex, but for overlapping polygons it's possible to find the Z-order robustly by computing the intersections with the line of sight.
 perhaps you could preprocess the shape using the Binary Space Partitioning (BSP) algorithm. there’s a step in the algorithm that finds polygons that would cause z-sorting conflict and splits them along the exact line you need to resolve the conflict. you end up with a data structure that gives you the z sorting order for any camera angle.
 For triangles only the intersection case matters. General Polygons could be a bit more complicated. As long as the object is watertight, it's easier.I recently ran into similar problems to be solved in Python, because I am trying to build a replacement for OpenSCAD by duct-taping together various Python packages. Shapely is quite useful for 2D geometry (like intersection and stuff). PyMesh is extremely useful for 3D meshes, but hard to build.There are some non photorealistic rendering (NPR) options for Blender, many of them implemented in Python. I don't know if they can output SVG data currently.ThreeJs has an SVG engine, meaning a backend that outputs SVG.
 > build a replacement for OpenSCADI am very interested in this.
 My first attempt was using the Blender API, you can take a look at https://github.com/akloster/blender-vraagCurrently I am trying to reimplement the "construct" part with Pymesh and Shapely, but I haven't published it yet.
 Have you tried python-occ? http://www.pythonocc.org/
 Thank you for the suggestion. I hadn't seen that yet. From a cursory look it's not completely what I am looking for, but maybe it can be useful.One of the problems for me is that I am sort of stumbling into this "CAD" thing from a coding perspective. CAD programs like Fusion 360° or FreeCAD seem a bit too complicated for me, and through my grappling with the concepts I am reinventing some concepts/tools.Particularly I want to develop 3D printed objects the same way I would do data science: Start with Jupyter notebooks, iterate, maybe end up with parametric Python scripts.
 python-occ may be particularly well suited. They have ipywidgets to look at the models. https://www.youtube.com/watch?v=ieX_GC1sdrQ https://github.com/tpaviot/pythonocc-core/blob/master/src/Di...
 I have only taken a cursory look. So far a lot of the links are dead and it's a bit hard to see examples of the API.
 I certainly agree with that. It has seen more work recently from the BIM side. http://www.pythonocc.org/ has examples but the most recent work is really demos using it as a part of other projects. https://pure.tue.nl/ws/files/119667686/20190402_Krijnen.pdf https://link.springer.com/article/10.1007/s42496-019-00007-4 https://arxiv.org/pdf/1810.10795.pdf The difficulty for a lot of CAD systems is the NURBS type line geometry interactions. https://en.wikipedia.org/wiki/Non-uniform_rational_B-spline