Loomgine

Direction is where the work stops being a request and becomes a set of decisions. The model establishes the premise, the register, the running order and the visual argument — the things a human director settles before anyone touches a timeline. Nothing is rendered at this stage, and nothing is guessed at pixel level. The output is reasoning that the rest of the chain can act on and, just as importantly, that a person can disagree with.

Hands onPremise and registerBeat orderVisual argument

Planning turns the direction into a structure the engine can build against — a scene list with durations, roles and transitions, and an explicit account of what has to be true by the end of each scene. Because the plan is data rather than prose, it can be re-planned: change the running time and the beats redistribute, cut a scene and the continuity is recomputed instead of quietly breaking.

Hands onScene listDurations and pacingContinuity constraints

Every scene declares what it needs before anything is fetched or generated: footage, stills, audio, iconography, a chart, a mark. Supplied material is used where it exists; complementary assets are generated where it does not. Because the requirement is declared by the composition rather than by a prompt, an asset that turns out wrong can be replaced in place, without re-running the film.

Hands onResolved mediaGenerated assetsPer-scene manifest

This is the centre of Loomgine. A scene is not a picture the engine hopes came out right; it is a document of layers with explicit geometry, type, colour and stacking. Every property has a name and an address, which is what makes the rest possible: a model can change one heading without redrawing the frame, a person can open the same scene and move it by hand, and a diff between two versions is readable.

Hands onLayer treeTypography and layoutAddressable properties

Motion is authored, not hallucinated. Entrances, holds, exits, easing curves and transitions are attached to the same addressable properties the composition already exposes, which means motion can be reasoned about: a beat that runs long is retimed rather than regenerated, and a transition that fights the cut is replaced without disturbing the frame it sits between.

Hands onTimelinesEasing and transitionsRetimeable beats

Because the composition is data, it can be inspected before it is rendered. Text that overflows its box, contrast that will not survive the medium, a title that leaves the safe area, a scene that runs past its slot, a continuity break between beats — these are found by reading the document, at a fraction of the cost of finding them in a finished file. Failures are routed back for correction, so validation is part of authoring rather than a report at the end.

Hands onLegibility and contrast checksLayout and safe-area checksCorrections applied

Rendering is the last step and the least eventful one, which is the point. By this stage the piece is fully specified, so rasterisation has no creative latitude left: the same document produces the same frames at any resolution, on any run. Determinism is what makes a render reviewable, a regression detectable, and a change to one scene cheap to re-emit without touching the others.

Hands onFramesReproducible outputScale-independent masters