Using HOOPS AI from a Fully Local Desktop Application
I installed HOOPS AI, worked through the Jupyter notebook tutorials, then wrapped it as a REST API with FastAPI, and after that put an MCP server in front of it so an AI agent could drive it. This time I went in a different direction: no web server, no HTTP, no separate process to manage — just HOOPS AI called directly from a native desktop application written in C/C++.
It works. A single shared library that embeds CPython and exposes a C ABI is enough to run Manufacturing Feature Recognition (MFR), similar-part search, and other HOOPS AI features from native code. I also collected everything into a redistributable package, moved it to a machine with no HOOPS AI installation, and confirmed it runs there — on both Windows and Linux. In other words, this covers the whole path an ISV partner would take to ship HOOPS AI inside their own product and hand it to end users.
That is a similar-part search running through the bridge from a plain console client. It isn’t running on my development machine either: the client sits inside the redistributable package (
redist_package) on a machine where HOOPS AI was never installed. On startup the test client initializes HOOPS AI at runtime, and HOOPS AI prints its own version banner and validates the license ([OK] HOOPS AI License: Valid) — all of it inside the native process. The search itself then returns the same hits and similarity scores I get from the Jupyter notebook tutorial for the same query part.
Approach
There are broadly two ways to run HOOPS AI locally from a native app: compile the inference logic into a standalone EXE and talk to it over files or stdio, or embed a CPython interpreter directly inside a shared library and expose a C ABI. I went with the second. HOOPS AI already ships as a Nuitka-compiled, license-protected Python extension, and embedding it avoids paying the process-startup cost on every call. Since HOOPS AI itself supports both Windows and Linux, I set the project up so that one CMake build produces hoops_ai_bridge.dll on Windows and libhoops_ai_bridge.so on Linux from the same source.
The design decision that mattered most was keeping the HOOPS AI calls out of the application and putting them in a separate layer — hoops_ai_bridge — shipped as an include/lib/bin package, the same layout as HOOPS Exchange and the other HOOPS SDKs. A client app includes the header, links against lib at build time (on Windows), and ships the DLL or shared object from bin alongside its own binaries. The goal was that it shouldn’t feel like “the special component with Python and PyTorch inside” — it should feel like any other HOOPS SDK you have already integrated.
What I found
The C ABI hides Python completely
Three layers, top to bottom: the client application, the bridge, and HOOPS AI itself. The only thing between the app and the bridge is the C ABI; the only thing between the bridge and HOOPS AI is an import from the embedded CPython interpreter. All three live in the same process, so there is no server and no HTTP round trip anywhere in the picture.
From the client side, all that is visible is a set of plain C functions. Behind FastAPI or MCP, the Python side still shapes the interface you code against; here it doesn’t surface at all.
MFR, similar-part search, and more run natively
Today the bridge exposes MFR (per-face feature classification), shape similarity (cosine similarity between two parts), and similar-part search (a FAISS-backed index the client app can register parts into and query), all through the same interface. I plan to keep adding to it, so treat that as where things stand rather than a ceiling. One implementation note: MFR and the shape-embedding path share a single CAD-access object rather than constructing a new one per call, which keeps repeated calls from re-paying the setup cost. For each feature, I confirmed the bridge returns the same results as the notebook tutorials on the same CAD file.
License keys work the way they do in every other HOOPS SDK
The bridge’s C ABI holds no license key of its own. HoopsAI_Initialize takes one as a runtime parameter, and where that key comes from is entirely up to the calling application. So a client app can embed its license key into its own binary at build time, exactly as it would with any other HOOPS SDK. The test client here does that — the key sits in a header and is compiled in. Nothing has to be handed to the end user, and nobody has to set an environment variable on the target machine.
It runs on a machine with no HOOPS AI installed
What I wanted to prove wasn’t that this works on my development machine, but that it can actually be shipped. So I collected the built test client, the bridge DLL, and the libraries HOOPS AI needs out of site-packages into a single redistributable package and moved it to a machine with no HOOPS AI installation. With the package unpacked in a location that referenced neither the development venv nor the repository, every feature worked. That makes this the full path an ISV partner would follow to ship HOOPS AI inside their own product and deliver it to end users, not just a bridge plus a native app.
A tracing tool keeps the package from carrying what it doesn’t need
I did not want to pack libraries into the redistributable that nothing actually loads. Static package metadata is no help here: lean on it and you end up carrying dependencies like scikit-learn that only matter during training. HOOPS AI’s own “Distribute Your Application” documentation covers the HOOPS Exchange native libraries, but says nothing about HOOPS AI’s compiled extension, PyTorch, or trained checkpoints.
So the repository includes a tracing tool: it runs the features you actually use and diffs sys.modules to find out what genuinely got imported. Only those packages go into the redistributable, alongside the build output, the checkpoints, and a README. Add or change a feature and you re-run the trace.
One caveat: even after trimming, the package is not small. HOOPS Exchange and PyTorch are large to begin with, and for the same feature set the Linux package came out roughly twice the size of the Windows one. That’s not CUDA — both were measured with the CPU build of torch. The HOOPS Exchange native libraries are simply larger on Linux. Worth knowing before you estimate a download size.
Verdict
This approach holds up. Every feature the bridge exposes runs natively through a single embedded-CPython library, and redistribution has been verified on both Windows and Linux, on machines with no HOOPS AI installation. GPU inference is the open item — everything above ran on CPU.
The fiddly parts — build commands, environment gotchas, how to invoke the trace and packaging scripts — are all in the repository README rather than here. Clone it and you should be able to reproduce everything above.
A note on licensing and redistribution rights
Everything above is about what works technically. Shipping is a separate conversation. How you handle a license key, and what you are allowed to put into a redistributable, are different questions from whether either is technically possible. Whether HOOPS AI’s compiled extension or a trained checkpoint can go out to end users at all, and under what conditions, depends on the terms of the Technology Partner Agreement (TPA) between the partner and Tech Soft 3D, and varies by country and agreement. Please don’t take this post as the answer; check with your licensing contact. What I verified here is that it runs, not that it is permitted.
Source
The bridge library, the C++ test client I used to verify it, and the CMake build files are at toshi-bata/hoops_ai_native_bridge. As with any reference code shared here, treat it as a starting point rather than production-ready code — error handling is deliberately minimal.
What’s next
Next up is dropping this bridge into a native application built on HOOPS Visualize and HOOPS Exchange, so it can import a 3D CAD file and run MFR or similar-part search on it. The test client here is a console app, so results come back as numbers and labels; in a real application you can color faces by their MFR result, or show a search hit in 3D on the spot. That work is already underway, so it shouldn’t be long.
Questions, comments, or results of your own — happy to hear them in this thread.