YOLO wants a very specific thing: one text file per image, one line per object, class id and a normalised box, plus a data.yaml naming the classes. This guide goes from an Unreal scene to exactly that, and ends with a real dataset in that format you can download and train on.
A YOLO detection dataset is four things: image files, one label file per image with a matching name, a data.yaml mapping class ids to names, and a split into training and validation sets. Each line of a label file is a class id followed by centre x, centre y, width and height, all normalised to the image size.
Normalisation is where hand-built exports usually go wrong. The values are fractions of image width and height, not pixels, and the position is the centre of the box rather than its corner. Get either wrong and training runs perfectly while learning nothing.
# labels/train/dump__plugin_000004.txt
# class id, centre x, centre y, width, height — all normalised
5 0.63125000 0.82546296 0.06041667 0.08055556
3 0.57317708 0.83287037 0.04739583 0.06944444
4 0.66718750 0.92685185 0.02604167 0.04629630
4 0.69609375 0.91388889 0.05260417 0.10555556Those four lines are the start of a real exported file: a barrel, a container and two crates, all in the lower half of the frame, each occupying between two and six per cent of the frame width. The class ids come from the data.yaml that ships beside them.
# data.yaml
path: .
train: images/train
val: images/val
test: images/test
nc: 6
names:
0: person
1: car
2: tank
3: container
4: crate
5: barrelFour commands, assuming you already have a scene with classes and zones. If you do not, start with the generation guide.
The engine writes frames, the identity buffer, depth and metadata. No labels yet: labels are derived afterwards, which is what lets one capture become both a YOLO and a COCO dataset without re-rendering.
Boxes are computed from the identity buffer, so occlusion and truncation are handled by construction. Boxes below the minimum pixel size are dropped here rather than exported as unlearnable targets.
Pass --format yolo, or yolo,coco to get both from one capture, and --val-frac to set the validation share. The reference export split 31 train and 9 val images.
Grades the export and checks for the things that quietly ruin a run: corrupt images, duplicate frames, near-duplicates inside one split, and the same image appearing in both train and validation.
nameframe capture-unreal job.json --remote-url http://127.0.0.1:30010
nameframe label _out/dump _out/labels
nameframe dataset _out/dump _out/dataset --format yolo,coco --val-frac 0.2
nameframe validate _out/dataset --out _out/validationThis is the reference capture's, and it is not balanced. Yours will not be either, because scenes are not balanced. Knowing the ratio in advance is what lets you weight a loss or spawn more of something.
| Class | YOLO id | Boxes | Share |
|---|---|---|---|
| barrel | 5 | 1,471 | 33.6% |
| crate | 4 | 1,216 | 27.8% |
| person | 0 | 996 | 22.8% |
| container | 3 | 361 | 8.2% |
| car | 1 | 254 | 5.8% |
| tank | 2 | 80 | 1.8% |
Consecutive frames of one capture look almost identical. If frame 12 lands in train and frame 13 in validation, your validation score is fiction. The validator checks for near-duplicates across splits, and reported zero on the reference export.
A frame with no objects is a valid negative example, but a dataset that is mostly empty files is a broken capture. The gates count them and refuse a capture that is mostly nothing.
12 frames, 1,813 boxes, data.yaml included, plus the COCO version of the same labels and the report that graded them. Download it (49 MB).