NameFrame is an Unreal Engine synthetic data generator for computer vision teams. Rare events, unsafe situations and controlled edge cases are hard to collect in the real world; NameFrame turns controlled 3D scenes into reproducible datasets with engine-derived ground truth.
How synthetic data generation works in Unreal Engine
Frame the world.Name the frames.
Bounding boxes · Instance masks · Depth in metres · Camera metadata
Commercial Preview · UE 5.8 verifiedApply for Private Pilot
Not because collecting data is hard in general. Because the specific frames that would fix a specific failure tend to be rare, unsafe, expensive to label, or impossible to reproduce twice.
Near misses, unusual viewpoints, extreme occlusion and uncommon failures are often the cases a model needs most, and the ones that appear least often in collected data. Waiting for them is not a plan, and staging them is sometimes dangerous.
The reference capture on this site averages 109 annotated instances per frame. Boxes take time; pixel masks take a great deal longer. And the labels themselves become another source of uncertainty, because two careful annotators will disagree about where a boundary goes.
Change the weather, the camera position or the object density outdoors and a dozen other variables move with them. An experiment you cannot hold still is an experiment you cannot repeat, and a result you cannot attribute.
A 3D world is different.
Unreal Engine already knows where every object is, which pixels belong to it, where the camera is standing and how the scene was generated. It has to: a renderer that did not know those things could not draw the frame at all.
In Unreal Engine, objects already have identities, transforms, geometry and camera relationships. NameFrame turns that scene knowledge into structured ground truth instead of asking a human to reconstruct it afterward.
The object already exists in the level, with a class, a transform and geometry.
NameFrame gives it a stable identity that survives weather, time and camera changes.
The engine writes an ID buffer, so the instance owns an exact set of pixels.
The box is measured from those pixels. Occluded instances shrink; hidden ones drop out.
Distance, class and instance id ship with the frame, not in a separate spreadsheet.
Traced through one real instance from frame 000004 of the Map_Airbase_Demo capture. Nothing on this list was typed in by hand.
Every object in the level is already a known thing with a known position. That is the raw material, and it exists before a single pixel is rendered.
A calibrated camera writes the image. Lens, sensor, exposure and weather are all part of the recipe, so the same recipe renders the same frame again.
Alongside the render, the engine writes a per-instance ID buffer. Two identical crates side by side are still two different instances, because the buffer says so.
Ask the same buffer a different question and it answers with classes. No second pass, no model, no guessing which pixel belongs to what.
Each box comes from the pixels the instance actually holds. An object half behind a hangar gets the smaller box it deserves, and one fully hidden is dropped.
Class, instance id, distance, camera, seed and the full configuration travel with the frame. When a label looks wrong you can go back and see exactly what produced it.
Change the camera, the population, the weather or the time of day, and the identities hold. That is the difference between a render and a dataset.
A capture recipe is a description of the conditions you want, not a recording of the conditions you got. Four things are yours to set.
Choose which objects appear, where they appear, how densely, and which of them belong together. Crowds around a vehicle, crates against a wall, workers where work happens.
Set distance, altitude and orientation, or hand over a zone and let it sample within it. Viewpoints that would produce nothing usable are rejected before they cost a render.
Move the sun, roll in weather, switch to night. The pixels change completely and the annotation identities do not move at all, which is the whole point.
Vary materials, animation state and pose from a seed, so a rerun of the same recipe produces the same variation rather than a new one.
Placing a hundred objects by hand gives you one scene. Describing how they should be distributed gives you every scene you were going to need after that.
Actors are placed across a region and settle on the surface they land on, so nothing floats and nothing sinks into the ground.
54 placements
Every capture writes these together. They are aligned by construction, because they come out of the same render rather than being reconciled afterwards.
RGBINSTANCE
DEPTH
BBOXInstance segmentation in Unreal Engine Metric depth maps from Unreal Engine How the bounding boxes are measured Camera metadata and intrinsics
A generated dataset is a claim about a world that never existed. The only thing that makes it worth training on is the evidence that it was produced the way it says it was, and that the labels match the pixels.
One master seed drives every placement decision. It is written into the capture and into each frame's own spawn manifest, so a frame can be traced back to the number that produced it.
The complete configuration is hashed and stored beside the frames. If the scene, the classes or the camera policy changed, the hash changes with them.
Gates run against the finished capture and have to pass before it becomes a dataset. A run that fails one stops there rather than exporting something that looks fine.
Labels are checked against the geometry that produced them: every blob is matched to the actor position it should have come from, and identity colours are checked for collisions.
Each frame keeps its own manifest, and the manifests are checked against the run index. What was asked for, what was placed and what was refused all stay on disk.
Verification recorded when this capture was labelled. Quoted as written.
One check did not pass on this run, and the report says so. Three of ninety visible people lost their box to a neighbouring instance’s colour. That is a 3.3% false-negative rate on the person class in this capture, and it is the kind of thing you only find by checking the pixels against the geometry.
A generation run is the expensive part. Everything that can go wrong in one can be found before it starts, so NameFrame puts three cheap steps in front of it instead of a single button that either works or wastes an afternoon.
The preview is a different, smaller run than the Map_Airbase_Demo capture the rest of this page uses. It reports its own seed, health grade and gate result on the same line as the frames, because a preview you cannot judge is only a picture.
Ten thousand frames of the same view from the same distance is one frame, repeated. These are the real distributions of the 40-frame airbase capture this page has been showing, computed from its own buffers and manifests.
Every annotated instance, measured from the camera position to the actor's own recorded position. The run's cameras sit in four authored zones, which is why the mass falls between 40 and 120 metres rather than spreading evenly.
The dataset publishes 4,378 annotations. The distributions above are computed from 4,402 measured instances. The difference is 24, and it is not an error in either.
They are two different questions asked of the same buffer, by two pieces of code with different rules. The scanner behind these charts counts every distinct identity colour covering at least 40 pixels. The labeller that produced the dataset applies its own thresholds: a minimum box side of 8 pixels, which 57 of the measured instances fall below, and a maximum aspect ratio of 6:1, which 2 exceed. It also reassembles fragmented objects, which the scanner does not.
Those rules do not add up to exactly 24 in either direction, and we are not going to pretend otherwise: reconciling the two pipelines exactly would mean running one of them twice. What matters for reading this page is which number describes what. Everything you download is the 4,378.
Only constraints this run actually declared appear here. A target nobody configured would be a number invented for a table.
| Constraint | Target | Actual | Gap |
|---|---|---|---|
| Minimum spacing between placements | ≥ 1.00 m | 1.00 m | met |
| Viewpoint retries per frame | ≤ 32 | 9 | met |
| Targets visible per accepted frame | ≥ 18 | 73 | met |
| Frames with no annotation | 0 | 0 | met |
The engine writes a raw dump and nothing else. Everything a trainer consumes is derived from that dump afterwards, which is why the same run can be re-exported into a different format without going back to the editor.
Map_Airbase_Demo · 40 frames · 1920×1080
| Split | Images | Labels | Masks |
|---|---|---|---|
| train | 31 | 31 | 31 |
| val | 9 | 9 | 9 |
| test | 0 | 0 | 0 |
Only the formats this build genuinely writes are listed. The test split is empty on this run because it was exported with a train and validation split only, and an empty split is shown as empty rather than quietly dropped.
Two samples from the capture used throughout this site, published in full: 15 packaged frames and 2,375 packaged annotations across the two archives, with the identity buffers the labels were derived from, the per-frame metadata, and this run’s own validation report including the check it failed.
A working detection and segmentation set: twelve frames spread across the run, with YOLO and COCO labels, the instance ID buffers they were derived from, and the metadata that says where every camera and object was.
sha256ac54025db5789bc58e62a54474b3c0ced5563a64c984baf01e155a7e71f17f94
Fewer frames, everything the engine wrote. Includes the raw float32 depth arrays in metres, which are too large to ship for a whole run but are the thing worth checking if you care about geometry.
sha256c52922f1ee9db49abd42e00b3ddc25f19dfea83bd4ac0ad01362267d90769f22
No sign-up, no email; the checksums above are what you should get. The two archives share 2 frames on purpose, so between them they cover 13 distinct frames of the run. There is a second capture too, from a different map and a much lower camera.
Every number on this page came from a run that happened. Each one is followed by what it does not cover, because a claim without its limits is not evidence, and you would find the limits yourself within a week anyway.
Collected from recorded evidence on 12 August 2026 at commit 995f0d3. The Unreal and validation figures come from visual-qa-ue58-2026-08-12; the soak figures from docs/STAGE_5G_MONITORED_50K_SOAK_2026-08-04.md. None of them are typed into this page.
The NameFrame Commercial Preview takes on a small number of teams at a time. If the data you need is dangerous, rare, or simply does not exist yet, that is the conversation we want to have.
