Perché esistono così tanti slicer “derivati”
Nel mondo FFF/FDM, gran parte dei software di slicing più diffusi condivide una genealogia tecnica: Slic3r ha dato origine (direttamente o indirettamente) a numerosi progetti, tra cui PrusaSlicer di Prusa Research; da lì sono nati altri fork e personalizzazioni da parte di aziende e community. Questa “famiglia” comune ha un vantaggio evidente: si parte da una base collaudata, con anni di sviluppo e ottimizzazioni. Il rovescio della medaglia è che, col tempo, la stratificazione di patch, dipendenze e compromessi rende più difficile intervenire sulle fondamenta senza rischiare regressioni.
oozeBot e preFlight: obiettivo dichiarato
oozeBot (team con base in Georgia, Stati Uniti) ha annunciato preFlight, uno slicer open source definito “The Engineer’s Slicer”, presentato come successore “spirituale” di PrusaSlicer ma con una revisione profonda del codice e dell’intero ecosistema di dipendenze. L’idea non è aggiungere una manciata di funzioni cosmetiche a un fork, ma spostare il progetto su una base tecnica più moderna, rendendo poco sensato l’allineamento continuo con l’upstream originale.
Il punto centrale: ridurre il “debito tecnico” con un rifacimento dell’architettura
In informatica, il “debito tecnico” è una metafora: scelte rapide o stratificate nel tempo funzionano, ma rendono più costoso e rischioso ogni cambiamento futuro. preFlight nasce esplicitamente con l’ambizione di “pagare” parte di quel debito intervenendo sotto il cofano: il cambiamento chiave dichiarato è l’adozione di una architettura realmente 64-bit lungo tutta la pipeline, con l’obiettivo di evitare problemi come overflow di coordinate e comportamenti silenziosi difficili da diagnosticare, che in software geometrici e di slicing possono emergere su modelli complessi o catene di elaborazione molto lunghe.
Stack modernizzato: librerie e toolchain aggiornati
oozeBot dichiara di aver aggiornato pesantemente lo stack: C++20, Boost, CGAL, OpenCASCADE, Eigen e Clipper2 sono citati come componenti centrali. In pratica significa riallineare il progetto a librerie e standard moderni che, nel mondo della geometria computazionale, incidono su robustezza degli algoritmi (intersezioni, offset, unioni di poligoni), gestione delle mesh e stabilità numerica. L’obiettivo non è “fare lo stesso più veloce” in modo generico, ma rendere più prevedibili e controllabili i casi limite che spesso si presentano nello slicing reale.
Geometria e precisione: perché Clipper2 e i decimali contano
preFlight mette l’accento sulla precisione della geometria, dichiarando l’uso di Clipper2 con compilazione a precisione elevata (indicata come 10 decimali). In un slicer, gran parte del lavoro è trasformare superfici e volumi in contorni 2D layer-by-layer, facendo operazioni come offset dei perimetri, generazione di riempimenti e gestione di pareti sottili: sono tutti passaggi in cui la robustezza numerica e le scelte di rappresentazione (interi/scalatura/precisione) incidono su artefatti, micro-gap e risultati incoerenti tra una scena e l’altra. preFlight prova a rendere questi passaggi più “ingegnerizzabili”, cioè meno dipendenti da euristiche opache.
Elaborazione “in memoria”: meno file temporanei, pipeline più lineare
Un altro punto dichiarato è l’eliminazione dei file temporanei durante l’elaborazione, con una pipeline di processing “in-memory”. Questo tipo di scelta tende a ridurre colli di bottiglia di I/O, semplificare la diagnostica (meno passaggi intermedi su disco) e, se implementata bene, anche contenere alcuni picchi di utilizzo di risorse. oozeBot comunica anche una riduzione dell’uso di RAM rispetto a workflow equivalenti, presentandolo come conseguenza della riorganizzazione interna.
Athena: controllo esplicito dell’overlap tra perimetri
Sul fronte funzioni utente, la novità più caratteristica è Athena Perimeter Generator, presentato come fork/derivazione concettuale di Arachne. Qui il punto non è “variabile sì/no” sulla larghezza di estrusione, ma la possibilità di controllare in modo indipendente quanta sovrapposizione (overlap) deve esserci tra perimetri interni ed esterni. L’overlap automatico può andare bene per profili generalisti, ma chi vuole ottimizzare per resistenza, flessibilità o estetica spesso cerca controlli più diretti: oozeBot dichiara persino la possibilità di impostare overlap negativo per creare gap voluti tra linee in casi particolari (materiali morbidi o strategie specifiche).
Interlocking Perimeters: “incastro” in XY per migliorare l’adesione tra layer
preFlight introduce anche Interlocking Perimeters, una tecnica che mira a migliorare l’adesione tra strati senza variare le altezze Z: invece di alternare layer “mezzi/ pieni” (approccio spesso discusso nella community con vari nomi), qui l’idea è spostare in XY alcune traiettorie su layer alternati e compensare con una gestione mirata dell’estrusione per riempire gli spazi e creare superfici di contatto più favorevoli. oozeBot parla di un incremento di resistenza tra layer nell’ordine del 5–15% come stima dichiarata e sottolinea che non dovrebbe aggiungere tempo di stampa, perché la quantità di percorso resta comparabile.
Stato del progetto, piattaforme e download
preFlight è distribuito come open source con licenza AGPL-3.0. Nella fase iniziale è stato presentato come disponibile su Windows, ma nelle release pubbliche di febbraio 2026 compaiono aggiornamenti rapidi: una release del 10 febbraio 2026 indica supporto Linux nativo tramite AppImage (eseguibile “single-file”), mentre per macOS viene indicato lavoro in corso. oozeBot chiede anche attenzione al tema sicurezza: i download ufficiali vengono concentrati sulle release GitHub e i binari Windows risultano firmati digitalmente dalla società, con indicazioni operative per verificare la firma prima dell’esecuzione.
Perché questa mossa può interessare anche altri attori
Il punto interessante non è soltanto “un altro slicer”, ma il messaggio che manda alla filiera: se uno dei problemi strutturali della famiglia Slic3r/PrusaSlicer è la difficoltà di cambiare fondamenta senza rompere compatibilità, un fork che decide di rifare lo stack può diventare un riferimento tecnico (anche solo come “prova” che certe scelte si possono fare). Nel panorama attuale, dove aziende come Bambu Lab, Prusa Research, e vari brand che distribuiscono slicer personalizzati basati su progetti esistenti competono anche sull’esperienza software, la qualità della base geometrica e la manutenibilità del codice restano fattori che prima o poi si traducono in bug, profili più affidabili e funzioni implementabili (o non implementabili).
