Syndicate This Blog |
MeshlabMonday, September 29. 2008
In which your narrator, unable to find the "simplify mesh"
command in a newly downloaded copy of Art of Illusion rashly asks the rest of
the core Reprap team where it is to be found these days...
Since getting the positioning robot of Tommelise 2 running properly some
time ago, I've spent most of my time milling plastic and steel. Doing that
quickly revealed the lamentable state of my PC-side Slice and Dice software
which means that for every hour I've spent milling this or that I've spent 4-5
hours sorting out problems in Slice and Dice.
The slicing module started out being reasonably stable, if a bit slow. Most
of the development action has been happening in the dicing routines. Efficient
milling of objects requires that Slice and Dice do things that aren't necessary
for additive extrusion like FFF.
Last night, I pretty much got everything running using my usual software development paradigm, viz, writing a horrifyingly complex piece of code (not necessarily the same thing as a BIG piece of code) and spending weeks getting it
running properly only to realise that there is a much simpler way of doing the
job. The code in question was one which collected and linked together minute
line segments generated by my grid approach to dicing. About dark on Sunday, I
realized that a simple agent routine could probably do the dicing job that I'd
been struggling to make work. Three hours later, the agent was written, tested
and commissioned in Slice and Dice.
In testing the agent module, I began to run up against an Art of Illusion-related problem. While AoI does a fair job of converting solids
descriptions to STLs it does tend to rather proliferate surface meshes. A small,
40-toothed involute profile gear that I'd designed required about 175,000 mesh
triangles to describe it. Much of this complexity comes as a result of doing the
#D boolean operations needed to convert a gear profile into a solid object
description.
There used to be and may still be, for all I know, a command in AoI called "simplify mesh" which could greatly reduce the complexity of such AoI surface
meshes. Unfortunately, I've been working on the positioning robot for Tommelise
2.0 for a long, long time and had bought a new PC during that time. As a result,
I'd not run AoI and had got quite rusty with its use. When I downloaded and
installed the latest version. That's when I got rash and put out a RFI to the
core Reprap team asking for assistance in finding the "simplify mesh" command in
the newest AoI release.
Vik, ever helpful, responded within a few hours that I ought to take a look
at a new open-source package that he'd discovered the previous week called Meshlab. I quickly downloaded and
installed Meshlab and had a go with it. I'd hoped for a simple routine that
simply ate big STL files and spit out smaller, more efficient ones. When I
imported my 40-toothed gear milling project into Meshlab, I realised that I'd
got considerably more than that.
That done, I discovered that Meshlab had reduced the complexity of my original mesh by 50% instead of the 75% that I'd originally thought it had. While poking around looking for an option in Meshlab to save STL files in ASCII format I noticed a little button consisting of a cylinder with a number of planes cutting through it.
A small window popped up that allowed me not only to cut my object with a plane, but instead let me slice it with a set of parallel planes set at standard distances from one another which could be easily set. Not only that, it allowed me to save the resulting information in SVG (Scalable Vector Graphics) format, a variety of XML.
The biggest shock was the speed with which it could do this slicing. I'd been rather proud that my Slice routine could cut a slice something of the complexity of my gear project in a matter of a couple of minutes. Imagine my mortification when Meshlab did a dozen slices of the same project in the blink of an eye. Reading a bit more about the Meshlab project, they have some 32 programmers working on the code. From the looks of things they're also quite good programmers who know their geometry. While I tend to trust my own coding, largely because if I need it to do something special I can get in and alter it to do that something special with relative ease, I know when I'm beaten. If the slicing routine in Meshlab is doing what it appears to be doing, I'm retiring by slice module and using Meshlab instead. Trackbacks
Trackback specific URI for this entry
No Trackbacks
Comments
Display comments as
(Linear | Threaded)
Simplfy mesh is an option in the AOI solid editor, which is a plugin that you have to install first.
I'll also have another look at meshlab. There's always so much to find out when walking unpaved roads :)
Isn't your code written in Java? Java is about 50 times slower than C++ - so a good fraction of your problem is the language you chose.
For a problem like this, in-fact most programming tasks, the algorithm is far more important than the implementation language.
From about 24 min for 12 slices to 'in the blink of an eye' I’m going to call roughly two orders of magnitude. In speed comparisons between programs implemented in multiple languages, such as VB, C++ or Java, the differences are normally less than 20%; still hundreds of times smaller than the speed increase here.
‘Java is about 50 times slower than C++’ is just plain untrue for non-trivial programmes:
http://www.idiom.com/~zilla/Computer/javaCbenchmark.html
For fun you might like to look at:
http://shootout.alioth.debian.org/
But remember it’s a game, the results are not necessarily indicative of anything. You will find 50x differences here but normally there is an algorithm difference between the implementations.
|
