Die bekanntesten Slicer für RepRaps sind: * Slic3r (Perl) * Skeinforge (Python) * Miracle-Grue (C++) Ich habe mal ein paar Timing-Benchmarks mit verschiedenen Modells für alle drei Slicer gemacht: * Bukobot Glider, 4236 Dreiecke [http://www.thingiverse.com/thing:22268] * Bunny, 69964 Dreiecke [http://www.thingiverse.com/thing:3731] * Eiffeltower, 139994 Dreiecke [http://www.thingiverse.com/thing:22051] * Yoda, 198530 Dreiecke [http://www.thingiverse.com/thing:14104] Testsetup: Ubuntu 12.04, Intel Core i5 (2.7 GHz), 6 GB DDR3 RAM. Hier die Ergebnisse: [[Image(SlicerBenchmark.png)]] Gemessen wurde das erzeugen von G-Code aus STL-Files, welches auch das Parsen der STL-Files beinhaltet. Um die Slicer mal auf Herz und Nieren zu überprüfen, habe ich ein Modell mit 969788 Dreiecken geslicet. [http://www.thingiverse.com/thing:26369] Dabei gingen alle Slicer so ziemlich in die Knie (die Messwerte im folgenden Diagramm sind Minuten!). Auf meinem Laptop ist der Slic3r wegen zu hohen Speicherverbrauchs abstürzt und hat keinen G-Code produziert, deshalb habe ich den Benchmark noch mal auf meiner Workstation wiederholt (Ubuntu 12.04,AMD FX 8120 / 3.1 GHz (8 Cores), 16 GB DDR3 RAM). [[Image(IFS_tree3_benchmark.png)]] Der Slic3r verbrauchte dabei mit 12.1 Gb (sic!) am meisten Speicher, gefolgt von Skeinforge mit 2.2 Gb und Miracle-Grue mit 1.6 Gb. Von Multithreading machte nur der Slic3r Gebrauch und das auch nur marginal. Auffällig ist, das Slic3r bei diesem STL-File schneller ist als Miracle-Grue, obwohl ersterer in Perl und letzterer in C++ geschrieben ist. Augenscheinlich spielt also nicht nur die Programmiersprache, sondern auch die Komplexitätsklassen der Slicing-Algorithmen eine Rolle.