RhinoCompute + AI = Linux

Rhino
1

Hello, I hope you are well!

I am currently developing utility commands using artificial intelligence. During my research, I’ve made several observations:

  • Microsoft is working with Ubuntu for Linux integration in Windows.
  • Some NVIDIA open-source projects provide precompiled libraries only for Linux.
  • Some official NVIDIA documentation explicitly recommends using Ubuntu.
  • NVIDIA Jetson boards (Nano, Xavier, Orin, Thor, etc.) run Linux as their OS, and DGX Spark also runs on Ubuntu.

It therefore seems that driver support for graphics cards is complete on Linux (at least for NVIDIA).

On your side:

  • you already have a cross-platform frontend with Eto,
  • Python and .NET are supported for scripting,
  • and RhinoCompute is clearly designed to run on servers.

So, is it conceivable that one day we might see Rhino on Linux?

Given my repeated frustrations with certain aspects of Windows, I would gladly switch my primary operating system to Linux. Right now, the only software keeping me tied to Windows is Rhino.

I imagine you’ve already discussed internally the idea of porting Rhino to Linux, but based on my findings I thought it was worth raising the point again. :slight_smile:

At the moment, I’m able to use AI to segment meshes or recognize simple surfaces (plane, sphere, cylinder, etc.). At the pace things are moving, it’s certain that in 3 to 5 years AI will enable us to do much more in 3D. We already see a multitude of AI services running on Linux servers powered by NVIDIA GPUs.

I sincerely believe that at the very least RhinoCompute should be able to run on Linux…

jmv

4

This is a long standing question:

Rhino on Linux? - Rhino / Rhino for Windows - McNeel Forum

Rhino on Wine (Linux) - Rhino - McNeel Forum (recent working example)

I’ve been able to get pretty decent support in the past for linux with wine and Rhino 5, but never without troubles or instability, and wine support broke with Rhino 6, and I gave up after that.

NVIDIA desktop drivers for linux are always problematic and a pain to get working reliably, and the diversity of distributions and combination of requirements is generally a pretty big hurdle to deploy this reliably.

RhinoCompute on linux would make a lot of sense, but I can imagine that it’s hard to prioritize this for McNeel.

But on the flip side, lots of work was done on porting the difficult parts (ETO, WinForms). Rhino was successfully ported to Mac, so it’s certainly possible, and bits and parts are cross platform and open source, including the awesome work by @nathanletwory on porting the blender render engine to Rhino.

5

We’re not planning on developing a desktop Rhino for Linux.

Everything else you said is well reasoned.

6

Thanks for your reply. I admit that my use of Linux is never in graphical/desktop mode.
Since NVIDIA is now releasing complete computers running Ubuntu, and I’ve read here and there that they recommend this OS, I was wondering if you’ve experienced the same issues with Ubuntu and the NVIDIA 50-series GPUs?

7

Compared to AMD, NVIDIA drivers are not open source, making it harder for distribution makers to include them by default. So the experience is a bit like the good old windows 95 days where you need to download the correct drivers, and then they’re working nicely with for example wayland or stuff like that.

Also, NVIDIA’s got some bad blood with a lot of the community for not really cooperating with making functional open source drivers.

This is mainly about desktop, and not server usage, where it’s already a bit less complicated, but still convoluted compared to AMD’s graphic cards.

8

Why not use macOS if you dislike Windows? It feels a lot more like Linux in terminal than Windows. And the M4 pipeline is really fast for graphics.

9

Hello Brian, Windows has been frustrating me lately. I often feel like it just does whatever it wants. As for Apple… well, let’s just say they don’t like to play well with others.

But this message isn’t really about me. there are always workarounds. For example, I bought an iPad Pro solely to use NomadSculpt (50$ for the app + 2000$ for the tablet). In the same way, I could buy a Windows PC or a Mac just to run RhinoCompute and place it next to my Linux server.

What interests me most in Rhino is its ability to open a wide range of formats (3dm, step, igs, stl, fbx, obj, etc.), perform simple 3D operations, and extract statistics (volume, number of parts, etc.). However, having to buy a second machine solely to run Rhino/Compute remains a burden, both in terms of infrastructure and cost. (But I think I’ll mainly invest in a solution that is compatible with Linux, there are alternatives to RhinoCompute)

My main intention here is simply to share an observation after exploring various codebases. We can clearly see the rise of web services based on AI, and we’re only at the beginning of their integration into businesses. Since the global server infrastructure is predominantly Linux-based, I thought this message might be relevant to you.

10

I don’t think you’ve been reading the threads calling for a Linux version with enough attention. It is not just about the operating system, but also about the companies behind the products - Microsoft and Apple are the same for many people who are calling for Linux.

Instead of buying another whole machine you can increase memory on your current machine to the max, get a second GPU and another big drive. Then set up a virtual machine with QEMU/KVM with PCI passthrough - you’ll have a Windows environment inside your Linux in which you can run Rhino on pretty much native speed. Just set up the network for the virtual machine correctly and you’ll have your compute. If you don’t need the GUI part then you can obviously skip the second GPU part.

11

Hello Nathan,

I actually tried the opposite approach, running Linux libraries inside WSL2. Even though Microsoft worked with Ubuntu for WSL2, I have a lot of issues with GPU access (and in any case, it would still require a Windows server once in production).

My only real Linux experience is with Raspberry Pi, so … but indeed, the QEMU option is worth considering.

12

To give some context:

My idea would be to analyze old client files, extract statistics (shape complexity, volumes, etc.), combine them with results data (modeling time, invoiced price), and train a model capable of estimating project complexity for non-technical people (such as sales teams). To do this, I would need a 3D manipulation library (Rhino remains my natural choice) and 3D volume inference tools (segmentation, simple surface recognition).

All of this is still experimental, and it’s very complex for a simple tool (I know :upside_down_face: ). But I believe AI will become as widespread as websites or smartphones, and if I don’t want to end up like a mechanic lost in the wake of automotive electronics, I must explore this.

For testing, I can use GPU cloud services. However, in production, our projects involve confidential data; therefore, an internal server is essential.

Linux is now the standard platform for server and cloud deployment, and RhinoCompute bills itself as a “REST geometry server.” The connection seems obvious…

I understand that fully porting RhinoCompute to Linux is not easy. But official support of QEMU / LXC(VM) could be a useful step.

13

btw, this and some other discussions I’ve had recently with some friends prompted me to look a bit deeper into how LLMs are trained at scale, since they obviously use of NVIDIA GPUs running on Linux on x86_64 systems and often on AMD CPUs. I always heard the compatibility with NVIDIA drivers and Linux is tricky, and several years ago with some students we had a really tough time doing this. But obviously there are compatible drivers, albeit probably on very specific hardware and software versions, because this is what is used to train LLMs at scale.

Rhino.Compute is a dotnet application that has been updated to run on dotnet core. It is a web server and does not depend on anything specifically available only on Windows. This is indeed easy. This is not where the issue is.

14

I would very much be interested in a linux version of Rhino, primarily for the functionality Grasshopper provides compared to other CAD programs. However due to not being able to use Rhino on linux, its forced me to use FreeCAD and I gotta say its rapidly improving and making me question keeping a windows pc around just for Rhino.

15

Would take years of testing to get Linux + Rhino working - unless the market demanded it, it would be uneconomic for McNeel to do so.

I’d rather see them spend the money and time on developing a full suite of AI+python tools and integrations into Rhino with windows.

That would be a game changer - i.e., Imagine a future where architects have round table discussions about a project - the meeting is actively being recorded - A Large-language model working away in the background transliterating and interpreting the conversation:

“RhinoAi” generating forms, plans, sections, reports etc.,. to present back to the architects for discussion and evaluation…..

16

Hi everyone!

A quick update after 4 months on this topic. All in all, even if AI sometimes just a gimmick, it has had the merit of making incredible geometric calculation libraries accessible. 3 years ago, segmentation or curvature analysis seemed complex to me; today, with the Python ecosystem, it’s documented and “plug-and-play”. That, for me, is the real revolution.

Anyway, I tested virtualization (Docker, WSL, Hyper-V). Honestly, for a workstation (even high-end), it’s too heavy. Either it requires 64GB+ of RAM, or disk performance is bad (WSL ↔ NTFS). Or the configuration and setup complexity is just too high. Result: I am forced to stay on native Windows.

The positive point is that after implementing several GPU tools, I realize we just need two things: a vertex array and a face array. In fact, it is so central that an interoperability protocol exists for this: DLPack (Welcome to DLPack’s documentation! — DLPack 0.6.0 documentation). It is incredibly handy: you just pass a pointer and you can use plenty of different libraries from different languages without any copy or conversion.

From what little I know, transferring millions of faces from the Rhino backend to Python or C# is extremely slow. My thinking leads me to propose considering an internal feature that would copy meshes directly into dedicated GPU memory and return a DLPack interface to the APIs (C++, Python, etc). This would allow developers to do mesh processing and play with all these crazy existing libraries!

I also note that Windows support is improving on the NVIDIA side and academic projects.

Sorry if this deviates from the original title, but DLPack would be a super relevant alternative and in the end, all that is needed is access to the vertex and face arrays.

(I really want to transform Grasshopper into a ComfyUI for 3D :sunny: )

jmv

17

Hello, sorry to bring this up again, but it’s possible it went unnoticed or I didn’t express myself clearly.

Normally, I would have mentioned Nathan, but I don’t know who else to contact besides you, @stevebaer, who also works with GPU/Direct3D.

We absolutely need an API to access the mesh buffer. On several occasions (and I don’t know all the cases), we’ve encountered problems as soon as we’ve had to manipulate the mesh data directly.

From what I remember, there were simple things like terrain deformation:

Complex calculations:

Real-time deformations:

And even optimizations of classic algorithms:

And probably many other cases I haven’t seen.

Each time, two solutions presented themselves:

– Copy the data and continuously update it on the Rhino side. This method often involved dealing with the slow data transmission between the Rhino and the C#/Python APIs.

– Avoid synchronization and use the OpenGL context to display the data directly in the window. This solution is fast, but the resulting objects are then completely invisible to all Rhino functionalities.

Therefore, a high-performance API for reading and modifying mesh data would be extremely useful.

18

Could you help me better understand by writing a few function declarations for what you want? I’m still a bit confused.

19

Hi @stevebaer ! Yes, I understand :slight_smile:

My suggestion is simply to move the heavy lifting—currently done via the C#/Python API—directly into your C++ code. Here is a quick idea of what the functions could look like:

// https://github.com/dmlc/dlpack/blob/main/include/dlpack/dlpack.h#L278
struct DLTensor;

class MeshReflectionGPU {
public:
    DLTensor* VertexTensor;
    DLTensor* FaceTensor;
};

class MeshReflectionCPU { /*...*/ };

class ON_Mesh;
void CopyGPUBuffers(ON_Mesh* mesh, MeshReflectionGPU* mesh_reflection);
void FreeGPUBuffers(ON_Mesh* mesh, MeshReflectionGPU* mesh_reflection);
void updateGPUBuffers(ON_Mesh* mesh, MeshReflectionGPU* mesh_reflection, bool rebuild = true);

I included DLPack descriptors; while not mandatory, they are very convenient for interoperability between libraries and languages. The main goal is to be able to perform a bulk copy of mesh data rapidly to a memory area (CPU or GPU).

As a reference, Blender faced the same performance bottleneck with their Python API. They solved it by implementing specific functions: foreach_set and foreach_get. Thanks to these, the API no longer iterates vertex-by-vertex, face-by-face, or UV-by-UV. Instead, a single function copies everything at once. The performance gain is massive.

These Blender functions are essentially synchronization functions. Since we cannot work directly on your internal raw mesh data, I am proposing an API to handle the copy (CopyCPUBuffers/CopyGPUBuffers) and update (updateGPUBuffers) much faster than iterating via Python/C#.

While extracting meshes from NURBS is possible, updating objects in place seems only relevant for Meshes (and perhaps SubD).

Concrete Example

The examples I mentioned earlier are use cases where this approach would be invaluable. In my current workflow, I am developing an application that performs topological analysis. All calculations are done on the GPU. Currently, this is a standalone app. If I try to integrate these functions into Rhino, I am forced to do a slow round-trip:

Rhino -> MyApp(RhinoAPI) -> Process(CUDA) -> MyApp(RhinoAPI) -> Rhino
         CPU              -> GPU          -> CPU

The goal is to achieve a pipeline like this:

Rhino -> MyApp(RhinoAPI) -> Process(CUDA) -> MyApp(RhinoAPI) -> Rhino
         GPU(copy)        -> GPU          -> GPU(update)

Alternative

There might be a simpler alternative: allowing the display of GPU arrays directly in the viewport. For instance, the DisplayConduit class could expose a method like:

draw_gpu_mesh(DLTensor* vertices, DLTensor* faces);

For context, my application uses exactly the same data arrays for both OpenGL rendering and CUDA calculations. This doesn’t use DLPack, but strictly CUDA/OpenGL Interops (ROCm also has HIP functions for this). It is extremely efficient and avoids having duplicate copies of the same arrays in each context (OpenGL and CUDA) requiring synchronization/copy at every frame.

In this scenario, the pipeline would be:

MyApp(RhinoAPI) -> lock / Process / unlock -> MyApp(RhinoAPI) -> Rhino
                -> GPU                     -> GPU(preview)
20

Ha ha! Someone just asked me if my previous message was the work of an AI… :upside_down_face:

21

Oh! A more illustrative example might be your GHGL component.

Rather than having a loop that copies the data (only if the input mesh is a reference to a Rhino object), you could also directly call its utility functions to copy the data within the OpenGL context:

22

Have you experimented with the MeshUnsafeLock class? This provides direct access to the mesh arrays.

https://developer.rhino3d.com/api/rhinocommon/rhino.geometry.meshunsafelock