Rhino.Compute on Linux is our existing Rhino.Compute project, now able to run on Linux servers. We are currently supporting Ubuntu Server 24.04 and AmazonLinux2023.
NOTE: This product is part of the Rhino WIP (work in progress) and as such should be considered WIP software. We do not recommend using this for production work.
Why is Rhino.Compute on Linux useful?
Rhino.Compute was first developed to run on Windows servers, because we knew how to make Rhino run on Windows. Truth be told, the majority of the world’s servers are not Windows servers. With Rhino.Compute on Linux we give developers the ability to run on server systems which are more readily available, more affordable, and more scalable than a Windows server.
@felix.brunold I’d like to get some hard numbers comparing startup times. Do you have any suggestions? I was trying Hyperfine on linux, but need some tool that would work on Windows as well.
Most of the project was developed on macOS running Linux in VMs and docker containers. I personally used Multipass to run Ubuntu 24.04.
@fraguada I ran some quick (admittedly unscientific) benchmarks out of curiosity, comparing startup times between the Rhino.Compute Docker image and the classic IIS server setup.
But I’m not so deep in the benchmarking, so I’m not really aware of what would be the best way to test this in a real meaningful way…
Comparison (5 runs, 4 children)
Proxy Ready (healthcheck)
Environment
Avg
Min
Max
Runs
Delta vs Native
Docker
1.68s
1.63s
1.71s
1.64s, 1.71s, 1.70s, 1.71s, 1.63s
+0.04s (+2.4%)
Native
1.64s
1.62s
1.64s
1.64s, 1.62s, 1.64s, 1.64s, 1.64s
—
First Child Ready
Environment
Avg
Min
Max
Runs
Delta vs Native
Docker
6.31s
5.91s
7.79s
5.91s, 5.99s, 5.95s, 5.92s, 7.79s
-5.75s (-47.7%)
Native
12.06s
12.03s
12.09s
12.04s, 12.03s, 12.06s, 12.09s, 12.09s
—
All 4 Children Ready
Environment
Avg
Min
Max
Runs
Delta vs Native
Docker
10.03s
9.18s
10.88s
9.83s, 9.18s, 9.77s, 10.50s, 10.88s
-21.23s (-67.9%)
Native
31.26s
30.73s
31.48s
30.73s, 31.32s, 31.36s, 31.48s, 31.41s
—
So I think the times themselves are not really usable (the number of plugins and stuff like this will affect it… Also the script plugins are not loaded in the docker), but they are interesting to compare.
Regarding the macOS setup, is there a possibility to test it locally without a core hour token? Or will that only work with core hour billing?
Really interesting news for our team! We are using Rhino.Compute heavily for one of our application, in this was quite a big discussion point going foreward with our developments.
@fraguada Will linux actually be capable of supporting all Rhino.Inside applications? Like for example the Rhino testing libary?
It should! Rhino.Compute uses the Rhino.Inside resolver, which we had to update to find Rhino on Linux. I used a few small dotnet apps with Rhino.Inside for testing on Linux throughout this development.
Maybe only slightly more plausible because we have the geometry core running on Linux. Getting a full user interface and new display in place is a much larger amount of work.
Makes sense, I wasn’t saying it’s probable either way, just a tiny amount more than before haha. But especially since Rhino uses direct3D now, wouldn’t the entire thing need to be rewritten for Linux regardless? (Unless you utilized some sort DXVK translation).
Amazing! I really hope this makes it through to production. Definitely going to play with this when I have some time. I have been putting off a compute server because that forces dealing with windows server.
My 2 cents: no need to push for a linux UI. Just break the dam, and the pressure of the water will flow where it needs to.
I’m super excited to see this! I’ve already been struggling to get a windows container running (start times are terrible), so I’m excited to have a better container option with Linux.
I’m not seeing a clear way to set the API key for accessing the container, or does this just run without one and that something for me to add?
I have successfully stood up a linux container. What I think I missed originally, but now know is that the API key for the computer server is the same as the Rhino license key used for core hour billing, which is different than setting up the “traditional” rhino compute server. Instead of just saying the Rhino-Token is the api key, I think it would be helpful to point out explicitly that this is different than the typical setup where the rhino-token and the api are set independent of each other.
@cameronbehning this is actually an error on my part in the documentation and in the environment file template we provide in the Rhino.Compute package. I will look to fix those. In the meantime, you can set RHINO_COMPUTE_KEY=<YOURSUPERSECRETKEY> in /etc/rhino-compute/environment and it will use that key.
Mainly for security reasons and handling confidential data. Going from Windows to Ubuntu is already a huge step in that sense, but a lot of industries (aerospace, defense, automotive, …) require it offline.
Core-hour billing is currently the only way to run Rhino on servers and Linux environments. At the moment we are not working on other ways to license Rhino on Linux systems.
NOTE: This product is part of the Rhino WIP (work in progress) and as such should be considered WIP software. We do not recommend using this for production work.