Wednesday, September 24, 2008

 

STL and Forks in the Eye, and new Slice Format?

So, I spent a while ( well more than a while ) fiddling with some STL files, trying to get them to slice in skeinforge.

STL is really nice in some ways-- easy to parse, easy to understand.

But it utterly sucks when it comes to trying to figure out hwow to represent a solid.
But, the STL Im working with has holes in it.

See, commerical cad packages dont seem to try to create "good" stl, -- its just for display, so they are like swiss cheese. I tried for hours to fix them with meshlab, remesh, and other tools, but they are painful. I'm using SolidWorks, which is a fantasic solid modeler, but creates unsuable STL.

Then, i realized that it has internally a brep represenation of each face-- just what i need to create quick and accurate slices.

It took only about 4 hours to whip up a plugin for Solidworks that will slice a model and output the edges, loops, and faces for a solid-- with exacting precision and no holes. Now I just need a way to get that into skeinforge to do the rest of the steps.

Then i started wondering: what if we had a standard slice format that contains the boundary rep of each slice, so that if it can be created in AOL or other cad packages, its easy to avoid STL?

Something like this, which uses standard loop representations ( with ccw or cw direction to indicate "inside" )

solidName: "MySolid"
slices
slice-z: 0
loop: "outer":
#x-y points
1.0 1.0
1.0 1.1
end loop
loop: "other"
#more xy-points
end loop
slice-z: 2
#more slices


The idea being, that this could be created directly very quickly and easily from the solid packages ( bsh script in AOL) and be an easy, portable way to then do more difficult slicing/dicing in another system...

Comments:
LOL! Something like this, huh?

{object}
{boundaries}
{x-axis min="000.000" max="055.000"/}
{y-axis min="000.000" max="055.000"/}
{z-axis min="000.000" max="010.000"/}
{/boundaries}
{rotations}
{x-axis degrees="0.0"/}
{y-axis degrees="0.0"/}
{z-axis degrees="0.0"/}
{/rotations}
{grid}
{xy-plane resolution="0.100"/}
{z-axis resolution="0.100"/}
{/grid}
{layer z="1"}
{path material="HDPE" size="0.8"}
{point x="25" y="24"/}
{point x="25" y="25"/}
.
.
.
{point x="27" y="24"/}
{point x="26" y="24"/}
{/path}
{path material="HDPE" size="0.8"}
{point x="62" y="179"/}
{point x="62" y="180"/}
{point x="62" y="181"/}
.
.
.
{point x="395" y="484"/}
{point x="395" y="485"/}
{point x="395" y="486"/}
{/path}
{/layer}
{/object}

Note that I had to replace the greater than and less than characters with curly brackets so that my comment would be accepted by this blog software. :-P

Zach and I put together this XML format for slice information before he started his love affair with GCode. I'm still using it. It has the advantage that you can make changes with an ordinary editor if there are tiny problems with your slices.
 
Pefect, just what i am looking for.

I love Gcode, but, I dont think its appropriate for repreenting slices and loops. It works, but its just not designed for it.

can your provide more info about the format of your file? the file to the left has more "fabrication" like stuff in there than I was thinking, IE, the idea is that a boundary rep of a slice is all you need in the file, the materials, etc etc would be added by the next step ( like skeinforge).
 
What you see is what you get. About the only other difference between what you see and the XML format I'm using is that the different data types are tabbed, like is usual in most XML. As well, the resolution of my machine is 0.1 mm, so you see the boundaries given in mm while the x and y points are given as integers in tenths of mm's.
 
forrest:

I think i understand the value of the "boundaries" eection, and of course the layers and points are clear.

what is the purpose of the grid section and the rotations section?

I think that my proposal is completely inline with yours WRT points, layers, and boundaries. I think that rotations, grid, material, and size are things I'd prefer to define later.

My goal would be to have a format that purely defines what the modelling tool knows about a solid and its geometry when it is sliced. after that, i think its appropriate for another tool in the chain to fill, account for extrusion material and diamter, scatter,smother, chunk, and top the layers.

STL is a really horrible format, but everyone uses it. I think it boils down to the fact that its really simple to read and write.

My hope would be that we could create a "slice" format that's so easy to create that it would be something lots of folks would add "because its not too hard".

If we could come up with a standard, i'd happily work with Enrique to modify skeinforge to accept it as input isntead of stl.
 
Hi Dave,

Glad you made the slice exporter. Your file format is good, all I suggest you add is a line with the extrusion height for the slices. This could be derived from the "slice-z" parameters, but it's good to just have it.

The issue with a slices format is that is it an end format. Even if you could import it into another program, you would have lost some topology information.

To keep all that info you could use the step format. Unfortunately, I haven't seen a good description of the format. There is a page about it here:
http://wheger.tripod.com/step/

and a relatively simple example here:
http://www.isr.umd.edu/Labs/CIM/vm/xlator/step.html

but I haven't found anyplace that actually explains the format. There is also IGES:
http://en.wikipedia.org/wiki/IGES

Once again, I could not find an actual description of the IGES format.

It would be great if programs used the CSG rayshade format:
http://graphics.stanford.edu/~cek/rayshade/raynotes/contents.htm

but, I haven't seen any that do although I haven't looked hard and something like BRL-CAD with its many file exporters might.

To summarize, once your slices format is stable, I'll write a skeinforge import filter for it. In the long term, it'd be great if we could import the step, iges or rayshades format.
 
Guys

I have been following you discussion here and I think I can follow your thrust.

Re G code v other slice format.

G Code is actually a Bot control/tool path control code and I feel has it's place in controlling the machinery.

I think I agree that G code is a poor slice format.

For me personally their looks to be a need for a three layer approach.

Object format

Slice format

Machine Control Format

Where there is a conversion process (including the necessary cleverness for each specialism)

Given this I think it is understandable that we are struggling with making one format adequately fit all.

If you compare and contrast this with say Computer Networking. You never actually do all of this in one layer but have a stack of layers that breaks a very complex problem into a sequence of understandable solutions.

Maybe G Code has its place quite rightfully at the machine control layer (what it was designed for) and a slice layer in addition (not instead) is what is needed.

Maybe G Code is to the RepRap what HPGL or Laserjet code is to printers.
 
Hey, enrique,aka47 glad to see you comment!

I looked at RayShade, and STEP , which solidworks can create. I had done reading about IGES and found that it was largely considered too hard-- to the point STEP was created to replace it.

I also read that STEP is pretty hard also. I exported an example below. it is, well pretty complicated.

Basically, I think its pretty hard to describe a general solid, which is why the formats are complicated.

I'm ok making a few assumptions to get the file to be very simple and easy to create:

(1) i'll slice it , which converts a really hard 3-d problem into a serias of fairly easy 2-d problems

(2) i'll live with the fact that i need to always slice in the z direciton

(3) i'll live with the reality that the file is much simplier if things are converted into line segments ( rather than attempt to preserve the precision of arcs, parabolas, spline definitions, bcurves, etc.


I think that having the solid package make the three assumptions above allows creation of a dead-simple format thats easy to read and easy to port...

Solidworks can export STEP-- more particularly, STEP AP214, whatever that is.

It is a fairly complex format, but as you mention does have all of the information of the solid.

Here is what it looks like. Best i can tell #number is a reference to another feature, and you kind of walk the references to draw the solid. example:

edge loop #11 is made up of features #354,#412,#372, and #32). feature 354 is an edge, associated with edge curve 71, which is itself defined by vertex points 35 and 21. vertex point 21 is a cartesion point ( 167) with coordinates x,y,z specified.

phew that's a moutful. I think i'll just slice it instead :)

ISO-10303-21;
HEADER;
FILE_DESCRIPTION (( 'STEP AP214' ),
'1' );
FILE_NAME ('Test.STEP',
'2008-09-24T21:52:02',
( 'a' ),
( 'a' ),
'SwSTEP 2.0',
'SolidWorks 2002296',
'' );
FILE_SCHEMA (( 'AUTOMOTIVE_DESIGN' ));
ENDSEC;

DATA;
#1 = ORIENTED_EDGE ( 'NONE', *, *, #199, .F. ) ;
#2 = ORIENTED_EDGE ( 'NONE', *, *, #353, .F. ) ;
#3 = EDGE_LOOP ( 'NONE', ( #259, #90, #31, #72 ) ) ;
#4 = EDGE_CURVE ( 'NONE', #24, #21, #92, .T. ) ;
#5 = EDGE_LOOP ( 'NONE', ( #143, #400, #240, #15 ) ) ;
#6 = ORIENTED_EDGE ( 'NONE', *, *, #364, .T. ) ;
#7 = EDGE_CURVE ( 'NONE', #411, #35, #121, .T. ) ;
#8 = EDGE_CURVE ( 'NONE', #374, #379, #126, .T. ) ;
#9 = ORIENTED_EDGE ( 'NONE', *, *, #370, .T. ) ;
#10 = EDGE_CURVE ( 'NONE', #403, #391, #135, .T. ) ;
#11 = EDGE_LOOP ( 'NONE', ( #354, #412, #372, #32 ) ) ;
#12 = ORIENTED_EDGE ( 'NONE', *, *, #237, .T. ) ;
#13 = ORIENTED_EDGE ( 'NONE', *, *, #364, .F. ) ;
#14 = ORIENTED_EDGE ( 'NONE', *, *, #22, .F. ) ;
#15 = ORIENTED_EDGE ( 'NONE', *, *, #367, .T. ) ;
#16 = ORIENTED_EDGE ( 'NONE', *, *, #380, .F. ) ;
#17 = ORIENTED_EDGE ( 'NONE', *, *, #353, .T. ) ;
#18 = CLOSED_SHELL ( 'NONE', ( #140, #363, #377, #23, #52, #257, #394, #25, #179, #356, #360, #20 ) ) ;
#19 = EDGE_LOOP ( 'NONE', ( #368, #33, #408, #1 ) ) ;
#20 = ADVANCED_FACE ( 'NONE', ( #149 ), #150, .F. ) ;
#21 = VERTEX_POINT ( 'NONE', #167 ) ;
 
You guys might find this interesting:

in reseaching STEP to learn about the AP203 file format, i came across this page:

in which the replacement for Gcode is described: STEP-NC ( STEP-AP238 )

http://www.steptools.com/library/stepnc/
 
This is just a thought and Im prepared to be lectured on my ignorance :)

Would SVG work as an slice format? or rather why wouldn't it?
 
Hi, believe it or not, i thought about SVG as an option. it would be very convienient.

The biggest issue i saw was that it defines things in terms of pixels ( screen display)-- IE, i didnt see a way to have an x-y coordinate of .125 inches represented in an SVG file.

its also quite verbose-- these files can be very large

svg doesnt have the concept ( i think ) either of a loop-- though I suppose you could represent everything as polylines now that i think about it. closed loops are very important as a part of the description of the surface. it would be pretty easy in svg to define a part that does not have a set of well behaving loops.

this is one of the problems STL has too-- its just too easy to create an incorrect file.

i also think that the key to success is simplicity. When you consider all the posibilities that can exist for how to define an edge, ( circle, spline, bspline, line, parabola, ellipse, and on and on ) its very hard to "easily" do that it gets messy.

I'm going to do some thinking tonight and make a proposed format that combines the ideas of enrique, forrest, and myself.

I'll blog it as a starting proposal
 
SVG does have the capacity to have a specified units, inches millimetres etc. It usually defaults to pixels when one is not defined.

The 'path' element is simple to use and supports arcs, curves and closed loops.

Incorrectly closed loops could be an issue with svg elements and files if the are manually created, but could be correctly handled in and automated process

Size could be an issue, how important is this? are slice files intended for distribution?
 
Huh. In that case, I think that SVG might work after all. I will have another look.

I dont think file size is a huge deal-- the format I was planning on using was basically JSON, which is very flexible but also not as small as a pure STL like file

JSON and SVG both have the advantage of having parsers already available.

JSON has more parsers, but SVG has the fact that it is readily displayed, which is admittedly very nice....

what says everyone about opinions about a JSON based format vs SVG?
 
MeshLab is (a) free and (b) very good at closing holes in meshes. I mostly use it to convert weird 3D meshes into STL.

It's also handy for reducing the size of a mesh so that the more extreme examples will actually fit in memory!

Vik :v)
 
Dave,

Thanks for exporting the step file. I found definitions for it at:
http://www.steptools.com/support/stdev_docs/express/ap214/html/index.html

Indeed step is complicated, and the definitions while helpful are still not an explanation. Also there are curves, rather than just polylines, so it would be harder to parse. It would be great if it could be parsed, but it would take a lot of effort.

xsainnz,

Good point about svg. Skeinforge already uses svg to view the gcode paths in a browser, and with some additions we could use svg as input loops.

Blogger won't accept svg lines, so for the svg snippets below assume that "{" is "<" and "}" is ">".

SVG is two dimensional, but supports comments, so to add the z we could have comment lines like:
{!-- slice-z: 0.2 --}

After you mentioned the path element, I found the paths description at:
http://www.w3.org/TR/SVG11/paths.html

From the description on that page, we could make path lines like:
{path d="M 1.0 1.0 L 1.0 1.1 z" /}

For a total shape file like:

{!-- slice-z: 0.2 --}
{path d="M 1.0 1.0 L 1.0 1.1 z" /}
!-- slice-z: 0.6 --
{path d="M 1.0 1.0 L 1.0 1.1 z" /}
..

It's good that SVG can handle units, but I would prefer to keep it simple by always using millimeters.
 
'id' attributes are supported by all svg elements this should make it easier to parse. eg

{path id="slice0.2" d="M25 25 L10 10 z"/}

or

{g id="slice0.4"}
{path id="outer1" d="M0 0 h 25 v20 h-20 z"/}
{path id="inner1" d="M5 5 h5 v5 z"/}
{path id="inner2" d="M15 15 h5 v5 z"/}
{/g}
 
Enrique:

Yes, i looked at a couple of other step examples and there are lots of other elements my example didnt have.

I'm also sensitive to AOL users-- i dont think it can even export STEP so they'd be unable to get onboard and that'd make it hard to drive a standard.

I think i'm onboard with using SVG.

XML is a bit harder to write and read, but its probably worth it to get a file format that is viewable for no effort at all.

Further, SVG also supports events and animations, so it would be possible to emulate the skeinforge"skip through the layers" trick and even might be possible to "stack" the slices to resemble what the object looks like

I will switch my exporter to SVG and post some examples. I hope to get to it this weekend, but not sure I will
 
Dave,

On second thought, slice_shape in skeinforge doesn't ask for the extrusion height directly, but instead gets the "Extrusion Diameter (mm):", "Extrusion Height over Diameter (ratio):", and "Extrusion Width over Diameter (ratio):". From that it derives the extrusion height and extrusion width. So in your slice script, please input the following parameters:
"Extrusion Diameter (mm):"
"Extrusion Height over Diameter (ratio):"
"Extrusion Width over Diameter (ratio):"

preferably with defaults of 0.6 for diameter, 0.6667 for height over diameter and 1.0 for width over diameter. Then in the svg file you would derive and add the following lines before the slices:
{!--extrusionDiameter 0.6 --}
{!--extrusionHeight 0.4 --}
{!--extrusionWidth 0.6 --}

Skeinforge starts the slices at half the extrusion height and steps up by the extrusion height.. Positive area polygons ( the outer loops ) will be counterclockwise and negative spaces clockwise. So slicing a shallow rectangular box that is 30 wide, 10 deep and 0.8 thick with a vertical square hole 4 on a side would, with default extrusion parameters, look like the following:

{!--extrusionDiameter 0.6 --}
{!--extrusionHeight 0.4 --}
{!--extrusionWidth 0.6 --}
{!--slice-z 0.2 --}
{path d="M 15.0 5.0 L -15.0 5.0 L -15.0 -5.0 L 15.0 -5.0 z" /}
{path d="M 2.0 2.0 L 2.0 -2.0 L -2.0 -2.0 L -2.0 2.0 z" /}
{!--slice-z 0.6 --}
{path d="M 15.0 5.0 L -15.0 5.0 L -15.0 -5.0 L 15.0 -5.0 z" /}
{path d="M 2.0 2.0 L 2.0 -2.0 L -2.0 -2.0 L -2.0 2.0 z" /}

The above would be readable by an updated skeinforge, but it is not complete svg. To make a complete svg file, the header, width & height and footer must be added. The largest box cross section has a width of 30 and a height of 10, so the valid svg file would look like the following:

{?xml version="1.0"?}
{!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd"}
{!--extrusionDiameter 0.6 --}
{!--extrusionHeight 0.4 --}
{!--extrusionWidth 0.6 --}
{svg xmlns="http://www.w3.org/2000/svg" version="1.1" width="32.0" height="12.0"}
{g fill="none" style="fill-opacity:1.0; stroke:black; stroke-width:2;"}
{!--slice-z 0.2 --}
{path d="M 15.0 5.0 L -15.0 5.0 L -15.0 -5.0 L 15.0 -5.0 z" /}
{path d="M 2.0 2.0 L 2.0 -2.0 L -2.0 -2.0 L -2.0 2.0 z" /}
{!--slice-z 0.6 --}
{path d="M 15.0 5.0 L -15.0 5.0 L -15.0 -5.0 L 15.0 -5.0 z" /}
{path d="M 2.0 2.0 L 2.0 -2.0 L -2.0 -2.0 L -2.0 2.0 z" /}
{/g}
{/svg}

While the above will be visible in browsers, it will be upside down, tiny, the layers will be stacked and most will be cut off since it's not centered. Fortunately, xsainnz mentioned that svg has many elements. One of them is transform, as described at:
http://www.w3.org/TR/SVG11/coords.html#EstablishingANewUserSpace

The transforms include scale and translate. Vectorwrite in the analyze_plugins folder in skeinforge uses a default scale of 10.0 / extrusionWidth, with the default extrusion width that works out to 16.667 = 10.0 / 0.6. The svg element for that scale is {g transform="scale(16.667)"}. To keep the line stroke width of 2 with the scale transform, the stroke width must be divided by 16.667 to give 0.12. To keep the layers from being stacked in the browser, vectorwrite puts them one after another down the page. For readability, vectorwrite adds a left margin of 20 and centers the cross section. It puts each slice down the scaled height of the cross section plus four times the font size, which is 262.67 = 10 * 16.667 + 4 * 24. Given the box section width of 30, height of 10 and scale of 16.667, the base translation is 270 = 20 + 16.667 * 30 / 2, 179.33 = 4 * 24 + 16.667 * 10 / 2. To show what the layer is, vectorwrite adds the layer index and layer z as text, starting down at three times the font height of 24, which is 72. It adds rotating resistor colors from Nophead's preview script, which go brown, red, orange, yellow, green, blue, purple, restarting on each layer. The viewport width is multiplied by 16.667, increased by 20 for the left margin, rounded up and two added so the line is not clipped, for a total of 522 = 30 * 16.667 + 20 + 2. The viewport height is the page height times the number of layers, rounded up and two added is 528 = ceil( 2 * 262.67 ) + 2. So the svg file becomes the following:

{?xml version="1.0"?}
{!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd"}
{!--extrusionDiameter 0.6 --}
{!--extrusionHeight 0.4 --}
{!--extrusionWidth 0.6 --}
{svg xmlns="http://www.w3.org/2000/svg" version="1.1" width="522.0" height="528.0"}
{g fill="none" style="fill-opacity:1.0; stroke:black; stroke-width:0.12;"}
{text x="20" y="72" fill="black" font-size="24" style="fill-opacity:1.0; stroke:black; stroke-width:0;"}
Layer index 0, z 0.2
{/text}
{g transform="translate(270.0,179.33)"}
{g transform="scale(16.667)"}
{!--slice-z 0.2 --}
{path d="M 15.0 5.0 L -15.0 5.0 L -15.0 -5.0 L 15.0 -5.0 z" stroke="brown" /}
{path d="M 2.0 2.0 L 2.0 -2.0 L -2.0 -2.0 L -2.0 2.0 z" stroke="red" /}
{/g}
{/g}
{text x="20" y="334.67" fill="black" font-size="24" style="fill-opacity:1.0; stroke:black; stroke-width:0;"}
Layer index 1, z 0.6
{/text}
{g transform="translate(270.0,442.0)"}
{g transform="scale(16.667)"}
{!--slice-z 0.6 --}
{path d="M 15.0 5.0 L -15.0 5.0 L -15.0 -5.0 L 15.0 -5.0 z" stroke="brown" /}
{path d="M 2.0 2.0 L 2.0 -2.0 L -2.0 -2.0 L -2.0 2.0 z" stroke="red" /}
{/g}
{/g}
{/g}
{/svg}
 
Enrique

A few ideas to make the svg file smaller and easier to read

Transforms can be grouped, but be aware that different orders may have differing results

eg. {g transform="translate(270.0,179.33) scale(16.667)"}

Style sheets make manual edits and tweaking easier, but as this is an auto generated document it will also make it smaller

Your example with these changes:

{?xml version="1.0"?}
{!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd"}
{!--extrusionDiameter 0.6 --}
{!--extrusionHeight 0.4 --}
{!--extrusionWidth 0.6 --}
{svg xmlns="http://www.w3.org/2000/svg" version="1.1" width="522.0" height="528.0"}
{defs}
{style type="text/css"}{![CDATA[
text {
stroke:none;
fill:black;
font-size:24px;
}
path {
stroke-width:0.12;
fill:none;
}
]]}{/style}
{/defs}
{text x="20" y="72"}Layer index 0, z 0.2{/text}
{g transform="translate(270.0,179.33) scale(16.667)"}
{!--slice-z 0.2 --}
{path d="M 15.0 5.0 L -15.0 5.0 L -15.0 -5.0 L 15.0 -5.0 z" stroke="brown" /}
{path d="M 2.0 2.0 L 2.0 -2.0 L -2.0 -2.0 L -2.0 2.0 z" stroke="red" /}
{/g}
{text x="20" y="334.67"}Layer index 1, z 0.6{/text}
{g transform="translate(270.0,442.0) scale(16.667)"}
{!--slice-z 0.6 --}
{path d="M 15.0 5.0 L -15.0 5.0 L -15.0 -5.0 L 15.0 -5.0 z" stroke="brown" /}
{path d="M 2.0 2.0 L 2.0 -2.0 L -2.0 -2.0 L -2.0 2.0 z" stroke="red" /}
{/g}
{/svg}

I'm not sure I understand the scaling. If you want the slice to be close to 'real' size or say 2:1 when there may be a simpler way to do that, but as with most things there is usually more than one way.

I have just downloaded Skeinforge, it will be my first foray into python land :)

Mark
 
Hey, guys:

I'm planning on providing an svg that has the layers already created, IE, i'd provide a list of already sliced layers. My thought was I'd dump them into skeinforge starting with the "fill" step. At this point, you wouldnt need to re-compute the slices i thought?


Format wise, i've got a prototype working at home that allows displaying the layers, as well as an interactive slider that allows flipping through the layers.

For a single slice, it requires only one path element, because svg will already recognize subpaths and fill them correctly.

thus for each slice, one path element with a separate line for each loop works just fine:

{path d="M x,y x1,y1, z
M x3,y3 x4,y4 z

believe it or not, not only does SVG recognize this as two loops, but also it will apply a ray trace algorithm and fill it correctly so that it looks correct.

it is easy to ensure that the model fits into the correct view without any fanciness by using the viewPort option-- if your paths are specified in "user" units ( pixels by default ), then I create another viewport after I know the extents of the slice, which ensures that the whole slice fits into view.

for example, suppose that you have this:

{ svg width=400px height =300px ...

then you have this:
{ path d=" m0,0 10,20

and suppose these are in mm. suppose further that the entire model is 20x20mm.

to make sure the model is nicely sized in the view, you can put the slices into a nested svg element, like this:
{svg viewPort="0 0 20 20"

this will cause the viewer to automatically apply a transform that will size the view to fit 20x20 user units into the current viewport

i have also added some javascript and a couple of stylesheets so that the layers can be viewed one at a time with a slider bar, similar to what skeinforge does.

I will post what i have on my blog , hopefully this w/e
 
Hi xsainnz,

Thanks for showing how to simplify the svg file. I tried the combined transform line and it worked. I then tried the css section, and nothing happened in the Mozilla Firefox version 2.0.0.3 browser on suse linux. After looking through the section I saw some redundant information in my original file and removed it. So the updated svg section follows:

{svg xmlns="http://www.w3.org/2000/svg" version="1.1" width="522.0" height="528.0"}
{g fill="none" font-size="24" style="fill-opacity:1.0; stroke:black; stroke-width:0.12;"}
{text x="20" y="72" fill="black" style="stroke-width:0;"}
Layer index 0, z 0.2
{/text}
{g transform="translate(270.0,179.33) scale(16.667)"}
{!--slice-z 0.2 --}
{path d="M 15.0 5.0 L -15.0 5.0 L -15.0 -5.0 L 15.0 -5.0 z" stroke="brown" /}
{path d="M 2.0 2.0 L 2.0 -2.0 L -2.0 -2.0 L -2.0 2.0 z" stroke="red" /}
{/g}
{text x="20" y="334.67" fill="black" style="stroke-width:0;"}
Layer index 1, z 0.6
{/text}
{g transform="translate(270.0,179.33) scale(16.667)"}
{!--slice-z 0.6 --}
{path d="M 15.0 5.0 L -15.0 5.0 L -15.0 -5.0 L 15.0 -5.0 z" stroke="brown" /}
{path d="M 2.0 2.0 L 2.0 -2.0 L -2.0 -2.0 L -2.0 2.0 z" stroke="red" /}
{/g}
{/g}
{/svg}

Dave,

Slice_shape in skeinforge slices and insets the shape. Once there is a stable svg format, I'll split slice_shape into slice_shape and inset. Then we'll be able to input your file into inset and the chain will take it from there.

Your viewport and slide show sounds good. All I want is for everything to be in as few files as possible and to work on most browsers. There is no need to worry about file size because the slices file is roughly twenty times smaller than the final gcode file.
 
sweet, ok. I have opera and firefox so i'll try it out on those.

I was able to get the file very compact and small. i'm hoping to actually export a non-trivial part for demonstration.

This is awesome-- though STL is nice this toolchain will work a lot better i think.
 
Hi Dave,

After I wrote my last post I remembered to try your combined path line. It worked perfectly in Firefox, so the updated svg section is below. I know that this will be superseded by your viewpoint method, I am just posting it to show the path element format that skeinforge could parse.

Indeed, your slice script could finally get around the triangle mesh hole bug; which has been around for years;)

{g fill="black" font-size="24" style="fill-opacity:1.0; stroke:red; stroke-width:0.12;"}
{text x="20" y="72"}
Layer index 0, z 0.2
{/text}
{g transform="translate(270.0,179.33) scale(16.667)"}
{!--slice-z 0.2 --}
{path d="M 15.0 5.0 L -15.0 5.0 L -15.0 -5.0 L 15.0 -5.0 z M 2.0 2.0 L 2.0 -2.0 L -2.0 -2.0 L -2.0 2.0 z" /}
{/g}
{text x="20" y="334.67"}
Layer index 1, z 0.6
{/text}
{g transform="translate(270.0,442.0) scale(16.667)"}
{!--slice-z 0.6 --}
{path d="M 15.0 5.0 L -15.0 5.0 L -15.0 -5.0 L 15.0 -5.0 z M 2.0 2.0 L 2.0 -2.0 L -2.0 -2.0 L -2.0 2.0 z" /}
{/g}
{/g}
 
On file formats etc.

Readable without a specialized editor ie text not binary is great.

An Open Source format is great also. Saves some obstructive organization undermining the good work that is/has been done.

From the snipets SVG looks good how is it on the Open Source front ??
 
On file formats etc.

Readable without a specialized editor ie text not binary is great.

An Open Source format is great also. Saves some obstructive organization undermining the good work that is/has been done.

From the snipets SVG looks good how is it on the Open Source front ??
 
aka47

The SVG specification is an open standard that has been developed by the World Wide Web Consortium (W3C)

For more info:
http://en.wikipedia.org/wiki/Svg
http://www.w3.org/Graphics/SVG/
 
Hey, Folks,

I have completed a kind of functional version of the svg slicer.

You can see the full blog post here:

http://cncfdm.blogspot.com/

Alternately, you can skip to the "punchline" and view the svg i came up with here:

http://home.bluedirt.org/slicer/TestPart.svg

( there's no easy way to post the file in the blog. )

A few features to note:
* the format aims to be as easy to machine parse as possible, while making it nice to look at
* the format aims to accomodate parts with different dimensions and units without changing the main file.
* I use the metadata tag allowed by svg to store data associated with slices.

I think this format is a pretty good start. a stripped down version ( that is not nice to view as a human but would work to communicate slice info ) would essentially be the section indicated by the MACINE CREATED markers and the metadata element.

This version is the minimum version with just the data, but no human friendly stuff:

http://home.bluedirt.org/slicer/TestPartSmall.svg
 
Oh, as I made the plugin I found several issues i'm working through:

(1) the approach i use to slice is to create a plane, and then "cut" the solid with the plane and then traverse the face. Solidworks seems to have a bug doing the cut for some shapes. This is a show-stopper if i cannot fix it.

(2) it became clear that it'd be nice to allow slicing with planes in any direction, rather than just z, since some of my models were not oriented in the ideal slicing direction. that should be easy

(3) it would really be nice to add an isometric image of the part into the svg, so that a human viewer can see what the part looks like this wouldnt be too hard

(4) i'd like to modify the javascript to display the coordinates of the cursor in model space

Right now item (1) is a complete show-stopper
 
Hi Dave,

Thanks for posting the svg file. The svg, stylesheet and javascript worked on Firefox. It didn't work on Konqueror 3.5.1, but that's an old version.

If the Solidworks bug prevents you from slicing in Solidworks, that's ok because you could still slice an Art of Illusion file. In Art of Illusion you can export the scene as an XML file. In that file are all the Constructive Solid Geometry shapes, so after lots of parsing, transforming and slicing you could slice Art of Illusion. It would take a long time to write a script, but all the information is there so in theory there is no bug that could stop you.

xsainnz,

After trying out Dave's script, I realized that CSS uses curly brackets. So I replaced the greater and less than symbols with curly brackets and everything worked in Firefox. It still didn't work in my old version of Konqueror, so I'll keep using the non CSS version. I realize that most people will have a Firefox or another good SVG browser, but I prefer a file format which works on everything, even if it means the file will be slightly larger and less readable.

Thanks to your explanation of SVG, within a couple months skeinforge will use SVG between slice and inset. Within a long while we will be able to get slices from Art of Illusion at least.
 
Eureka!

I'm a happy guy. I finally figured out that though you'd _think_ a plane is a surface, it is really not. I was slicing with a reference plane ( which sometimes works), but what always works is to slice with a first-class surface.

After doing this trick, the slice routine works perfectly with all my parts....

Woo! Next i'll add the code to compute the part's bounding box, and then I'll have a workable solution.

If anyone else is using solidworks, let me know and i'll provide the macro source.
 
After Forrest tried out the Meshlab SVG slicer, I posted on the Meshlab user forum at:
http://sourceforge.net/forum/forum.php?thread_id=2302201&forum_id=499532

and asked if they would be interested in using transforms in their format. Paolo Cignoni quickly answered that "the svg transform group is a nice idea. Retaining original values has a certain value...
I will probably bring it in our svg exporter."

I suggest we continue this thread at the Meshlab thread and try to make a common format for slicing, for Solidworks and Meshlab.
 
Enrique

Glad you sorted out the style sheet, if as you say they are not supported by everything (they should be! :)) then perhaps it is better to just use the element attributes

Dave

Kudos, your svg output looks great!
 
Thanks,xsainnz:

We're working on the format over the meshlab forums if you want to head over...
 
Hey, Enrique:

You know your vision of having skeinforge read a STEP file and then slice it?

There might be a way that's easier than you think.

this project is a pyhton binding to OpenCascade, a free/os modelling kernel.

http://www.pythonocc.org/
Its pretty much just done with swik.

I downloaded the docs for opencascade, and it is a fully funtional Brep libary, which would have all the functions necessary to slice, dice, etc. I also can read/write STL, STEP, and IGES :)

Many companies use it as a basis to devleop their own custom in-house modelling tools.

http://www.opencascade.org

with the python bindings, it would be possible to add to skienforge the ability to read STEP. It might also make offsetting and filling alorithms easier with access to all thos functions...
 
Post a Comment

Links to this post:

Create a Link



<< Home

This page is powered by Blogger. Isn't yours?

Subscribe to
Posts [Atom]