Python is where research, analysis, and AI work happen, and it is where your C or C++ code has to show up to be useful there. We connect the two: native code of almost any kind, a rendering engine, a geospatial or vision library, a simulation core, a numerical or signal-processing library, exposed to Python cleanly enough that a scientist, an analyst, or an AI agent can drive it, and without paying for a copy on every call. None of this is limited to graphics. WrapStar and aipython work on any C or C++ codebase.
WrapStar: any C or C++, made properly Pythonic
We call our body of binding techniques and tooling WrapStar, sometimes written Wrap*. The star is the claim behind it: we can wrap effectively any C or C++ code cleanly for Python, up to and including libraries as demanding as OpenSceneGraph and VulkanSceneGraph, which run their own object and resource lifecycle management, and we do it without intrusively modifying the original codebase. The result feels like Python rather than a foreign object bolted on: real lists and dictionaries, stable object identity that holds up across repeated access, correct object lifetimes with no slow leak of accumulated wrappers, and plain Python functions standing in for native callbacks, all backed by code that still runs at full native speed. Objects pass cleanly in both directions, so anything created on the C++ side can be used from Python and the reverse.
Why not just point an AI at it
You can. Ask a coding assistant to wrap a large C++ library and it will produce something. What it produces is usually thousands of lines of boilerplate that cannot be safely removed once it exists, leaks objects because it never understood the library's ownership model, and does not feel like Python to the people who have to use it. A library that manages its own memory and lifecycle is full of sharp edges, and an unguided model walks straight into them. We are direct about this because it is exactly where the value is: wrapping hard C++ well is a craft, and WrapStar is how we do it reliably.
Into the AI and scientific stack, without the copies
Python is the language of AI and data science, so wrapped native code has to move data with the tools that world uses. We connect C and C++ to the scientific and machine-learning stack, NumPy, PyTorch, OpenCV, GDAL for geospatial data, and Jupyter, so arrays move between your code and Python with little or no copying. When the data lives on the GPU it can stay there: a native library and a compute kernel can share the same memory, so model tensors or simulation state can be consumed, processed, or visualized without a round trip through the CPU. That matters most when the data is large and the loop is hot, which is exactly where a careless binding quietly doubles your memory traffic.
Add Python to an existing C or C++ application
You do not have to rewrite anything to get this. We add Python to an existing C or C++ codebase incrementally, as a scripting and runtime layer on top of the code you already ship, so you can script, test, extend, and automate a large native application without an all-Python rewrite. It works in both directions: exposing your C++ to a Python process, or embedding a Python interpreter inside your C++ application. For a mature codebase, this is often the fastest and least risky path to modernization, because the existing code keeps running while Python grows around it.
Live sessions, and AI that can drive them
Once your code is in Python, it becomes something you can drive live. Bring a native application up under an interactive session and change it while it runs, adding or modifying objects, adjusting parameters, and seeing the effect immediately, instead of the edit, compile, and restart loop that C++ imposes. Background and asynchronous work is handled cleanly across the language boundary, with real progress reporting and orderly cancellation, so a long native task does not freeze the session driving it. The same wrapping that makes a library pleasant for a person also lets us teach an AI agent to use it correctly, so a model works with your code the way an experienced developer would instead of guessing at an unfamiliar API. That is what aipython is for: co-driving one live session with a human and an agent in the same interpreter.
What it makes possible
This is a complete Sketchfab-style 3D viewer: a deferred, physically based renderer with image-based lighting, real-time shadows, and a full post-processing chain, built entirely in Python. There is no C++ application underneath it wearing a thin Python veneer. The scene, the multi-pass render pipeline, and the shaders are all authored and driven from Python, interactively, using WrapStar, aipython, and our OpenSceneGraph Python tooling. It stands as one example of what the approach makes possible.
Where it connects
This work runs under the rest of what we do: computer vision, geospatial, and 3D graphics are the native engines most often on the other end of a binding, but the capability itself is general, any C or C++, reachable from Python and from a prompt.
Who works on it
AlphaPixel is a US-owned small business, founded in 2004, with senior C++ and Python developers who have bound native code to Python and shipped the tooling around it. DLA DD2345 / ITAR registered. We take closed-source work and open source alike.
Talk to us
Tell us what you’re building and where it’s stuck. We’ll tell you straight whether it’s something we can help with, and how we’d approach it.
Or see how we run consulting and software development engagements.
