Examples

Start from a dataset job that already has a shape.

These are files that exist in the repository, not configuration invented for a web page. Each one compiles to the low-level plugin contract and runs against an open Unreal editor. The workflow they are built for is: pick the task closest to yours, change the map, the target selectors and the zones, then validate before you spend an hour capturing.

Featured jobs: 5
Longest example: 1,000 frames
Selector kinds: 4

A Studio job is one YAML file. It names a map, a camera, where targets may be placed, and which actors count as which class. Two commands turn it into a labelled dataset: the first compiles the job to the contract the Unreal plugin reads, and the second runs it in an editor that is already open, verifies the result, and writes the report and the dataset beside it.

# compile the Studio job to the low-level plugin contract
nameframe studio-compile examples/studio_drone_person_detection_beach.yml _local/jobs/drone_person_detection_beach.json

# run it in an open editor, verify it, and write the report and the dataset
nameframe capture-unreal _local/jobs/drone_person_detection_beach.json --verify --report-out _local/reports/drone_person_detection_beach --dataset-out _local/datasets/drone_person_detection_beach --dataset-task box --dataset-val-frac 0.2 --dataset-test-frac 0.1

Those are the commands from examples/README.md, with the absolute output paths shortened so they read the same on any machine. Point the paths wherever you keep your runs. If you want to see what a job will do before it captures anything, studio-validate and studio-dry-run are the two commands worth knowing; the CLI, SDK, REST and MCP surfaces all reach the same pipeline.

Five jobs worth copying

Every value below was read out of the YAML. Where a file does not state something, there is no row for it.

Object detection, small aerial targets

Aerial person detection from a drone camera

examples/studio_drone_person_detection_beach.yml

People on a beach map, seen from 16 to 34 metres up, with COCO keypoints enabled on the one class. This is the closest starting point if your targets are people and your camera is above them, which is the case where boxes are small and a detector trained on ground-level data tends to fall over.

Frames: 500
Seed: 42
Resolution: 1280 x 960
Horizontal FOV: 57.3 deg
Camera altitude: 16-34 m
Orbit radius: 8-42 m
Look-at jitter: 0-8 m
Minimum fill ratio: 0.12
Depth: written
Map: /Game/BeachPack/Scenes/BeachDemo
Render profile: beach_sunny_drone
Class selector: prefix BP_RB_, keypoints coco

One circular camera zone and one spawn zone, both centred on the same point, plus a visibility rule that hides any BP_RB_ actor that was not selected as a target so an unlabelled person cannot appear in frame.

Object detection, multi-class vehicles

Two vehicle classes from a road corridor

examples/studio_vehicle_detection.yml

The longest job in the set, and the one with the most of a real configuration visible: a thousand frames at 1080p, cars and trucks selected by separate actor tags, and an environment block that moves the sun and the fog between frames instead of capturing the same lighting a thousand times.

Frames: 1000
Seed: 202
Resolution: 1920 x 1080
Horizontal FOV: 55 deg
Camera altitude: 8-40 m
Camera zone altitude: 20-60 m (road_drone_corridor)
Camera zone radius: 20-80 m
Orbit radius: 8-60 m
Minimum fill ratio: 0.04
Depth: written
Weather: daytime
Sun elevation: 18-65 deg
Sun azimuth: 0-360 deg
Fog density: 0.0-0.015
Exposure: fixed, bias -0.4
Spawn zone: road_vehicle_area, 0-60 m, labels car and truck
Spacing: 2.5 m minimum, 18 deg maximum slope
Class selectors: actor_tag DatasetCar and DatasetTruck, keypoints none

Both classes use actor tags rather than name prefixes, so the two vehicle classes can be separated without renaming a single asset. The camera declares 8-40 m while its one camera zone declares 20-60 m; both numbers are in the file, and if you copy it you should decide which of the two you actually want.

Object detection, single class

One arbitrary class, selected by a tag

examples/studio_generic_object_detection.yml

The minimum viable job. One class called object, every member of it found by a single actor tag, at a lower and closer camera than the aerial presets. Start here when the thing you want to detect is not a person or a vehicle and you would rather delete nothing than delete four classes you do not need.

Frames: 500
Seed: 101
Resolution: 1280 x 960
Horizontal FOV: 60 deg
Camera altitude: 4-18 m
Camera zone altitude: 6-22 m (user_camera_area)
Orbit radius: 3-24 m
Minimum fill ratio: 0.05
Depth: written
Weather: clear_sun
Sun elevation: 25-65 deg
Fog density: 0.0-0.01
Map: /Game/YourProject/Maps/YourMap (placeholder)
Class selector: actor_tag DatasetObjectCandidate, keypoints none

The map path is deliberately a placeholder, so this file cannot run until you point it at your own level. That is the intended first edit, along with the actor tag.

Object detection, mixed taxonomy

A mixed taxonomy, with pose on one class only

examples/studio_mixed_detection.yml

Person, car, food and animal in one job, each found a different way: a name prefix, an actor tag, a Blueprint class name and a full class path. Keypoints are switched on for person and left off for the other three, which is the point of the file.

Frames: 100
Seed: 42
Resolution: 1280 x 960
Horizontal FOV: 57.3 deg
Camera altitude: 10-28 m
Camera zone altitude: 16-34 m (beach_drone_lane)
Orbit radius: 4-24 m
Minimum fill ratio: 0.10
Depth: written
Weather: daytime
Sun elevation: 28-62 deg
Spawn zones: two: person/animal/food at 2-18 m, car at 4-30 m
person: prefix BP_RB_, keypoints coco
car: actor_tag DatasetTargetCar
food: class_name BP_FoodPlate_C, excluding tag DatasetIgnore
animal: class_path /Game/Animals/Dog/BP_Dog.BP_Dog_C

Pose is a per-class setting, not a per-job one. Only person carries keypoints: coco here; car, food and animal leave the field out, which compiles to keypoints none. The file also uses all four selector kinds at once, and a negative selector to keep tagged plates out of the food class.

Analysis only

Coverage targets, checked against a run that already exists

examples/analytics_coverage_targets.yml

Not a capture job. This file states what a balanced dataset would look like — how much of it should be close range, how much should be seen from the front, how much should be foggy — and nameframe metadata-coverage compares those targets with what an indexed run actually contains. It reports the gap. It never starts a generation.

Schema version: 1
Dimensions: 3
observations.camera_distance_m: 0-10 m 20%, 10-25 m 30%, 25-50 m 30%, 50 m+ 20%
observations.view_azimuth_deg: rear-left, front, rear-right, wrap-boundary, 25% each
frames.weather: clear 35, fog 20, overcast 25, rain 20
Starts a run: no

The percentages in each dimension sum to 100, which the command requires. Read it as the answer to a question capture alone cannot answer: not whether the labels are right, but whether the run covered the conditions you said mattered.

Two variations on the same jobs

Each is one of the above with a single thing changed, which is usually easier to read than a paragraph explaining the option.

The beach preset with rectangular zones
examples/studio_drone_person_detection_beach_rectzones.yml
The same people-from-a-drone job with its circular camera and spawn zones replaced by rotated rectangles, which is what you want when the area you care about is a road, a runway or a strip of beach rather than a disc.
The optional camera controls, all switched on at once
examples/studio_drone_camera_options.yml
A short job that exists to show what the camera block can do beyond width, height and FOV: drone mode, a per-frame random field of view, small orientation error, an explicit near clip, and per-frame intrinsics and extrinsics written out with the frames.

Advanced and engineering examples

The rest of the folder. These are fixtures: most run a single frame at 320x240 against a test map to prove one code path still works. They are listed because they exist, not because you should copy them.

studio_drone_person_detection_beach_smoke.ymlFive-frame smoke preset used to check that a run produces non-empty frames.
studio_spawn_distributions_testing.ymlAcceptance fixture for the native spawn distributions.
studio_poisson_spawn_testing.ymlAcceptance fixture for Poisson-disk placement.
studio_spatial_profiles_testing.ymlAcceptance fixture for Gaussian spatial profiles.
studio_anchor_constraints_testing.ymlAcceptance fixture for anchor selectors and inter-class distance constraints.
studio_nested_groups_testing.ymlAcceptance fixture for nested spawn groups and their final statistics.
studio_worker_acceptance_testing.ymlOpt-in worker acceptance run that spawns from an engine asset, not from tags.
studio_performance_benchmark_base.ymlThe base job the performance benchmark script varies. Five frames at 640x480.
studio_visual_showcase_concrete.ymlVisual acceptance fixture: four classes, four spawn pools, on a textured map.
studio_visual_showcase_concrete_uds.ymlThe same fixture with the sky and weather delegated to Ultra Dynamic Sky.

Where to go from one of these

The fastest useful change to any of these files is the class block. Swap the selector for one that matches your own actors, point scene.map at your level, move the camera and spawn zones onto the part of the map you care about, and leave the frame count low until a short run comes back clean.