As I’m sorting out my Dual-boot Win 11/ Linux Mint machine, I came across this video on how to install Winboat. I realize it’s in Beta, but anyone have Rhino running on it? Seems like an option if it works.
Yep, I’ve got Rhino8 running successfully on WinBoat. Rendering takes a long time due to some issues, but for basic modelling it works quite well!
Having used it like this for a month of two, I’ve noticed that its a lot easier to use in the Desktop environment rather than the floating window due to W11 popups and some menus not working properly.
There are hints that the WinBoat devs are working on OpenGL support which should speed things up enormously, but its still in Beta so now we play the waiting game ![]()
It is a critical moment for the future of computer-aided design. While Rhino 3D remains one of the biggest industry standard for organic modeling and Grasshopper is the undisputed king of visual programming but the landscape of the “user ecosystem” is shifting rapidly and A.I. is disrupting this market quicker than ever before.
Here is why a Linux port has officially graduated from being a ‘fun experiment’ for enthusiasts to a full-blown survival strategy. Let’s face it: being tethered to a single ecosystem is starting to feel a bit too much like a bad relationship, it’s time for Rhino to spread its wings and join the open-source party!:
The Shift from Utility to Freedom
For decades, users accepted Windows as the “default” because that is where the tools lived. However, modern designers and architects are becoming increasingly tech-savvy and ethically conscious. They are no longer just looking for features; they are looking for **independence and control over their own workspace **.
As mainstream operating systems become more cluttered with forced telemetry, aggressive advertising, and restrictive updates, a growing segment of the creative community is looking toward Linux as a haven for performance and privacy.
Why McNeel Must Act Now
- Beyond a Mere Technicality: A Linux port is no longer just a supplementary feature or a niche request; it is a necessity for survival.
- Preventing the “Ditch” Factor: Creative professionals are notoriously loyal… until they feel trapped. If a designer decides to move their entire workflow to an open-source or cross-platform ecosystem, and Rhino is the only thing holding them back, they won’t stay on Windows; they will find a way to replace Rhino.
- Hardware Efficiency: Linux is famous for its light footprint. For heavy computational design in Grasshopper, having an OS that doesn’t “get in the way” of the CPU and RAM is a massive competitive advantage.
The Bottom Line
McNeel has always been a company “by designers, for designers.” To prevail in the next decade, Rhino must go where the people are going. Bringing Rhino and Grasshopper to Linux isn’t just about technical compatibility; it’s about respecting the user’s right to choose their own environment.
Let’s be honest: we absolutely, positively need a ‘native’ version of Rhino 3D on Linux… and we need it yesterday! Our computers are ready, our souls are willing, but our operating systems are still waiting for the invitation. Let’s make it happen, McNeel!
does the open nurbs initiative count? ![]()
well, that and maybe Master-sCAM
i believe Rhino can replace CAM’s too though. I honestly hesitating to joing linux… probably should draw a picture of me n’ my Rhino riding off into the sunset leaving windows behind and looking for linux
almost forgot my grasshopper ![]()
I was probably one of the first people to ask about linux support years and years ago. Yeah, I’d still like to see it. But, I just don’t see it happening. Lots of games are also Windows only and now Steam has worked hard to nearly eliminate that. You can run almost any Steam game on linux now. This is probably the way forward - a system like Proton that turns Windows calls into linux calls and patches over the details. Now, Rhino does phone home and I don’t know how well that plays with things like Proton and such but it seems like it must sort of work because people have gotten various versions of Rhino to work.
Yes, Windows is a complete mess these days and I don’t want to use it anymore for anything. MS took something that was at least tolerable and defecated all over it until it was such a bloated, spyware ridden, AI slop mess that no one wants it anymore. But, trying to port Rhino to linux at this point would likely be way too large of an undertaking. Granted, I thought that about MacOS as well but they did eventually get that going. Now, if only someone a decade ago had said something about great cross platform GUI systems like QT. QT6 is very nice these days and does very easily allow very easy cross platform support. Alas, this is not what Rhino is based upon. (Sorry, every few years it’s mandatory to bring that up)
QT should have hired me as a spokesman, I talk about it often enough.
A year and a half later I am trying this (Rhino7) on Linux Mint 22.3 using wine 11. Something changed, but still not quite there. This time the tooltips do show up, but they are behind the popup windows (and I use popup exclusively). There are also display refresh problems such that you draw something and its control points stay unless you click another viewport. You delete stuff and they stay unless you click another view. Also some mouse navigation doesn’t work.
Whether or not it happens officially, there are instructions you can follow to get a fully functional V7 using wine. I encourage you to try it, there are instructions up-thread!
My setup is a little more annoying, as I’m a freak who uses sway. But I’ve run it on the same computer using Gnome (GTK) and Plasma (qt) and it works amazingly - native performance, near native user experience. There are some annoying little UX things on sway, but there are no performance issues - it even uses my GPU.
I switched my system apps from (originally XFCE-based) Gnome-based to KDE-based because the look and feel was so much better with QT5 and QT6. So although I’m only a few months into being a QT stan, I understand your enthusiasm. No shade on Eto, it’s a great system. It’s a big BIG deal for a company like McNeel to switch frameworks, but if they did the .net Rhino calls is now cross platform, and QT is too. So eventually the lion’s share of the development would be identical, regardless the platform.
Now, that all said - I totally understand and respect that McNeel can’t devote resources to the effort. And we may have to stay on Rhino 7 on wine forever. But I do wish there was some way for some volunteer devs to sign an NDA and fork the source code and try to make it work natively on Linux. Even just a MVP or proof of concept so they could quantify more clearly what cross-platform development would look like, and what parts of the program would be an easy port and which would be more intractable. I would assume Nathan Letwory has already examined the issue and McNeel ruled it out as infeasible… but you never know what’ll happen in the future.
I tried using WSL to run Rhino with proton but the system bypassed that and executed in windows,
Once I get the time I will try to install a second boot on my laptop to test if it works.
Interesting results, I’m thinking about waiting
that’s WSL interop - a nifty feature of wsl, but can get in the way - if you want to disable it add/edit /etc/wsl.conf file in your wsl with this:
[interop]
enabled=false
appendWindowsPath=false
I just want to put out that Crossover 26 has been released, it might be worth for someone to try running Rhino 8/9 with it. There might be more success than before. (previous attempt with 25 finished the installation but I couldn’t get Rhino 8 to actually run)
Would McNeel consider launching a crowdfunding campaign with clear figures for what would be required to finance Linux development? It could gauge the community’s interest in a native Linux version and reduce financial risk.
I’ve been following this thread for some time and wanted to share my results with running Rhino in Linux. The tests were done on an older PC (i7-8700K CPU @ 3.70GHz, 32GB RAM, GTX 1080) running Ubuntu 24.04.
Compatibility layer approach:
Wine: does not install (I don’t know much about configuring wine)
Steam Proton: got it to install but does not run
Crossover 26: it installs, it does not run
Virtual machine approach:
Winboat: installs, runs but there’s no graphic acceleration, no anti-aliasing, struggles even on small projects
VMWare Workstation Pro (it appears to be free now, and has some special 3d drivers):
-Rhino 8: has problems with opengl, curves and edges don’t render, unusable
-Rhino WIP: works surprisingly well with Direct3D, even got it to load a 1.2GB pointcloud file. For small projects it’s fine, but other than that it seems to struggle.
My conclusion is, if you don’t have a second GPU for PCI passtrough, your best bet is VMware.
For me, the temporary solution is is to keep a beefy Windows machine for work, and use Sunshine/Moonlight + Tailscale to stream from my other Linux machines (home PC or laptop) when I need to get work done. With a good internet connection it works really well.
Hope this helps anyone interested, and I really hope that in the future we can, at least, get Rhino running trough something like wine, because VM performance, while usable, is still far from ideal. Cheers.
Best results I get is using Qemu/Virt-manager. How to install & use QEMU+KVM and virt-manager
My biggest issue is that on SteamDeck every SteamOS upgrade is deleting my configuration and I need to start from scratch (again). The performance is great without any notable drawbacks.
@Cumberland I will give it a try and post if performance is noticably better. Thx
@Cumberland no luck getting 3d acceleration in virt-manager. It looks like there is a problem with Nvidia proprietary drivers.
I am using this in a Steamdeck machine which do have a custom AMD APU.
I made a quick search for Nvidia cards:
Nvidia Driver 555, 560 Supports 3D Acceleration · Issue #695 · virt-manager/virt-manager
To enable NVIDIA 3D acceleration in virt-manager, use Virtio video with 3D acceleration checked, Spice with OpenGL enabled, and EGL-headless for renderer access. This uses VirGL to pass host NVIDIA GPU performance to the guest, requiring specific XML edits for best results.
VirGL runs with NVIDIA GPU - Tutorial 2024!!! (QEMU)
Steps for NVIDIA 3D Acceleration (VirGL):
-
Virtual Machine Config:
-
Video: Select
Virtio, check3D acceleration. -
Display Spice: Set Listen type to
None, checkOpenGL.
-
-
Required Fix for NVIDIA (EGL-headless):
-
NVIDIA often requires
egl-headlessto work with Virtio, as SPICE OpenGL can fail. -
Use
virsh edit <vm-name>to add<graphics type='egl-headless'/>. -
Ensure the render node is set to
/dev/dri/renderD128(or/dev/nvidia0).
-
-
Alternative / Performance Option:
- For maximum performance, consider GPU Passthrough (VFIO) instead of virtualized 3D acceleration, though this requires a second GPU.
This video demonstrates how to set up 3D acceleration without GPU passthrough: 3d Acceleration without GPU Passthrough with Virgl | Linux Guide
