NameFrame and UnrealCV
This is the least like-for-like pair on the site. UnrealCV is an interface: it lets a program outside the engine move the camera, move objects and ask for a view back. NameFrame is a pipeline that produces a dataset. You can build the second on top of the first, and people have.
- UnrealCV licence
- MIT
- UnrealCV engine
- 5.6 recommended
- NameFrame engine
- 5.8
- Verified
- 27 August 2026
An interface, and a pipeline
UnrealCV gives you commands. Ask for the lit view, the depth view, the object mask. Get the list of objects, set an object’s colour, move it, hide it. Your Python or your training loop is in charge, and the engine answers questions. That is a genuinely different and very flexible thing, and it is why it has been used in research for years: if you are running an agent in a loop, or building an environment that reacts to a model, this is the shape you want.
What it does not do is decide anything for you. Where the camera goes, how objects are distributed, whether a frame is worth keeping, what a bounding box is, whether the run is reproducible: all of that is code you write. That is not a criticism. It is the point of an interface.
NameFrame makes those decisions and lets you set them. Camera sampling under constraints, spawn and exclusion volumes, a seed that replays the whole run, boxes and masks measured from an identity pass, and a grade on the result before it is allowed to export. If your job is to produce a dataset rather than to run a loop, that is most of the work already done.
Side by side
| NameFrame | UnrealCV | |
|---|---|---|
| What it is for | Generating labelled computer-vision datasets end to end | Connecting external code to a running Unreal world |
| Unreal versions | 5.8, verified on 5.8 | 5.6 recommended, UE4 and UE5 lineage |
| Colour images | Yes | Yes, the lit viewmode |
| Depth | Metric, float32 metres per pixel | Yes, the depth viewmode |
| Semantic segmentation | Yes | By object colour, which you assign |
| Instance segmentation | Yes | Yes, the object_mask viewmode |
| Bounding boxes | Measured from the identity pass | Not documented |
| Occlusion-aware labels | Visible pixel share per instance, and a gate on it | Not documented |
| YOLO and COCO export | YOLO and COCO, plus the raw dump | Not documented |
| Built-in randomization | Spawn zones, exclusion zones, materials, animations, entity swapping | You write it, through the commands |
| Camera sampling | Sampled under constraints, with validation and retries | You drive it, through the commands |
| Deterministic runs | Seeded, and a run can be replayed | You implement it |
| Dataset validation | Graded and gated before export, with a published report | Not documented |
| CLI and automation | CLI, REST and MCP | The command protocol itself |
| In-editor interface | Studio panel in the editor | Commands rather than a panel |
| LiDAR and point clouds | Experimental raycast LiDAR | Not documented |
| Licence | Commercial preview | MIT |
| Maturity | New. Not on sale yet | Long established in research |
Last verified 27 August 2026, from UnrealCV on GitHub. Where their documentation does not answer a question, this page says so rather than counting it as a missing feature. If something here is out of date or wrong, tell us and it gets corrected.
Which one to reach for
Choose NameFrame if
- your output is a dataset, and you want it in YOLO or COCO without writing a converter
- you want boxes and occlusion measured for you rather than derived by your own code from a mask
- you want a run to be reproducible from a seed without implementing that yourself
- you want the scene to vary in controlled ways rather than scripting each variation
- you would rather set this up in a panel in the editor
Choose UnrealCV if
- you are doing reinforcement learning or anything where the model acts and the world responds
- you want your own code in charge of every decision
- you are on an engine version we do not support
- you want MIT-licensed source you can read, fork and cite
- you are continuing work that already builds on it
What this page is not
This is written by the people who make one of the tools on it, so read it that way. What we can do is keep it checkable: every row came from the other project’s own repository or documentation on the date at the top, the link is there, and a question their docs do not answer is written as not documented rather than as a missing feature.
We also have one end-to-end result and it is not flattering. A detector trained only on NameFrame frames, with no real images anywhere in training, improved on its synthetic test split and lost recall on real drone footage. It is published with the failure pictures on the experiment page. No comparison table on this site should be read as evidence that our output trains a better model, because we have not shown that.