UnrealCV's default branch is named 5.2, and the features not in its command list are not open source

The default branch is named after the engine version it targets

The repository's default branch is called `5.2`, which is a maintenance model stated by the tooling rather than in the prose. UnrealCV tracks Unreal Engine versions, and a branch per engine version is the only workable arrangement when a plugin has to compile against the engine's own headers and the engine's build system changes between releases.

The readme's newest feature entry says the plugin supports Unreal Engine 5.2 and later. So the branch name and the supported range agree, and the project is on the current line rather than pinned to a historical one.

The release history shows the project is being worked on now. A minor release on 2026-08-27, then two more on the following morning, 05:25 and 06:49, and the last push to the branch carries the same timestamp as the second of them. Whatever those two patch releases fixed, the project is not sitting still.

The licence is MIT, the repository is not archived, and the citation block points at a paper from 2017. That combination is the usual profile of research infrastructure: a long-lived open component with a short active life, maintained by whoever needs it rather than by a team with a roadmap.

Two parts, and only one of them installs with pip

UnrealCV is a client and a server, and the installation instructions treat them completely differently.

The server is the plugin. You download the source, place it in the plugin folder of a C++ Unreal project, and then launch that project from Visual Studio, at which point UnrealCV is compiled along with everything else. The readme is explicit that your Visual Studio version has to be compatible with your engine version, and it links to the engine's own setup documentation for the details. To check the installation worked you run a status command in the engine console.

The client is the Python package, and it installs with `pip install unrealcv`.

That asymmetry is the whole deployment story in miniature. The client is trivial. The server requires a C++ Unreal project, a matching Visual Studio, and a compile of the engine plugin, which is a far heavier thing than installing a Python library. A team that wants UnrealCV as a data generator is committing to the engine's toolchain whether they planned to or not.

The readme offers a third path, which is a pointer rather than a package: pre-built Unreal Engine binaries with UnrealCV already embedded exist in a separately hosted environment. Using one of those, the readme says, is as simple as running a game, with no knowledge of Unreal Engine required. That is the option that makes the project usable by people who are computer vision researchers rather than engine programmers.

The open source command contract is defined by a documentation page

One paragraph of the readme does more to shape what you can build on than any feature list, and it is about a second distribution channel.

There is a continuously developed feature surface, described as being tested in a separate supported environment before general-purpose capabilities are promoted into the open-source plugin. The paragraph then states the boundary explicitly: those features are available in the supported environments and are not part of the open source command contract unless they appear in the main command system documentation.

That is a clear and unusual statement of the terms, and it is more useful than a vague roadmap. It tells you there are two tiers. The documented command list is the interface you can build against, and anything outside it is something you would be testing against a hosted environment rather than against the repository you cloned.

The readme also frames the promotion mechanism: a capability becomes part of the open-source contract when it is judged general-purpose enough and appears in the command reference. So the contract grows by promotion, and the documentation page is the authority on what is in it today.

The practical consequence is a question worth asking before you commit: does the command you need appear in that reference? If it does, you can rely on it. If it does not, you are depending on a hosted environment, whatever else the readme says it is called.

A runtime MCP server is closed source, and its clients sit on a personal account

The readme links out for an agent integration, and the two sentences describing it contain a disclosure and an ownership detail.

The disclosure: the Unreal Engine C++ runtime MCP server is not currently open source. What is public, and linked, are the runtime MCP clients, the examples, and an agent skill, hosted in a separate repository. So the interface is documented and the tooling around it is readable, while the component that actually does the work inside the engine is not available to read, modify or build yourself.

The ownership detail: that public repository is under a personal account rather than the project organisation. So the agent-facing surface of this project lives in somebody's namespace, which is worth knowing before you build a workflow on it.

Neither fact is a reason to avoid the project. An agent skill and public clients are exactly what a closed server usually comes with, and the pattern is a deliberate one. But it does change the shape of the dependency: the open source part of this project is the plugin and the Python client, and the agent integration is a consumer of it rather than part of it.

It also means the readme is being explicit about a boundary that many projects would leave to a licence file. If you need to inspect what the agent is allowed to do to your engine, that code is not the one in this repository.

The repository holds a plugin, a Python client and a Python build runner

The tree is a mixed-language project that does not describe itself as one, and the directory names do the describing.

The engine side is conventional for an Unreal plugin: a plugin descriptor at the root, and a configuration directory, a content directory, a resources directory and a source directory beside it. Those four are the layout the engine's plugin loader expects, and they are why the tree looks unfamiliar if you have only worked on Python.

The Python side is a directory named `client`, and it is the part that people install. It has its own test configuration in a tox file at the root, and the documentation is configured for a hosted reference site through a read the docs configuration file, so the docs are built from this tree and published elsewhere.

The build is driven from Python too. There is a script named `build.py` and a task runner script whose name is the tool it configures, which is a sign that the C++ build is orchestrated as a task list rather than by an IDE. There are also `tools/`, `workflow/`, `test/` and `examples/` directories, and a directory marked as work in progress inside the examples.

So the build of a C++ engine plugin, the test of a Python client, and the publication of documentation are all reachable from one checkout, which is tidy, and the cost is that the repository has no single entry point you can read to understand it.

The examples target detectors from 2017

The examples directory is a small archive of what this project was for, and it is worth reading as a snapshot rather than as a tutorial set.

There is a file named after a fast region-based detector and a file named after a YOLO implementation. Both are the kind of two-stage and single-stage detector that dominated computer vision in the period when the project's paper was published, and both are wired to UnrealCV to generate or consume images. The rest of the directory follows the same pattern: a script that claims to do it in ten lines, a commands demonstration as both a script and a notebook, a data generation script, an interactive control example, a camera trajectory recorder, a stereo pair generation notebook, a model zoo directory, and a directory marked work in progress.

Two things follow. The first is that the intended workflow is closed loop: drive a camera in the simulated world, capture images and labels, train a detector, and point it back at the world. The trajectory recorder and the interactive control example are the parts of that loop on the simulation side.

The second is age. A detector example from 2017 is still a valid demonstration of the protocol, but it is not the set of models anyone is training now, and the readme's only forward reference is to a technical demo and a model zoo page. If you are starting fresh, the examples show you how the interface works and nothing about what to train.

Five hostnames, and the getting started guide lives on a project page

The readme points at four different domains for four different things, and a new user will follow them in the wrong order if nobody tells them.

The project site is one domain with a docs subdomain carrying the reference documentation, so the API lives under a different host from the front page. The getting started tutorial, which the readme tells you to read, is not on either of those: it is hosted on a project user page under the GitHub pages domain. The contact link is on that same user page. The badge at the top of the readme points at a chat room on a third service.

Then there is the separate supported environment, which has its own documentation subdomain, its own site and its own project page. So the count is more like five hostnames, and the distinction that matters most, the open source plugin versus the supported environment, is also the distinction that is hardest to see from a list of links.

None of this is unusual for a research project that grew a commercial-adjacent tier, and none of it is a defect. But if you are evaluating it, the practical instruction is to read the open source repository and the command reference first, and treat everything reachable from the other domains as documentation for something you have not yet decided to use.

Editorial conclusion

Use UnrealCV if your training data comes from a simulation and you want the simulator to be a real engine rather than a toy renderer, because that is what the plugin is for and what the two install paths assume. Three things to know before you start. That the command surface you can rely on is the one in the documented command system, since the readme says outright that the newer UnrealZoo surface is not part of the open source command contract unless it appears in that page. That the server is a C++ plugin you compile inside a C++ Unreal project, so your pipeline inherits the engine's toolchain requirements, a Visual Studio install matched to the engine version, and the cost of a full engine build. And that the runtime MCP server is closed source, so an agent-driven workflow is available to you as public clients and a skill rather than as something you can read or modify. The client side is unremarkable and pleasant: one pip install.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. unrealcv/unrealcv on GitHub