I am in process of trying to install Bambu Studio on a Raspberry Pi 4B and do not want to go down any deep rabbit holes if I can avoid it.
Over on the Bambu Lab Github pages there are instructions about the process.
I’m at this stage but in a holding pattern to sort this out.
Is this block in red important about the directory structure? My pi projects so far have not required specific directories which in turn have specific files in them but I know you can mess up if the structure is wrong.
Does the Ubuntu zip file have some default folders it will try and create or can I extract everything to a folder of my choosing.
I have not seen anything on the wiki that gets into installation on any Linux distribution.
There is a flatpak option also.
The last time I went down this rabbit hole I tried compiling Bambu Studio from source. The stumbling block is simple: the Bambu network plugin does not exist for ARM CPUs. That means you can build a slicer, but you’re stuck sneaker-netting files with an SD card. I even tested if I could just push files with standard FTP on Raspbian - no luck, the plugin is mandatory.
Bottom line: unless Bambu decides to let one of their rabbits out of the walled garden, it isn’t happening. And given the mess they’ve made with Bambu Connect, they’re moving the opposite way. Don’t hold your breath.
Why would you want to run the slicer on a Pi? Its slicing performance is probably at best going to be pitiful. And 3D render previews in the slicer are going to be pretty slow for any reasonably complex model. A Pi’s GPU isn’t very good.
If it’s your only option, I guess it’s better than nothing. But it probably isn’t worth the effort for any other reason…
Not if he’s running Linux and using the linux version of BS. Even less so if he decided (and he should) to move to a RPI 5.
You’re right it would be slower than a Win or Mac machine, but it will run. For a RPI that’s all that some need to try. Hell I want to try it now, I have two 4’s and a 5 sitting around.
I suppose using Wine to emulate x86 to run windows version of bambu studio may work rather than having Linux binary to load that DLL directly. But I don’t know, just a thought.
I don’t think Wine does well with driver and DLL emulation. And you need a user mode emulator as well. Assuming you could get it to work, performance would be even more execrable.
Unless I misunderstood how the code is compiled, all slicing and previews are CPU-bound. I’ve monitored this on more than one system and saw zero GPU usage during slicing.
The idea that the Pi 5’s GPU isn’t strong enough to run Bambu Studio overlooks the bigger point: Bambu Studio - like Cura, PrusaSlicer, and Slic3r - doesn’t use the GPU for slicing. The heavy lifting is all CPU. The GPU would only matter for 3D preview rendering which the slicer as just stated, doesn’t make use of. Performance walls on a Pi 5 would come from CPU throughput, memory bandwidth, or missing plugins - not GPU horsepower.
For context, I only have a Pi 4, but even that should outperform low-end laptops. I sometimes run the slicer on a 2012 Surface Pro without much degradation compared to my desktop with a 12th-gen Intel CPU and RTX 3080 Ti.
When I first explored compiling the code, my original goal was to see if compiling could somehow produce CUDA code so I could tap into NVIDA GPU parallel processing. I dug into this pretty extensively over a couple of weekends, and both forum resources and AI tools agreed: to make that work, the slicing code would need a full University research-level rewrite for CUDA. In other words, there’s a lot of math and computer science involved. It’s not something you get just by recompiling existing sources. Apparently it’s nowhere near as simple as just flipping a switch.
At any rate, I abandoned the effort and will keep my fingers crossed hoping that someone will see this as a worthy effort. For me, it is beyond my skillset.
WINE is an elegant idea, but it has never delivered full Windows compatibility. Since the early 90s, I’ve tried it many times - Corel’s backing in the late 90s gave us Linux geeks hope, but that fizzled. Even today, it rarely matches native Windows performance or compatibility. It always seemed half-baked in my view, never quite finished and never lived up to its hype.
It reminds me of an old programmer’s joke:
Boss: Is the program done yet?
Programmer: No, but when it is, you’re gonna love it.
The last time I looked closely was in 2018 when Valve introduced Proton, a fork of WINE. I built a Steam box to test it, and it worked surprisingly well. But for Raspberry Pi, it doesn’t help - both WINE and Proton are translators, not emulators, and they only run x86 code. That’s the same roadblock for Bambu Studio because of the proprietary Bambu network libraries and now the reviled “Bambu Connect”.
This is a challenge I’ve wanted to tackle for a while, so if anyone here has real-world experience, as the Ferengi would say: I’m all ears.
Slicing has nothing to do with the GPU (although it could be used if someone wrote a slicer who used it). But the slicer provides 3D rendered representations of the model you’re slicing.
All the work you do in the slicer when setting up your slicing uses the GPU to display what’s going on. That performance will be terrible. Like, really slow and laggy when you try and rotate the view, for example.
Anyone who’s used an underpowered GPU with a program that wants more will know exactly what I’m talking about.
