OrcaSlicer: a community fork of Bambu Studio for calibrating your own printer

What OrcaSlicer solves, and who ends up using it

A stock slicer ships profiles for the printers its vendor sells. If your machine is a Voron you built, a RatRig, a VzBot, a Creality or a FlashForge, the profile that matters may not exist, and the settings that make a print succeed live in a spreadsheet, a forum thread or your memory. OrcaSlicer is a G-code generator distributed under AGPL-3.0 that treats calibration as a first-class part of the interface rather than something you do in a separate program. The README lists temperature towers, flow rate and retraction tests under Advanced Calibration Tools, and points at a wiki page for the calibration guide. The audience is therefore narrower than a general slicer's: people who are willing to run a test print, measure the result, and write the number back into a profile. If you want a slicer that is correct out of the box for the printer on your desk, that is a different product category, and OrcaSlicer will feel like work.

Where the code comes from and how a model becomes G-code

The repository is a C++ application built with CMake. The top level holds CMakeLists.txt, a cmake/ directory, deps/ and deps_src/ for vendored dependencies, src/ for the application, tests/, tools/, resources/ and localization/, plus per-platform build scripts: build_linux.sh, build_release_macos.sh, build_release.bat, build_release_vs2022.bat and build_flatpak.sh. That layout is the familiar shape of a desktop application that links a slicing engine, so the pipeline is the conventional one: import a mesh, apply a printer profile and a process profile, slice into toolpaths, preview the layers, then export G-code for the printer or send it over the network. Network support is listed for Klipper, PrusaLink and OctoPrint, which means the send step talks to the printer's own host rather than a vendor account. The interesting design choice is that calibration tests are generated by the same slicer that will later print your parts. A temperature tower sliced with your profile uses your profile's speeds and cooling, so the number you derive is measured under the conditions you will actually print in. The cost of that choice is that the calibration routines inherit every quirk of the profile you are trying to fix.

Installing OrcaSlicer and running a first calibration print

The README sends you to the releases page rather than to a package manager. On Windows there are x64 and arm64 installer executables, and a portable build is offered for convenience; the troubleshooting note says that if the build will not start you may need the Microsoft Edge WebView2 runtime and the vcredist2019_x64 redistributable. On Linux the repository ships build_linux.sh and build_flatpak.sh alongside the release artifacts, and the README's install section is organised by platform, so treat the release page as the primary source rather than a distribution package. There is no command-line installation step documented in the README; the steps below are the build scripts present in the repository, not a claim that a packaged build exists.

# From a clone of the repository, on Linux
git clone https://github.com/OrcaSlicer/OrcaSlicer.git
cd OrcaSlicer
./build_linux.sh

On Windows the equivalent entry point is a batch file at the repository root.

build_release.bat

The README also publishes a Flatpak build script, which is the closest thing to a distribution-style install the repository documents.

./build_flatpak.sh

Once the application is open, the workflow the README describes is: pick the profile that matches your printer, then run a calibration test before trusting a long print. The calibration guide is linked from the main features list as a wiki page, and it covers temperature towers, flow rate and retraction. The practical order is temperature first, then flow rate, then retraction, because a wrong temperature changes the extrusion behaviour that the other two tests measure. After each test you edit the profile and re-slice; the README does not describe a wizard that writes the result back for you. Nightly builds are published separately under the nightly-builds tag and the README asks for feedback on them, so keep a stable release installed alongside if you depend on the machine for work.

Belt printers are a parallel build, not a merged feature

The nightly release ships two artifacts distinguished by a filename suffix. The standard build has no suffix; the belt build carries _belt, for example OrcaSlicer_Windows_Installer_x64_nightly_belt.exe. The README states that belt support adds slicing against a tilted belt surface instead of a flat bed, with belt printer profiles, mesh rotation and G-code transforms, belt-aware support generation and a tilted-bed preview. It also states plainly that this work is under active development and is not yet merged into main, that it ships only in the parallel _belt builds produced from the belt-printer branch, and points at tracking PR #14394 and the original documentation in #12998. Read that as a boundary rather than a caveat. If you own an infinite-Z conveyor printer and you install the standard nightly, you will not get belt slicing, and if you install the _belt build you are running a branch that the project itself describes as unfinished. This is the clearest case where OrcaSlicer is the wrong tool: a production belt printer running a paid job should not be sliced from a branch that has not landed.

How OrcaSlicer differs from Bambu Studio and from Cura

OrcaSlicer is a fork of Bambu Studio, so the two share an interface lineage and much of the settings vocabulary. The difference is direction of travel. Bambu Studio is developed by the printer vendor and is tuned around Bambu Lab hardware and its cloud workflow; OrcaSlicer is community driven, and its feature list is organised around printers from several vendors, with profiles for Bambu Lab, Prusa, Creality, Voron and others. That is why OrcaSlicer exposes controls such as precise wall, seam control with scarf seams, sandwich mode, polyholes and overhang optimisation, and why its calibration suite is in the application rather than in a companion tool. Cura is a different comparison. It is also an open source slicer with a large profile library, but its calibration story is largely external: you find a test model, slice it, and interpret the result yourself. OrcaSlicer generates the test from your profile. The trade-off is that OrcaSlicer's defaults assume you will tune them, and the wiki exists because many settings are not self-explanatory. If you want a slicer that hides its parameters, neither of these is it, but Cura hides more of them.

Licence, maintenance and what upgrading actually costs

OrcaSlicer is licensed AGPL-3.0, and the licence file is at the repository root as LICENSE.txt. The practical consequence for a workshop or a small business is that if you modify the slicer and let other people use it over a network, the AGPL's source-availability terms are the ones to read; that is a description of the licence, not legal advice, and anyone distributing a modified build should read the licence text itself. On maintenance, the picture is mixed and worth stating precisely. The repository is not archived, and the last push to the default branch was on 2024-11-21. The release list shows v2.4.1 on 2026-06-28 and v2.4.2 on 2026-07-07, so tagged releases have continued even though the default branch has not moved since November 2024. That gap matters for anyone tracking main. Upgrading between stable releases carries the usual cost of re-checking profiles, because a process profile tuned against one version may not produce identical G-code in the next. The nightly channel is where the belt work lives, and the README asks for feedback on those builds, which is an invitation to test rather than to depend. If you pin a version, pin it deliberately and keep the profile bundle with it.

Editorial conclusion

Adopt OrcaSlicer if you own a printer whose profiles are incomplete elsewhere, or if you want temperature, flow rate and retraction calibration built into the slicer instead of a separate toolchain. Do not adopt it for a Bambu Lab machine you are happy running from Bambu Studio with the vendor cloud, and do not adopt it for a belt or conveyor printer expecting a finished feature: the _belt nightly builds come from the belt-printer branch and are not merged into main. Before committing, verify three things on your own hardware: that a profile exists for your exact model, that your firmware accepts the G-code flavour the profile emits, and that the release you downloaded matches the version you intend to keep.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes