Loading
DaveD

gcode decimation program

by DaveD Sep 8, 2010
Download All Files

Thing Apps Enabled

Please Login to Comment

That's pretty cool. Though I usually just use the "Remove Doubles" in Blender with a high-ish (0.5mm) threshold to chop down the vertex count before I print.

Sheesh.. Now he tells me the easy way to do it...

There's also a few other ways to save poly count in Blender (after all, it's designed for creating animation and game content, both of which do best if you keep the base mesh as low-detail as possible) which can be integrated (with varying degrees of effort) into a design workflow.

There's the decimate option, which I think hasn't made it to 2.5 yet but hopefully soon, which reduces polygon count with some error routine to try and stay "true" to the mesh. I think this would do fairly bad on sharp corners though...

There's also subdivision surface modeling, which is nice in
that you can make round holes that start as /square/ then subdivide them into rounded ones, based on how many levels of subdivision you use. Exporting at a low subdivision for print then acts as natural poly reduction with geometry already specified for things like sharp edges.

However, a skein-l
evel slice simplifier has definite advantages. For one, it doesn't rely on the user (and thus, some thing you may have got off Thingiverse and don't want to mess with) to take good care of the mesh, and for two, it can correct automatically geometry problems which might be very tough in a mesher or
dog help you, OpenSCAD.

V2 uploaded, which fixes a couple potential exceptions and the zig-zag/perimeter problems of V1 and processes the file a LOT faster..

I'm not sure the default min-size of 0.25mm is really the best, but I'm also not sure it's wrong. If people actually use this and find it's too small or large, please comment..

I usually try to make my .stl poly count smaller to help with this but I like the idea of having the option of processing the gcode after the fact. especially if you run across a file someone else has created with a high poly count.

@Dave: Very cool! I can't wait to try this out.

Hmm, rather than removing close points, which causes the zig-zag problem and misalignment of long segments that follow a curve with short segments as also shown in your example....

(pause for breath)

I thought - only remove point if its angle to following/preceding points is less than, say, 20 degrees. This would prune circles. Then I thought, why have the 'close together' requirement at all - even long lines with small angles could have points removed.

Then I thought - it isnt about the closeness OR angle between points - it is about the impact on the shape of removing points.

SO - how about measuring the impact of removing ANY point and having an 'impact threshold' ?

Eg, Length*offset. Long lines moved a tiny bit = big impact. Tiny lines moved a lot = big impact.

I dont know how to calculate 'movement' though.

Hm.. Iinteresting idea.

The problem I was trying to solve (or at least help) was the X/Y slowdown and subsequent blobbing that happens when you feed the machine too much detail - too many lines in too small of an area.

Within a layer, is there really anything else that has a negative impact to the print? I guess the goa
l is really to remove/change bits that hurt the print, while changing as little as possible.

Between layers, I was thinking about comparing the last point on the previous layer and the first point on the next layer. If that distance is below some threahold, remove the extruder off/on commands that
skeinforge always inserts. I'd have to test that out to see if it actually helps, though.

I suspect a new version of this will be coming tonight or sometime soon .. I think I can safely have the code look at the next command and allow a short-line through if next step is a long one or a non-G1 comm
and. That would (in theory) solve the problem with the perimeter overlap and would help things like that picture of the bolt hole not being as closed.

Nice! Too bad its Windows only. And I agree no python :)

Beautiful! Could really use this on my bot, as it has an /especially/ bad time with short stops due to the terrible custom firmware necessary with the ancient hardware I'm on.

If I ever have time ever again, I'll think about folding this into SuperSkein!

becasue I don't havea bot handy right now, can someone post some examples and maybe a time estimate?

Print time shouldn't really improve. I'd be suprised if you got 1% better.

Run time totally depends on your system and layer height and fill rate and etc, etc but my 4-5 year old PC went through http://www.thingiverse.com/thing:3628http://www.thingiverse.com/thi... in about 2 seconds. It's pretty quick.

I don't have any pictures of prints with it yet..

Bre Pettis in 3D!
by bre