Eleven days after a feature-heavy alpha, OrcaSlicer has moved its next major version to beta. The V2.5.0 Beta release notes, published by SoftFever on October 27 under the tag v2.5.0-beta (commit 345efec) and marked as a pre-release, do more than tidy up the alpha. The beta adds toolhead collision volumes that printer profiles can define, a travel planner that shortens the route on every print, faster sparse infill, and slicing that runs up to twice as fast on detailed models. It also changes something that matters to anyone with tuned profiles: every print's G-code will change.
The 2.5.0 Alpha, released October 16, carried the headline features: Python plugins, belt printer support, an experimental Design tab, color mixing, Texture Displacement, and printing 2-4 parts at once on IDEX and IQEX machines. The project called it the most feature-packed release in its history, built from more than 950 pull requests by over 140 contributors. The beta builds on the alpha with new features and fixes for problems reported since. This piece covers what changed.
Telling the slicer where the obstacles are
The largest new feature is toolhead collision volumes, contributed by Harry-Loud in PR 13777. It closes two long-standing issues, #5922 and #10579. The problem is familiar to anyone whose printer has hardware sitting above the build surface, such as bed clips, raised tool docks or camera arms. Printer profiles can now tell the slicer about them.
Profiles describe these obstacles as polygonal prisms. Each one either runs the full height of the machine or covers only a set Z range, so a low bed clip doesn't wall off the space above it. The Toolhead collision volumes setting sits below Excluded bed area in Printer settings > Basic information > Printable space, and you need Advanced mode to see it. Objects that touch a volume are flagged, with the overlap shown in red.
Coverage is broad but not complete. Arrange and Fill Bed respect the volumes, taking their height into account, so an object can still sit under a raised one. Brims and normal supports are clipped around them, Organic tree supports steer their branches around them, and travel moves are rerouted where a safe path exists. The Tree Slim, Strong and Hybrid support styles do not yet. When a sliced G-code move crosses a defined volume, OrcaSlicer scans the G-code as a final check and warns about it. The scan has a blind spot, though: it cannot see moves hidden inside firmware macros. If your start G-code calls a purge or wipe macro that sweeps across the bed, OrcaSlicer won't know where that motion goes.
Multi-extruder machines get three modes through the Collision volume behavior setting. Shared applies one set of volumes to every extruder. Toolhead-relative follows each nozzle's offset. Individual per extruder lets you set volumes separately for each one. Printers without collision volumes slice exactly as before.
Shorter travel on every print
The change most users will notice without touching a setting is the new travel planning in PRs 16492 and 16743, by ianalexis and gloth-3ds. OrcaSlicer now builds a shorter travel route on every print, and the release notes include benchmark numbers.
On a benchmark plate, travel distance fell by 6 to 26 percent and estimated print time by 1 to 6.5 percent. On prints of 10 to 13 hours, that works out to 6 to 45 minutes saved. Slicing took at most 2.1 percent longer. Infill, ironing and support paths also print in a shorter order, and gap fill on Monotonic and other fixed-order surfaces now prints as the nozzle passes it instead of at the end. With Apply gap fill set to Everywhere or Top and bottom surfaces, that saved 538 retractions on a 15-hour print.
The notes also report a case that went the other way. A dense plate of Benchy copies printed with a 0.2 mm nozzle saw its estimated time rise 3.6 percent, even though travel fell 6.5 percent. According to the notes, more short hops on that plate crossed the retraction threshold, so less travel did not always mean a faster print. The maintainers' general warning applies here too: expect every print's G-code to change.
Infill, arcs and precision
Sparse infill also gets faster. PRs 16694 and 16707 round off its corners evenly. With Sparse infill smooth factor at 100 percent, the notes report up to 29 percent faster infill than with smoothing off, measured with the Octagram Spiral pattern. A Hilbert Curve print on a Snapmaker U1 took 16 percent less time than with the previous rounding. Klipper and Marlin 2 slow down at each junction according to how sharply it turns, so the toolhead keeps more of its speed through the curves.
The other changes in this group are smaller:
- Arc fitting, Sparse infill only (PR 16747): a new mode that applies arc fitting just to sparse infill instead of the whole print.
- Top/Bottom paint penetration layers (PR 16818): new settings that control how far painted regions reach through top and bottom layers.
- High precision G-code (PR 16568, experimental): positions are written with four decimals instead of three and extrusion with six instead of five. On the author's test cylinder, outer-wall flow variation fell from 1.2 percent to 0.09 percent. The trade-off is G-code files about 10 percent larger.
- Klipper-accurate time estimates (PR 15545): on Klipper printers, one QIDI print that actually took 9h08m used to be estimated at 7h44m and is now estimated at 8h34m, or 9h02m once the square corner velocity matches the printer's config. That's still short at default, but much closer.
Speed and stability
The beta also says slicing is up to twice as fast on detailed models, and many times faster on objects made of thousands of parts. Translucent filaments now show as see-through in Preview. Several platform bugs are fixed, including Mesh Boolean on Windows, random crashes on Apple silicon, and hangs on exit.
What It Means for Makers
This beta is not a cleanup release. The travel planner and infill changes affect every print. Because G-code output changes across the board, a profile you tuned on 2.4 may not behave exactly the same. Back up your profiles before installing. Then reslice a known-good part and compare it with the old output before trusting the beta with a long job.
Collision volumes are the main reason to try the beta if your printer has hardware above the bed. To use them well, profile authors need to describe the obstacles accurately. Users need to remember that Tree Slim, Strong and Hybrid supports ignore the volumes for now, and that macro-driven moves won't show up in the G-code scan. Treat a clean scan as reassuring, not as proof that nothing will hit.
Klipper owners get time estimates closer to reality. Anyone chasing surface quality can try the High precision G-code option, as long as they accept the larger files and its experimental status. This is still a pre-release. The numbers above come from the project's own benchmarks, so confirm them on your own machine.
