Rendered training data built in 3D instead of collected and labelled: for classes that are rare, expensive to photograph, or cannot leave the building.
A lot of data, quickly, with exact labels, at a lower price is close to impossible when every image has to be photographed and then annotated by hand. Rendering changes that arithmetic. We build the subject in 3D and generate images of it, which means the label is known before the image exists rather than added afterwards by a person looking at it.
It is not a replacement for real data and we will not pretend otherwise. It is the right tool for a class you cannot photograph enough of, a failure mode that happens twice a year, or a subject that cannot legally leave your building.
The first use case was a manufacturer who needed renderings of printed circuit boards. Because the products already existed as 3D models, we could generate high-quality computer-vision data within a week. It improved the performance of their quality-control detection system, and the same trained models turned out to be usable for returns management, which was not the reason the project started.
That is the shape of a good synthetic-data project: the geometry already exists somewhere in the business, and nobody had thought of it as a source of training data.
Six reasons, in roughly the order they decide projects. The first is the one people arrive with and rarely the one that matters most.
The 3D asset is the whole project. Everything downstream is cheap once it exists, which is why the first question is always what geometry you already have.
What 3D models, CAD files or scans already exist. Manufacturers usually have more than they expect, which is what makes this affordable.
Materials, lighting and the variation ranges that matter for your task, agreed before anything is rendered at volume.
A small batch trained on and evaluated against real data, to find out whether the gap between rendered and real is small enough for your model.
The full set, with labels emitted alongside the images rather than derived from them.
Deciding the ratio of generated to real data, which is usually where the accuracy actually comes from, and reporting what each contributed.
If your task depends on visual detail nobody has modelled, or on the exact noise of your own sensor, a pilot will show the gap and we will say so rather than sell you a larger render. Synthetic data that a model cannot transfer from is worse than a small real dataset, because it looks like progress.
Almost always, as the evaluation set at minimum. A model tested only on generated data tells you it learned the renderer. The useful question is not whether you need real data but how little of it you need, and a pilot answers that.
Whatever 3D geometry exists: CAD, product models, scans. If none exists it can be built, but that is a modelling project first and it changes the cost, so it is worth checking what your engineering team already has.
Exact, in the sense that they are generated from the scene rather than judged from the image. That removes label noise as a source of error, which is not the same as removing the domain gap between rendered and real.
For some tasks, and we will tell you when. For anything involving human judgement, language, or subjects that cannot be modelled, no. We sell both, so we have no reason to push you to the wrong one.
Most projects touch more than one of these. One partner across all of them means the labelling, the preparation and the application are not three vendors blaming each other.
Human-labelled training data across text, image, video, audio and 3D, and the feedback layer for language models: preference data, written demonstrations, rubric scoring, red-teaming.
Custom AI-driven applications, taken from concept through to deployment by the team that labelled the data.
The work before training: cleaning, structuring and checking datasets so a model has something honest to learn from.
