Skip to content
NAMEFRAMEApply for Pilot

Camera modes

Where the camera stands decides what a dataset teaches. A detector trained only from eye level fails from a drone; one trained from a ring of identical distances has never seen a close-up. NameFrame plans viewpoints as policy, orbit, grid, fixed or along a spline, and every frame records the pose that produced it, so the plan is reproducible rather than a set of lucky screenshots.

Modes
Orbit, drone, random, grid, fixed, spline
Aim
The subject, a random point near it, or free
Rigs
Several cameras, weighted, each with its own mode
Recorded
Full pose and intrinsics per frame

Orbit: rings around a subject

The workhorse. The camera samples positions on rings around a chosen subject, with distance and altitude drawn from ranges you set, aim jitter so the subject is not always dead centre, and a minimum fill ratio so it never shrinks to a speck. The drone and random modes are the same machinery under different policies: a drone flies higher and looks down, random frees the position entirely.

Every candidate viewpoint passes through the same validation gate: subject visible, not occluded past the threshold you set, camera not inside geometry, not under the landscape. A refused viewpoint is resampled rather than shipped, and the refusal is counted in the run manifest.

Grid: coverage you can prove

A grid camera plan covers an area rather than a subject: so many cells across, so many down, at a set spacing and height, with optional scatter inside each cell so the positions are not perfectly mechanical. Where orbit answers “what does this object look like from everywhere”, grid answers “what does this whole area look like from above”, which is the shape aerial survey and search datasets need.

Because the cells are enumerable, coverage is provable: the plan says which cell each frame came from, so you can show a client the area was covered rather than assert it.

Spline: a flown path

A Flight Path is a spline actor you draw in the level. The camera travels it, and the aim can track an actor re-resolved every frame, so a moving subject stays framed while the camera flies its own route. The tracking is deliberately imperfect: a delayed pan, a smoothed chase and optional airframe vibration, so footage reads as flown rather than computed.

This is the mode behind the video product and the moving-sensor LiDAR captures: a subject driving a track, the camera following, and every modality written per frame along the way.

A frame from a spline camera capture: an orange tractor in a sunflower field beside a barn, seen from a flown viewpoint above and behind
A spline camera following a tractor through a farmMap_BarnEnvironment, Unreal Engine 5.8Rendered frame from a real capture

Fixed: the surveillance shape

A list of authored poses, captured in order. This is the CCTV and gantry shape: the camera never moves, so everything that varies between frames is the scene, which is exactly what a model deployed on a fixed camera will experience. It is also the cheapest way to A/B a randomizer, because nothing else changes.

The modes compared

ModePositionBest for
OrbitRings around a subject, distance and altitude from rangesObject-centric detection sets: one class, every angle
DroneHigh orbit, steep look-downAerial detection, the view a UAV payload actually has
RandomFree positions inside the validation gateVariety without a policy
GridEnumerated cells over an area, set spacing and heightSurvey coverage, orthographic-style area datasets
FixedAuthored pose listCCTV, gantries, A/B tests of everything else
SplineA drawn flight path, aim tracking an actor per frameVideo datasets, chase footage, moving-sensor LiDAR

Rigs, and what gets recorded

A capture can carry several cameras at once, weighted so a dataset is, say, mostly drone with some ground level mixed in. Each camera in a rig keeps its own mode, aim and intrinsics; only grid stays a whole-plan mode, because a grid is a plan rather than a camera.

Whatever the mode, every frame writes the resolved camera: position, rotation, field of view and intrinsics, in camera_resolved.json beside the image. A viewpoint you cannot reproduce is a viewpoint you cannot debug, and the record is what turns “frame 41 looks wrong” into a pose you can stand a camera back on.