Re: [OpenSCAD] STL to SVG conversion
David Eccles (gringer) wrote
I would [eventually] like to do some simplification of the geometry,
combining adjacent triangles with the same normal into a single polygon
Well, that took a bit less effort than I had expected (which probably means
it has more bugs than I expect). I've now updated the script to merge
triangles that have the same normal and share a common edge.
https://github.com/gringer/bioinfscripts/blob/master/stl2svg.pl
--
View this message in context: http://forum.openscad.org/STL-to-SVG-conversion-tp10540p10578.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
David Eccles (gringer) wrote
So... I wrote my own Perl script to do a basic conversion of a triangle
STL file to SVG:
...and I've converted it into C++ for OpenSCAD :-). Some additional features
would be nice though (e.g. using the current color settings and the viewport
camera angle).
http://files.openscad.org/csg.scad
http://files.openscad.org/csg.svg
ciao,
Torsten.
tp3 wrote
and I've converted it into C++ for OpenSCAD :-). Some additional features
would be nice though (e.g. using the current color settings and the
viewport
camera angle).
I see now that STL is generated in the export.cc code, so it would make
sense for a 3D SVG export (2D SVG is already there) to go in a similar
place:
https://github.com/openscad/openscad/blob/master/src/export.cc
But I can't see anything there about colour, and I'm a bit green to the
OpenSCAD data structures. Any ideas how colour can be pulled out the
objects?
I've been colourising images in Inkscape by setting the saturation and hue
to that of the desired colour, keeping the lighness the same as the surface
(assuming the fudged Inkscape model of colour). It would be possible to do
this in code, bearing in mind that the lightness component would be ignored
from the object colouring, but I need some way to get the colour out of the
objects -- it's definitely not in the STL file, and the current 2D SVG
export ignores colour completely.
Viewport camera angle shouldn't be too difficult -- it's just an application
of a matrix multiplication to all the 3D components.
--
View this message in context: http://forum.openscad.org/STL-to-SVG-conversion-tp10540p10648.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
On 20.12.2014 10:52, David Eccles (gringer) [via OpenSCAD] wrote:
I see now that STL is generated in the export.cc code, so it would make sense for a 3D SVG export (2D SVG is already there) to go in a
similar place
Sorry, just noticed you've already done that -- for some reason I couldn't find your fork earlier. It's a nice idea to add it to the
existing SVG code and choose based on the model whether to do a 3D or 2D SVG export.
Looking at the code, it doesn't seem to combine polygons to exclude common edges with the same normal (i.e. not including my most recent
changes), and only calculates the normal based on the first three points (presumably assuming all polygons are triangles). Presumably
updates are in the works....
--
View this message in context: http://forum.openscad.org/STL-to-SVG-conversion-tp10540p10649.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
On 12/19/2014 11:18 PM, David Eccles (gringer) wrote:
It's a nice idea to add it to the existing SVG code and choose based
on the model whether to do a 3D or 2D SVG export.
I think that's much nicer than just give an error "can't export 3D
model as SVG", even with it's currently a bit limited features.
Looking at the code, it doesn't seem to combine polygons to exclude
common edges with the same normal (i.e. not including my most recent
changes), and only calculates the normal based on the first three
points (presumably assuming all polygons are triangles). Presumably
updates are in the works....
At this point in the export, the polygons are usually not fully
tesselated, but all should be convex, so it depends on the previous
calculation steps what geometry is given to the export. I guess in
most cases (e.g. for the primitives or for extrusion) it's likely
quads.
The normal calculation could be made more stable by better selection
of the vertices. Do you have an suggestions what could work for that?
Using the vertices which have the greatest dot product value?
ciao,
Torsten.
The normal calculation could be made more stable by better selection
of the vertices. Do you have an suggestions what could work for that?
Using the vertices which have the greatest dot product value?
Assuming all the vertices are coplanar (hopefully a reasonable assumption
to make), it shouldn't matter too much as long as there's sufficient
separation between the points. My gut instinct would be to select 3
vertices that differed in distance in all 3 dimensions by more than 1/4 of
the bounding box.
If all points are colinear, then the polygon probably shouldn't be
displayed, and if the normal is pointing away from the viewport, then the
polygon probably also shouldn't be displayed.
--
View this message in context: http://forum.openscad.org/STL-to-SVG-conversion-tp10540p10652.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
On Dec 19, 2014, at 20:24 PM, David Eccles (gringer) bioinformatics@gringene.org wrote:
Assuming all the vertices are coplanar (hopefully a reasonable assumption
to make), it shouldn't matter too much as long as there's sufficient
separation between the points.
if we really want to support non-planar polygons, perhaps just use Newell’s method, as in:
https://github.com/openscad/openscad/blob/a05fe72c6bcc46450797ab6b87a3494c703d4d4d/src/cgalutils-tess.cc#L109
We can also tessellate before doing the export if that makes it easier.
-Marius