Rendering and synthetic data generation

Rendering turns a scene description into images or frames. Synthetic data generation is rendering, or simulation, done to produce training examples rather than pictures for people to look at: labelled images of objects that do not exist in any photograph yet, scenes with lighting and clutter varied on purpose, sequences with perfect ground truth because the generator knows where everything is. Both are heavy, both are batch, and both are workloads E31 Network is being designed to take.

What they share is a frame at a time. Each frame or sample is independent of the others, the set has a defined size, and no one is waiting on any particular frame. The whole set is one job.

Rendering as a batch job

A render job declares its work as the renderer and the scene: what is being drawn, at what settings, for how many frames or views. The data is the scene assets, staged for the job: geometry, materials, textures, animation, environment. The request is the compute and either a deadline or a duration. The output is the rendered frames.

Rendering is among the oldest batch workloads in computing, and it fits the network's shape with no translation. The job can wait in a queue with the meter stopped, run when compute is free, and return its frames when done. The team pays for the hours compute was held, and when the render finishes the compute is released. There is no render farm to own, and nothing sits idle between projects.

Synthetic data: rendering with a purpose

Synthetic data generation adds a layer of intent. The point is not the picture; it is the labelled example. A generator produces an image and, alongside it, the exact bounding boxes, segmentation masks, depth, or pose that a model should learn to predict. Variation is deliberate: lighting, viewpoint, background, object placement, and defects are sampled so the resulting dataset covers cases a real-world collection would miss.

As a network job, this is rendering plus a specification of what to vary and what to label. The work is the generator and its sampling configuration. The data is the asset library it draws from. The request is the compute and the size of the set. The output is a dataset: images and labels, in a form a training job can read. The design intent is that this output can become the input to a separate training job on the network, described on its own, though they are not linked automatically and the team moves the data between them as it sees fit.

When the output is the big part

Most network jobs take in a large dataset and return a small result. Rendering and synthetic data invert that. The input is a comparatively compact set of assets and a configuration; the output is a very large set of frames or examples. Returning the output to the submitter is therefore the step that carries the weight.

The program's published list of unsolved problems names getting large datasets to where the compute is. Rendering raises the mirror image: getting a large output back from where the compute was. The preview does not claim to have settled either direction. The design intent is that the job's output is declared up front, including its approximate size, so the return is planned rather than discovered. A team whose jobs produce large outputs would be helping the program work on exactly this, and /design-partners describes the kind of team it is looking for, though intake is not yet open.

From synthetic data to training

A synthetic dataset is rarely the end. It is the beginning of a training or fine-tuning run, often blended with real examples, and later the subject of an evaluation. On the network each of those is its own job with its own work, data, request, and output. The rendering job produces the dataset. A training job consumes it. An evaluation job tests the result. Each is paid for by the hour for the hours compute was held, and each releases its compute when done. No rates are published yet for any of them.

Nothing in this chain is real-time, which is what makes it a network chain. A renderer drawing a frame for a live display, or a simulator producing a view for an operator in the moment, must answer now and stays on local infrastructure. The network draws the frames nobody is waiting on yet. See Simulation sweeps as a batch job for the close cousin of this work, Training a model on rented compute for the next step, and /workloads for the full list.