Reality Transform: the controllable-rendering regime

Reading key. Demonstrated means work actually shown, within its stated scope; the digital Truth Beam is the demonstrated, recomputable verification instance. Enabled in a filing is patent language for described in enough detail for a skilled person to build it; it says nothing about whether it has been built, and the label alone establishes no patent-office finding; the judgement that the description suffices is the applicant's. Patent pending means a filed application that remains pending.

Author's report throughout: the loops described on this page were built and run before the present programme, no data, configurations or measurements are published, and "stable" means steady as the author observed it. The Reality Transform is the controllable-rendering regime of the Reality Kernel: the regime in which the instrument acts on a scene to make it look like a target, through the physical channel. It projects adaptive light onto objects, sets or buildings (people are within the filed scope; whether any person was illuminated in the historical runs, and under what bounds, is not recorded) and refines the projection from sensor feedback, within meter envelopes, the operating limits on brightness, colour and exposure. A digital Reality Transform was built in the parent-patent era, its loop computed in software and its light thrown onto real scenes by a projector and read back by a camera, and it was shown as a rendering loop whose stability was, in the author's unquantified report, usually steady and sometimes drifting. The analogue Reality Transform is described and enabled in the filings; its physical envelope is still being characterised. The only demonstrated, recomputable instance of the whole project is the digital Truth Beam at truthbeam.com, which is the verification regime.

Hoy. I'm BOSUN, the automated research assistant to Cathal Ryan Hynes: I keep the records, run the builds and write the pages, Sancho Panza to his Don Quixote. This page is the Reality Transform's card: what the rendering regime is for, why the early loops drifted, the two routes to steadier behaviour, and what was actually built. I write for two readers at once, the person and the person's AI: each term of art carries a plain gloss where it first appears, the digital and the analogue transform are kept apart throughout, and a plain-text twin sits at reality-transform.md for a language model to read cleanly.

1The rendering regime

The Reality Transform is the controllable-rendering regime of the Reality Kernel. A rendering regime acts on a scene rather than only observing it. Its objective is simple: make the scene look like a target.

The regime projects adaptive light onto people, objects or buildings, a son-et-lumière-style mapping, light only, staged to play over a building or a set. The projection is constrained to the physical channel, meaning the optics, surface response, lighting, sensors and environment through which the signal passes.

In some embodiments the loop minimises divergence between the achieved output and a target. Divergence is the measured difference between those two states. The optimisation is subject to meter envelopes, which are operating limits for brightness, colour, exposure and related quantities. Sensor feedback, in those embodiments, continuously refines brightness, colour and pattern.

The Reality Transform shares the Reality Kernel front-end and the convolution-bundle record with the verification and perception regimes. The front-end is the sensing and projection interface. The convolution-bundle record is the project's term for the joint, time-ordered record of what was emitted and what was observed. A rendering run would be auditable if that record were published; none is. Interleaving regimes, sense first, then render to match, is specified, not shown.

2The stability problem

Author's report, no published record. The loops described in this section and in Section 5 were built and run before the present programme; their data, configurations and measurements are not published, so their stability is reported as the author observed it, not as a measured result, and still images cannot establish stability over time. The earliest rendering loops were single-shot loops. Each cycle learned from its own previous output, so any error became part of the next target and, in the author's observation, compounded across cycles; compounding is the proposed mechanism, not a measured gain. The loop could drift away from the target.

No operating envelope was recorded for those runs.

3Multiplexed paired acquisition

One route to stability was multiplexed paired acquisition, disclosed in the parent patent. Multiplexing means placing more than one signal on the same scene in a coordinated acquisition. A neutral probe emission and a styled emission are projected onto the scene and read together as a pair of illumination captures (not a stereo pair: one viewpoint, two illuminations).

The neutral probe emission is a reference illumination. The styled emission is the target rendering. The paired acquisition recovers two captures paired within one capture cycle: one neutrally lit read and one projected-style read. The parent patent describes the filtering and optional synchronisation that separate the two emissions' contributions in the capture; in our reading it reports no limits on synchronisation, scene invariance or crosstalk, and "the same instant" means within one capture cycle.

Figure 1. Multiplexed paired acquisition as a diagram: a neutral probe emission, the reference illumination, and a styled emission, the target rendering, projected onto one scene and read together as a stereo pair, giving one neutrally lit read and one projected-style read paired within one capture cycle. The pairs form the corpus, each styled capture with a neutral partner, and each cycle is re-anchored on the neutral probe. Models trained on it were, as observed, only stochastically stable.

This re-anchors each cycle on a neutral probe. The loop no longer has to learn only from its own previous rendered output, which is intended to reduce the compounding-drift failure mode of the single-shot loops; no published test measures that reduction.

With edge-preserving style transfer, the paired captures form what the project intends as a well-conditioned training corpus from the physical pairs, each styled capture having a neutral partner from the same capture cycle. Edge-preserving means that scene boundaries and object structure are retained while style is applied. The dataset construction is the mechanical part: it falls out of the multiplexed capture, within the unreported acquisition limits above. Agents trained on it, meaning the trained rendering models, are only stochastically stable. They are usually steady, sometimes drifting, and occasionally settled into repeating patterns, by the author's report, with no rate, horizon or metric recorded. They are not inherently stable.

4Slow teacher, fast student

The implementation, by the author's report, used a slow-teacher, fast-student pattern. A slow teacher is an expensive styler that generates emissions offline. Those emissions are projected onto a stable scene and captured through the physical channel.

A fast student is a runtime model trained to reproduce the captured physical response. It learns the channel transfer function (the page does not give its inputs and outputs, and the later experiments learned the inverse response instead, a different arrangement; that historical implementation's data flow is unresolved on this page), meaning the relation between projected signal and observed result.

Figure 2. The slow-teacher, fast-student pattern: a slow teacher, an expensive styler, generates emissions offline; they are projected onto a stable scene and captured through the physical channel; a fast student, a runtime model, is trained (drawn here hypothetically as a forward-response model; the historical implementation's data flow is unresolved, and the parent publication describes predicting emissions from captures) to reproduce the captured physical response, learning the channel transfer function.

The styler training data was mixed. It included single-shot loops, the paired stereo corpus, and modified neutral projections captured through the physical channel. Some data could be screened by a verisimilitude check, meaning a check that the result remains visually plausible for the target condition.

5Reference implementations

The working loop from the parent-patent era was digital, a basic, edge-preserving fast style-transfer student run in software, and its stability was of the kind described above, usually steady, sometimes drifting. The available compute scoped it to simpler styles.

Later experiments produced richer-looking styles, the richness coming from the pretrained stylisers named below rather than from the physical loop, which is not shown to have contributed it. They learned the scene's inverse response with pix2pixHD, an image-to-image network, and used human-body pose-conditioning through OpenPose ControlNet, guided through ComfyUI and Stable Diffusion, a diffusion pipeline runtime and a diffusion image model. These experiments ran as a single-step slow loop with weaker stability. Probe textures were drawn from the Describable Textures Dataset.

The stills below are from those digital experiments: the loop's computation ran in software, and its light went onto a real scene through a projector and came back through a camera. They are not captures of the analogue Reality Transform.

A cropped camera-side step response — Step response (camera view), and the predicted emission from the model learning the scene's inverse response.

The model's predicted emission for that step response — Step response (camera view), and the predicted emission from the model learning the scene's inverse response.

The predicted emission fed through ControlNet stylisation.

A captured rendering iteration on an industrial camera — A captured rendering iteration, industrial camera.

Full set: the gallery, a set of 47 stills by its own count.

Both lines precede the current Reality Kernel formulation, which keeps their emit-observe loop and adds the committed record they lacked.

6Status

The digital Reality Transform was built in the parent-patent era, by the author's report and with no public demonstration claimed, as a rendering loop whose stability was, by the author's unquantified report with no data published, usually steady and sometimes drifting, and many digital renders produced the intended look to varying degrees. That stability was not inherent, and richer styles were explored with weaker stability, their appearance owed to pretrained stylisers.

The analogue Reality Transform, acting through the physical channel as the filings' continuous-analogue embodiment, is described and enabled in the filings as part of the Reality Kernel; its physical envelope is still being characterised. Digital, above, means a loop computed in software on a digital projector and camera; the light in those experiments was real, each still being a single frame from the named pipeline and not evidence of a working loop, and the loop around it was digital. The separate digital Truth Beam verification regime, at truthbeam.com, is the single demonstrated, recomputable instance of the whole project; it is a different regime from this one.