3D Printer Slicer Suggestions

I’m struggling a bit here. I use PrusaSlicer on the desktop, but the recent versions are dependant on OpenGL 3.2. PrusaSlicer will start on the RK3588, but complain about missing shaders. Starting with export LIBGL_ALWAYS_SOFTWARE=1 allows PrusaSlicer to run, but after a model is sliced, slows the software down to the point the model can no longer be interacted with. You can usually, at least, export the GCode.

I tried Orca slicer, and that failed to start. I wondered if others had success with slicers and had recommendations for reliable options on the RK3588.

1 Like

I have no experience with RK3588. You may try Bambu Studio, just for the slicer portion, as on my Pi4, the network plugin did not work at all. I guess might have something do to with ARM architecture. My other Intel system, running Debian 13, Bambu Studio work just fine.

I have the same problem.
For easy fast slicing stuff it works.. but yeah if you need to make more changes your doomed.

My current workaround is my old workstation which i use for heavy workloads. i start a screen sharing session and slice it there ^^v

1 Like

Orca currently has trouble under Wayland, it should be better next release. Try the Flatpak (it’s not on Flathub, you have to download from them directly) or try to run with:

__EGL_VENDOR_LIBRARY_FILENAMES=/usr/share/glvnd/egl_vendor.d/50_mesa.json WEBKIT_DISABLE_DMABUF_RENDERER=1 WEBKIT_FORCE_COMPOSITING_MODE=1 orca-slicer

Have not tried on the Pocket but this helps on a Wayland desktop system I use.

I was able to run orca in the mnt pocket, but I compiled from source and I am running via xwayland-satellite

I still have not tried any big jobs though, only small examples. And it did fine, but I am still on the “testing” phase.

The network plugin for a Bambu does not exist for aarch64. Orca downloads an .so but it is the default amd64 binary. So for now, in my case it’s a matter of slicing, exporting into an SD card and then printing.

2 Likes

I was able to get Prusa Slicer working again by forcing Mesa to a newer OpenGL version. Had to make a one line script with “MESA_GL_VERSION_OVERRIDE=4.1 MESA_GLSL_VERSION_OVERRIDE=410 flatpak run com.prusa3d.PrusaSlicer”

Then changed Exec= section of the desktop entry for prusa slicer in ~/.local/share/applications/com.prusa3d.PrusaSlicer.desktopto call script, so it could be launched from the GNOME menu.

1 Like

RK3588? Tried this and it unfortunately didn’t work for me, same error about dashed-lines as before. I was exploring trying to use Zink, but hit a roadblock there with mixed MESA versions with the Reform packages.

Oh you’re right it does not render the print. I think last time I used it, I was flying blind printing a model I was familiar with so it didn’t bother me.

OOC I did a very quick search in the codebase for dashed lines, looks like there are several options (compile time?) around dashed lines vs solid lines and different shaders that it can use PrusaSlicer/src/slic3r/GUI/Gizmos/GLGizmoPainterBase.cpp at 69c8e569410efe82259e706cd09a05ea82da9359 · prusa3d/PrusaSlicer · GitHub

Looks like you can set a build option to target OpenGL ES, I would say that has a good chance to work PrusaSlicer/CMakeLists.txt at 69c8e569410efe82259e706cd09a05ea82da9359 · prusa3d/PrusaSlicer · GitHub

I was just looking at that. Forcing software rendering works on the flatpak version. Change the script to LIBGL_ALWAYS_SOFTWARE=1 flatpak run com.prusa3d.PrusaSlicer

IDK why it won’t show the .desktop file if I put that directly into the Exec= line.

As I stated above, forcing software rendering will allow it to run, but causes it to slow down to an unusable state after a model is sliced.

The PrusaSlicet OpenGL 3.2 thread gives some indication of where to start with the CMake flags. I might give that a shot over the weekend and see how far I get.

I struggled to get this to build, however I have found that someone else has built ARM AppImages with OpenGL ES patches, and these appear to be working well.