# Changelog (/docs/changelog)



<Callout type="info">
  Placeholder entries — version numbers and dates are illustrative until the
  first public builds ship. Subscribe from your [dashboard](/dashboard) to
  get release notes by email.
</Callout>

## 2026.2.0 — upcoming [#202620--upcoming]

**Photon RTXPT**

* DLSS Ray Reconstruction preset ladder replaces the single denoiser toggle
* AOV layers: direct/indirect split output for external compositing
* Fix: accumulation reset flashing under time-sliced material exports

**Matter**

* `Deterministic` mode — bit-identical replays at \~15% cost
* Cloth self-collision robustness pass at high substep counts

**Aura**

* Input 4 normal-map support graduates from experimental
* Fix: temporal ghosting on hard cuts with `Reset History` pulse

## 2026.1.1 [#202611]

**All plugins**

* Signed headless license tool (`nops-license.exe`) ships in the plugin
  folder — see [Licensing a render farm](/docs/guides/render-farm-licensing)
* Status readout now reports the minimum driver version on refusal

**Photon OVRTX**

* Radiance cache probe refit no longer stalls on large geometry edits

## 2026.1.0 — first early-access builds [#202610--first-early-access-builds]

* Photon RTXPT, Photon OVRTX, Matter, and Aura enter early access
* Per-seat licensing with online and offline activation
* TouchDesigner 2023.12000+ / driver 560+ floors established


# Introduction (/docs)



<Callout type="info">
  These pages are placeholder content while the plugins are in early access —
  the structure is real, the numbers are not final. Join the
  [waitlist](/) to be notified when they ship.
</Callout>

## What is NativeOps? [#what-is-nativeops]

Every NativeOps plugin is a **native operator**: it registers itself with
TouchDesigner like a built-in, cooks on the GPU, and shows up in the OP Create
dialog next to everything else. No Python glue, no texture round-trips, no
external processes to babysit.

<Cards>
  <Card title="Native performance">
    Written in C++/CUDA against TouchDesigner's plugin API. Zero-copy texture
    sharing means frames never leave the GPU on their way through your network.
  </Card>

  <Card title="Licensed per seat">
    One license per machine, managed from your dashboard. Activation takes a
    key, not a hardware dongle — and moves with you when you swap workstations.
  </Card>
</Cards>

## The plugins [#the-plugins]

<Cards>
  <Card href="/docs/photon-rtxpt" title="Photon RTXPT">
    Real-time path tracing inside TouchDesigner, built on NVIDIA's RTX Path
    Tracing SDK.
  </Card>

  <Card href="/docs/photon-ovrtx" title="Photon OVRTX">
    The Photon front end on the ovrtx backend — the same scene semantics,
    tuned for interactive previz.
  </Card>

  <Card href="/docs/matter" title="Matter">
    GPU rigid bodies, fluids, and cloth as one operator suite — eight
    operators, one solver clock.
  </Card>

  <Card href="/docs/aura" title="Aura">
    Real-time 2D global illumination for layered scenes — emitters, occluders,
    and bounce in a single TOP.
  </Card>
</Cards>

## Quick start [#quick-start]

<Steps>
  <Step>
    ### Buy a license [#buy-a-license]

    Every plugin is sold per seat from the [products page](/products). The
    license key lands in your [dashboard](/dashboard) the moment checkout
    completes.
  </Step>

  <Step>
    ### Install the plugin [#install-the-plugin]

    Drop the plugin folder into TouchDesigner's plugin path and restart.
    [Installation](/docs/getting-started/installation) walks through both the
    per-user and system-wide paths.
  </Step>

  <Step>
    ### Activate your seat [#activate-your-seat]

    Paste your key into the operator's Activate parameter page — or activate
    offline for air-gapped machines.
    [Activation](/docs/getting-started/activation) covers both.
  </Step>
</Steps>

## Why native operators? [#why-native-operators]

<Accordions type="single">
  <Accordion title="Python operators are too slow for this">
    Script TOPs and CHOPs run on the CPU, once per cook, with the GIL in the
    way. A path tracer or a fluid solver needs thousands of GPU dispatches per
    frame — that only works as a compiled plugin sharing TouchDesigner's own
    GPU context.
  </Accordion>

  <Accordion title="Spout/NDI round-trips add latency and tear frames">
    Running a renderer in a separate process means every frame crosses process
    boundaries twice. A native operator cooks inside TouchDesigner's frame
    loop — the output TOP is the renderer's actual target texture.
  </Accordion>

  <Accordion title="External engines don't speak the network editor">
    Parameters, exports, CHOP references, time-slicing — the things that make
    TouchDesigner TouchDesigner — only reach operators. NativeOps plugins
    expose everything as ordinary parameters, so your existing control rigs
    just work.
  </Accordion>
</Accordions>

## Reading these docs as an agent [#reading-these-docs-as-an-agent]

Append `.md` to any page URL for its raw markdown. [/llms.txt](/llms.txt) is
the index, [/llms-full.txt](/llms-full.txt) is every page in one document, and
the **Copy page** button up top yields the same markdown.


# Overview (/docs/aura)



**Aura** lights 2D scenes the way a renderer lights 3D ones. Feed it layers —
who emits, who blocks — and it returns the scene with light that bounces,
bleeds, and wraps. Motion graphics stop looking flat without leaving TOPs.

<Callout type="info">
  Aura is the entry point to the NativeOps line: it runs on any CUDA-capable
  GPU from the 16-series up, no RT cores required.
</Callout>

## The idea [#the-idea]

A 2D scene has the same light problems as a 3D one — a neon sign should
tint the wall behind it; a character crossing a doorway should catch light
from it. Aura solves radiance in screen space over your layers:

* **Emitters** — any layer's bright pixels cast light, in nits
* **Occluders** — alpha or a dedicated mask blocks and shadows
* **Bounce** — one to four bounces of colored indirect light
* **Volumetrics** — optional fog pass so beams read in empty space

## Where it sits in a network [#where-it-sits-in-a-network]

```text title="Typical chain"
comp_layers (TOP) ──► aura1 (TOP) ──► bloom / grade ──► out
```

One Aura TOP per scene, after compositing and before grade — the same slot a
lighting pass occupies in a 3D pipeline. [Inputs](/docs/aura/inputs) covers
the layer contract.

## Next steps [#next-steps]

<Cards>
  <Card href="/docs/aura/inputs" title="Inputs">
    The layer contract — what each input plug expects.
  </Card>

  <Card href="/docs/aura/parameters" title="Parameter reference">
    Bounce counts, distance fields, quality ladders.
  </Card>
</Cards>


# Inputs (/docs/aura/inputs)



Aura takes up to four TOP inputs. Only the first is required — each one added
unlocks a feature tier.

| Input                 | Content                               | Unlocks                          |
| --------------------- | ------------------------------------- | -------------------------------- |
| 1 — Scene             | Your composited layers, premultiplied | Emission from bright pixels      |
| 2 — Occlusion         | Grayscale blocker mask                | Shadows independent of alpha     |
| 3 — Emission override | RGB emission map, in nits             | Emitters that aren't visible     |
| 4 — Normal            | 2D normal map                         | Directional response on surfaces |

## The one rule: premultiplied alpha [#the-one-rule-premultiplied-alpha]

Aura derives occlusion from input 1's alpha when no input 2 is wired.
Straight (unpremultiplied) sources read as glowing halos around every edge.

<Callout type="warn">
  If halos appear around composited elements, the source is straight alpha —
  drop a Premultiply TOP in front, or wire a real occlusion mask into
  input 2.
</Callout>

## Emission without visibility [#emission-without-visibility]

Input 3 answers the common request "light from off-screen": paint emitters
into the override map and they cast without being drawn.

```python title="Flicker an off-screen fire"
# noise TOP → level TOP (drives intensity) → input 3
op('aura1').par.emissionscale.expr = "1.0 + op('noise_fire')['chan1'] * 0.4"
```

<Callout type="idea">
  Normal maps (input 4) are the cheapest large upgrade: characters rendered
  from a 3D DCC with a normal AOV pick up directional 2D light that tracks
  their forms — the flat-sticker look disappears.
</Callout>


# Parameter reference (/docs/aura/parameters)



<Callout type="info">
  Generated reference, same pipeline as the other plugins. Placeholder
  subset below.
</Callout>

## Light page [#light-page]

<TypeTable
  type="{
  Bounces: {
    description: &#x22;Indirect bounce count. 1 covers most looks; 4 is the ceiling.&#x22;,
    type: &#x22;int&#x22;,
    default: &#x22;1&#x22;,
  },
  &#x22;Emission Scale&#x22;: {
    description: &#x22;Global multiplier on emitter brightness, in nits.&#x22;,
    type: &#x22;float&#x22;,
    default: &#x22;1.0&#x22;,
  },
  &#x22;Light Distance&#x22;: {
    description: &#x22;How far light travels, in pixels at full res. Drives the distance-field trace length.&#x22;,
    type: &#x22;float&#x22;,
    default: &#x22;512&#x22;,
  },
  &#x22;Color Bleed&#x22;: {
    description: &#x22;How strongly bounced light picks up surface color.&#x22;,
    type: &#x22;float&#x22;,
    default: &#x22;0.7&#x22;,
  },
  Volumetrics: {
    description: &#x22;Fog pass so beams read in empty space. Costs ~30% of the cook.&#x22;,
    type: &#x22;toggle&#x22;,
    default: &#x22;off&#x22;,
  },
}"
/>

## Quality page [#quality-page]

<TypeTable
  type="{
  &#x22;Quality Ladder&#x22;: {
    description: &#x22;Preview / Standard / Fine — trades ray count against cook time.&#x22;,
    type: &#x22;menu&#x22;,
    default: &#x22;Standard&#x22;,
  },
  &#x22;Temporal Blend&#x22;: {
    description: &#x22;Frames of history blended to stabilize noise. Raise for slow scenes, lower for cuts.&#x22;,
    type: &#x22;float&#x22;,
    default: &#x22;0.85&#x22;,
  },
  &#x22;Internal Resolution&#x22;: {
    description: &#x22;Lighting solve resolution relative to output. Half is invisible in motion.&#x22;,
    type: &#x22;menu&#x22;,
    default: &#x22;Half&#x22;,
  },
}"
/>

<Callout type="warn">
  `Temporal Blend` above 0.9 ghosts on hard cuts. Pulse the `Reset History`
  parameter from your cue system on every scene change — one line in a
  Script CHOP callback.
</Callout>


# Activation (/docs/getting-started/activation)



Activation binds a seat from your [dashboard](/dashboard) to the current
machine. Until then the operator runs in watermark mode — full function,
watermarked output.

## Online activation [#online-activation]

<Steps>
  <Step>
    ### Open the Activate page [#open-the-activate-page]

    Every NativeOps operator has an **Activate** parameter page. Select the
    operator and switch to it.
  </Step>

  <Step>
    ### Paste your key [#paste-your-key]

    Keys look like `NOP-1C285B2D-6CE6-4BC7-B8BE-ADB6A7E304DA` and are listed in the
    [dashboard](/dashboard). Pulse **Activate**.
  </Step>

  <Step>
    ### Confirm the status [#confirm-the-status]

    The `Status` readout flips to `Licensed` and the watermark disappears on
    the next cook. The seat now shows this machine's name in your dashboard.
  </Step>
</Steps>

<Callout type="info">
  Activation is once per machine, not per project — every `.toe` on the
  machine sees the seat.
</Callout>

## Offline activation [#offline-activation]

For machines that never touch the internet:

<Steps>
  <Step>
    Pulse **Request Offline File** on the Activate page. The operator writes a
    `machine.request` fingerprint file next to the project.
  </Step>

  <Step>
    On any online machine, upload the request in the
    [dashboard](/dashboard) under **Seats → Offline activation**. It returns a
    signed `seat.license` file.
  </Step>

  <Step>
    Copy `seat.license` into the plugin folder on the offline machine and
    restart TouchDesigner.
  </Step>
</Steps>

<Callout type="warn">
  The fingerprint covers the GPU and motherboard. Swapping either invalidates
  an offline seat — deactivate from the dashboard first if hardware work is
  planned.
</Callout>

## Deactivating [#deactivating]

Deactivate from the operator's Activate page (pulse **Deactivate**), or from
the [dashboard](/dashboard) when the machine is gone — dead SSD, returned
rental, stolen laptop. Dashboard deactivation is immediate and frees the seat
for the next machine.

Something stuck? [Troubleshooting → Activation
problems](/docs/troubleshooting/activation-problems) covers the failure modes
we know about.


# Installation (/docs/getting-started/installation)



Each plugin ships as a single folder containing the operator DLL and its
resource files. TouchDesigner discovers it on startup — there is no installer
and nothing touches the registry.

<Callout type="info">
  Downloads are signed and versioned per TouchDesigner build line. Grab the
  build matching your TouchDesigner version from the
  [dashboard](/dashboard) — a `2025.30000` plugin will refuse to load in a
  `2023.12000` session.
</Callout>

## Install locations [#install-locations]

<Tabs items="[&#x22;Per-user (recommended)&#x22;, &#x22;System-wide&#x22;, &#x22;Project-local&#x22;]">
  <Tab>
    Drop the plugin folder into your user plugin path. TouchDesigner scans it
    on every launch, and updates don't need admin rights.

    ```text title="Windows"
    %USERPROFILE%/Documents/Derivative/Plugins/PhotonRTXPT/
    ```
  </Tab>

  <Tab>
    For lab machines and render nodes where every user shares one install:

    ```text title="Windows (requires admin)"
    C:/Program Files/Derivative/TouchDesigner/Plugins/PhotonRTXPT/
    ```
  </Tab>

  <Tab>
    Ship the plugin inside a project folder for fully portable setups — the
    path is scanned relative to the `.toe` file:

    ```text title="Relative to your .toe"
    ./Plugins/PhotonRTXPT/
    ```

    <Callout type="warn">
      Project-local plugins still need an activated seat on the machine that
      opens the project. Bundling the DLL does not bundle the license.
    </Callout>
  </Tab>
</Tabs>

## What lands on disk [#what-lands-on-disk]

<Files>
  <Folder name="PhotonRTXPT">
    <File name="PhotonRTXPT.dll" />

    <File name="photon-rtxpt.sig" />

    <Folder name="shaders">
      <File name="pathtrace.ptx" />

      <File name="denoise.ptx" />
    </Folder>

    <Folder name="presets">
      <File name="studio.json" />

      <File name="exterior-sun.json" />
    </Folder>
  </Folder>
</Files>

## Verify the install [#verify-the-install]

<Steps>
  <Step>
    Restart TouchDesigner. Plugins are scanned once at startup — a running
    session will not pick up a new folder.
  </Step>

  <Step>
    Open the OP Create dialog (double-click the network background). The
    operator appears under the **Custom** tab — `Photon RTXPT` in this
    example.
  </Step>

  <Step>
    Drop the operator into a network. Until a seat is activated it cooks in
    watermark mode — full function, watermarked output. Continue to
    [Activation](/docs/getting-started/activation).
  </Step>
</Steps>

<Callout type="idea">
  Developing on a laptop and deploying to a media server? Install per-user on
  the laptop and system-wide on the server — the license seat follows the
  machine, not the install location.
</Callout>


# Licensing (/docs/getting-started/licensing)



A **seat** is one plugin activated on one machine. Licenses are sold per
plugin, per seat, with updates included for the duration of the license term.

## The model [#the-model]

* **Per machine, not per user.** Any user account on an activated machine can
  use the plugin. Two workstations need two seats.
* **Floating by deactivation.** Moving to a new machine is
  deactivate-then-activate from the [dashboard](/dashboard) — no support
  ticket required.
* **Watermark mode is not a trial clock.** An unactivated operator never
  expires; it cooks full-rate with a watermark. Evaluate as long as you like.

<Callout type="info">
  Render nodes cook headless with the same seat type — there is no separate
  render license. If a machine opens the `.toe`, it needs a seat.
</Callout>

## What a key looks like [#what-a-key-looks-like]

```text
NOP-XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
NOP-1C285B2D-6CE6-4BC7-B8BE-ADB6A7E304DA
```

The `NOP-` prefix, then a UUID — 32 hex characters, uppercase, in the
usual 8-4-4-4-12 grouping. Case and hyphens are part of the key.

Keys are plugin-scoped: a Photon RTXPT key will not activate Matter. Every key
you own is listed in the [dashboard](/dashboard) with its activation state and
the machine it's bound to.

## FAQ [#faq]

<Accordions type="single">
  <Accordion title="Can I use one seat on my desktop and laptop?">
    One seat is one machine at a time. Deactivate on the desktop, activate on
    the laptop — it takes about a minute in the dashboard. If you switch
    machines daily, a second seat is the honest answer.
  </Accordion>

  <Accordion title="What happens when my license term ends?">
    The operator keeps working at the last version released during your term.
    Renewing restores update access — nothing on your machine deactivates.
  </Accordion>

  <Accordion title="Do you support offline / air-gapped machines?">
    Yes — activation has an offline path built for media servers that never
    touch the internet. See
    [Activation → Offline](/docs/getting-started/activation#offline-activation).
  </Accordion>

  <Accordion title="Is there an educational discount?">
    Planned, not live. [Contact us](/contact) with your institution and we'll
    sort something out manually in the meantime.
  </Accordion>
</Accordions>


# Requirements (/docs/getting-started/requirements)



NativeOps plugins are native CUDA code sharing TouchDesigner's GPU. The
requirements below are hard floors, not recommendations — the operators check
them at load time and say so in the status parameter when one is missing.

## Supported platforms [#supported-platforms]

|               | Minimum         | Recommended          |
| ------------- | --------------- | -------------------- |
| TouchDesigner | 2023.12000      | 2025.30000+          |
| Windows       | Windows 10 21H2 | Windows 11           |
| NVIDIA driver | 560.xx          | Latest Studio driver |
| CUDA compute  | 7.5 (Turing)    | 8.9+ (Ada)           |
| VRAM          | 6 GB            | 12 GB+               |

<Callout type="warn">
  macOS is not supported. Every NativeOps plugin depends on CUDA — and Photon
  additionally on the RTX SDKs — which do not exist on Apple silicon. This is
  an NVIDIA-only product line by design.
</Callout>

## GPU generations [#gpu-generations]

The RTX requirement differs by plugin:

| Plugin       | Needs RT cores               | Runs on GTX      |
| ------------ | ---------------------------- | ---------------- |
| Photon RTXPT | Yes — RTX 20-series or newer | No               |
| Photon OVRTX | Yes — RTX 20-series or newer | No               |
| Matter       | No — any CUDA 7.5+ GPU       | Yes (16-series+) |
| Aura         | No — any CUDA 7.5+ GPU       | Yes (16-series+) |

<Callout type="info">
  Multi-GPU rigs: the operator cooks on whichever adapter TouchDesigner is
  running on. Affinity across GPUs is on the [roadmap](/roadmap), not in the
  current builds.
</Callout>

## Checking your machine [#checking-your-machine]

```python title="Textport"
# TouchDesigner build
print(app.build)

# GPU + driver as TouchDesigner sees them
print(project.paths)  # placeholder — see the Guides section
```

If the machine falls short, [Troubleshooting → GPU
requirements](/docs/troubleshooting/gpu-requirements) has the full
decision tree.


# Your first path-traced frame (/docs/guides/first-render)



This guide assumes an [installed](/docs/getting-started/installation) and
[activated](/docs/getting-started/activation) Photon RTXPT. Watermark mode
works too — everything renders, watermarked.

<Steps>
  <Step>
    ### Make some geometry [#make-some-geometry]

    A Grid SOP as the floor and a Torus SOP floating above it. Nothing
    fancy — this scene is about light, not modeling.
  </Step>

  <Step>
    ### Drop the renderer [#drop-the-renderer]

    Add a `Photon RTXPT` TOP from the OP Create dialog's **Custom** tab.
    Point its `Geometry` parameter at the container holding both SOPs:

    ```python title="Or from the Textport"
    op('photon_rtxpt1').par.geometry = '/project1/geo1'
    ```

    You already have an image — the default camera orbits the scene bounds
    and a default dome light fills it.
  </Step>

  <Step>
    ### Light it on purpose [#light-it-on-purpose]

    Add a `Photon Light` COMP, type **Area**, and set intensity to
    `10000` lumens. Kill the default dome by setting the renderer's
    `Default Dome` toggle off. One soft key from the left — already worth a
    screenshot.
  </Step>

  <Step>
    ### Give the floor a material [#give-the-floor-a-material]

    Add a `Photon Material` COMP, set `Roughness` to `0.15`, and bind it:

    ```python
    op('photon_mat1').par.bindpaths = '*/grid*'
    ```

    The torus keeps the default gray; the floor picks up a soft reflection
    of it.
  </Step>

  <Step>
    ### Let it converge [#let-it-converge]

    Stop moving the camera and watch the sample counter climb in the info
    overlay — the image resolves in a second or two. That's accumulation;
    it resets on any move and the denoiser hides the restart.
  </Step>
</Steps>

## Where to go from here [#where-to-go-from-here]

<Cards>
  <Card href="/docs/photon-rtxpt/materials" title="Materials">
    Glass and emission are two parameters away.
  </Card>

  <Card href="/docs/photon-rtxpt/lights" title="Lights">
    Swap the area for a sun + dome pairing.
  </Card>
</Cards>

<Callout type="idea">
  Drop a Movie File Out TOP after the renderer and you have path-traced
  playblasts — accumulation makes still-camera exports look like offline
  renders.
</Callout>


# Guides (/docs/guides)



Reference pages say what a parameter does; guides say what to do. Each one is
a complete path through a real task, with the wrong turns marked.

<Cards>
  <Card href="/docs/guides/first-render" title="Your first path-traced frame">
    Empty network to a denoised Photon RTXPT render in ten minutes.
  </Card>

  <Card href="/docs/guides/render-farm-licensing" title="Licensing a render farm">
    Seats on headless nodes — offline activation at rack scale.
  </Card>
</Cards>

<Callout type="info">
  More guides land with the plugins — coupling recipes for Matter, an Aura
  scene-lighting cookbook, and a DMX-to-Photon rig walkthrough are next in
  the queue. [Tell us](/contact) what you're stuck on.
</Callout>


# Licensing a render farm (/docs/guides/render-farm-licensing)



Render nodes are the worst-case licensing client: no browser, often no
internet, imaged from a common template. This guide runs the
[offline activation](/docs/getting-started/activation#offline-activation)
flow at rack scale.

<Callout type="warn">
  Do **not** bake an activated seat into a machine image. The license
  fingerprint covers GPU and motherboard — clones fail validation on first
  cook and show up in your dashboard as conflicting activations.
</Callout>

## The flow [#the-flow]

<Steps>
  <Step>
    ### Generate requests on every node [#generate-requests-on-every-node]

    Photon and Matter ship a headless license tool next to the DLL —
    scriptable over your farm's remote execution:

    ```powershell title="Per node, via your farm manager"
    & "C:\Program Files\Derivative\TouchDesigner\Plugins\PhotonRTXPT\nops-license.exe" `
      request --out \\filer\licenses\requests\$env:COMPUTERNAME.request
    ```
  </Step>

  <Step>
    ### Bulk-upload in the dashboard [#bulk-upload-in-the-dashboard]

    [Dashboard → Seats → Offline activation](/dashboard) accepts a zip of
    request files and returns a zip of `seat.license` files, one per node,
    named by machine.
  </Step>

  <Step>
    ### Distribute the license files [#distribute-the-license-files]

    ```powershell title="Back out over the same channel"
    Copy-Item "\\filer\licenses\issued\$env:COMPUTERNAME.license" `
      -Destination "C:\Program Files\Derivative\TouchDesigner\Plugins\PhotonRTXPT\seat.license"
    ```

    Nodes pick the file up on the next TouchDesigner launch — no reboot.
  </Step>

  <Step>
    ### Verify from the farm manager [#verify-from-the-farm-manager]

    The tool exits nonzero on an unlicensed node, so your farm's health
    check can gate dispatch:

    ```powershell
    & "...\nops-license.exe" status --quiet   # 0 = licensed
    ```
  </Step>
</Steps>

## Swapping hardware [#swapping-hardware]

GPU replacement invalidates that node's fingerprint. Deactivate the seat in
the dashboard *before* the swap and reissue afterwards — takes two minutes
and avoids the conflicting-activation flag.

<Callout type="info">
  Farm seats are ordinary seats — same price, same dashboard. If a node dies
  mid-season, dashboard-deactivate it and the seat is immediately free for
  the replacement.
</Callout>


# Coupling (/docs/matter/coupling)



**Coupling** is the suite's reason to exist: all body types integrate on the
same clock, so forces exchange *inside* a substep instead of one frame late.
A splash pushes the boat during the same step the boat displaces the water.

## What couples with what [#what-couples-with-what]

|           | Rigid              | Fluid                  | Cloth                     |
| --------- | ------------------ | ---------------------- | ------------------------- |
| **Rigid** | contacts, stacking | buoyancy, drag, splash | drape, collide            |
| **Fluid** | displacement       | —                      | soak weight, surface drag |
| **Cloth** | wraps, tears       | porous flow-through    | self-collision            |

## Enabling it [#enabling-it]

Coupling is on by default between bodies in the same solver. The switch that
matters is the pair mask:

```python title="Turn off fluid→cloth for a cheap win"
solver = op('matter_solver1')
solver.par.couplefluidcloth = False   # banner ignores the rain
```

<Callout type="idea">
  Pair masks are the first performance lever. A courtyard scene where rain
  never believably moves the flags can drop fluid→cloth and win the substep
  back.
</Callout>

## Walkthrough: boat on water [#walkthrough-boat-on-water]

<Steps>
  <Step>
    Drop a `Matter Solver`, a `Matter Fluid` fed by a tank-shaped SOP, and a
    `Matter Rigid` pointed at the boat mesh with `Collision Shape:
        auto-convex`.
  </Step>

  <Step>
    Set boat `Density` below the fluid's rest density — 400 kg/m³ floats
    convincingly against water's 1000.
  </Step>

  <Step>
    Read the boat transform out of `Matter Out` into a Geometry COMP
    instance. The camera never knows the hull is a proxy.
  </Step>
</Steps>

<Callout type="warn">
  Coupled systems share the substep budget — a fluid at 2 substeps forces
  the rigids it touches down to 2 as well. If stacking gets soft the moment
  fluid enters the scene, raise the solver's substeps, not the rigid's
  stiffness.
</Callout>


# Overview (/docs/matter)



**Matter** is a simulation suite, not a collection of solvers. Rigid bodies,
fluids, cloth, and constraints all step on one clock inside one CUDA context —
which is what lets a fluid push a box that tears a cloth, in real time,
without a frame of latency between them.

<Callout type="info">
  Matter runs on any CUDA 7.5+ GPU — RT cores not required. A GTX 16-series
  laptop runs the small examples; see
  [Requirements](/docs/getting-started/requirements).
</Callout>

## The suite [#the-suite]

<Cards>
  <Card href="/docs/matter/operators" title="Eight operators">
    One solver, three body types, two force fields, an emitter, and a
    readback CHOP — the whole surface.
  </Card>

  <Card href="/docs/matter/coupling" title="Two-way coupling">
    Solvers exchange impulses inside a substep, not across frames — the
    feature the suite is built around.
  </Card>
</Cards>

## Design rules [#design-rules]

* **Determinism switch.** `Deterministic` on the solver trades \~15% speed for
  bit-identical replays — same inputs, same frames, every run.
* **SOPs in, SOPs/TOPs out.** Colliders and emitters are plain geometry;
  results come back as point clouds, meshes, or velocity fields.
* **Budgeted stepping.** Like Photon OVRTX, the solver takes a millisecond
  budget and reduces substeps before it ever stalls your frame.

## FAQ [#faq]

<Accordions type="single">
  <Accordion title="Is this a Bullet/PhysX wrapper?">
    No — Matter's solvers are written for the GPU-resident, two-way-coupled
    case. A wrapper around a CPU engine can't share substep impulses with a
    GPU fluid without copying state across the bus every step.
  </Accordion>

  <Accordion title="How many bodies / particles are realistic?">
    Placeholder targets on a 4080: \~20k active rigid bodies, \~2M fluid
    particles, or \~500k cloth vertices — budget-shared when mixed. Real
    numbers land with the benchmark project.
  </Accordion>

  <Accordion title="Can I bake a sim to disk?">
    The readback CHOP/SOP pair feeds TouchDesigner's native caching (Cache
    SOP, File Out). A dedicated bake operator is on the
    [roadmap](/roadmap).
  </Accordion>
</Accordions>


# Operators (/docs/matter/operators)



Eight operators, one pattern: the **solver** owns time, everything else
declares state or reads it back.

| Operator            | Family | Role                                        |
| ------------------- | ------ | ------------------------------------------- |
| `Matter Solver`     | COMP   | The clock — owns substeps, gravity, budget  |
| `Matter Rigid`      | COMP   | Rigid body set from SOP instances           |
| `Matter Fluid`      | COMP   | SPH fluid volume                            |
| `Matter Cloth`      | COMP   | Cloth / soft shell from a mesh              |
| `Matter Constraint` | COMP   | Joints, motors, pins between bodies         |
| `Matter Force`      | COMP   | Field forces — wind, vortex, attractors     |
| `Matter Emitter`    | COMP   | Streams new particles / bodies at rate      |
| `Matter Out`        | CHOP   | Readback — transforms, velocities, contacts |

## Network shape [#network-shape]

```text title="Typical wiring"
matter_solver1
 ├─ matter_rigid_crates     (SOP: crate instances)
 ├─ matter_fluid_tank       (SOP: emission volume)
 ├─ matter_cloth_banner     (SOP: banner mesh)
 ├─ matter_force_wind
 └─ matter_out1             (CHOP → instancing network)
```

Bodies register with the solver whose path their `Solver` parameter names —
parenting in the network editor is for humans, the path is what binds.

<Callout type="info">
  One solver per interacting system. Two solvers never exchange forces — use
  that deliberately to isolate a background sim from a hero sim at different
  budgets.
</Callout>

## Reading results [#reading-results]

```python title="Contacts drive audio"
contacts = op('matter_out1')['contact_impulse']
if contacts.eval() > 4.0:
    op('audio_hit').par.play.pulse()
```

<Callout type="idea">
  `Matter Out` exposes contacts as CHOP events with impulse magnitude —
  collision-driven sound and lighting cost one export, no Python per frame.
</Callout>


# Parameter reference (/docs/matter/parameters)



<Callout type="info">
  Generated reference (same pipeline as Photon's) — Matter is the reason it
  exists: eight operators, \~160 parameters, derived from USD Physics schemas.
  Placeholder subset below.
</Callout>

## Matter Solver — Sim page [#matter-solver--sim-page]

<TypeTable
  type="{
  &#x22;Substeps&#x22;: {
    description: &#x22;Physics steps per frame. Stacking stability wants 4+; fluids often fine at 2.&#x22;,
    type: &#x22;int&#x22;,
    default: &#x22;4&#x22;,
  },
  &#x22;Budget (ms)&#x22;: {
    description: &#x22;Per-frame time cap. The solver sheds substeps before it stalls the frame.&#x22;,
    type: &#x22;float&#x22;,
    default: &#x22;6.0&#x22;,
  },
  Gravity: {
    description: &#x22;World gravity vector, m/s².&#x22;,
    type: &#x22;xyz&#x22;,
    default: &#x22;0, -9.81, 0&#x22;,
  },
  Deterministic: {
    description: &#x22;Bit-identical replays for ~15% speed. Fixed seed, ordered reductions.&#x22;,
    type: &#x22;toggle&#x22;,
    default: &#x22;off&#x22;,
  },
  &#x22;Scene Scale&#x22;: {
    description: &#x22;Units-per-meter. Wrong scale is the #1 cause of floaty-looking sims.&#x22;,
    type: &#x22;float&#x22;,
    default: &#x22;1.0&#x22;,
  },
}"
/>

## Matter Rigid — Body page [#matter-rigid--body-page]

<TypeTable
  type="{
  Density: {
    description: &#x22;kg/m³ — mass derives from collision volume. Override with Mass when art-directing.&#x22;,
    type: &#x22;float&#x22;,
    default: &#x22;1000&#x22;,
  },
  Friction: {
    description: &#x22;Coulomb friction against other bodies.&#x22;,
    type: &#x22;float&#x22;,
    default: &#x22;0.5&#x22;,
  },
  Restitution: {
    description: &#x22;Bounciness. Above 0.9 with high substeps gets lively.&#x22;,
    type: &#x22;float&#x22;,
    default: &#x22;0.1&#x22;,
  },
  &#x22;Collision Shape&#x22;: {
    description: &#x22;Auto-convex, box/sphere/capsule fit, or exact mesh (static only).&#x22;,
    type: &#x22;menu&#x22;,
    default: &#x22;auto-convex&#x22;,
  },
}"
/>

## Full table [#full-table]

<Accordions type="single">
  <Accordion title="All eight operators (placeholder dump)">
    | Operator   | Page     | Parameters                                      |
    | ---------- | -------- | ----------------------------------------------- |
    | Solver     | Sim      | substeps, budget, gravity, deterministic, scale |
    | Solver     | Advanced | broadphase, sleep threshold, CFL target         |
    | Rigid      | Body     | density, friction, restitution, shape           |
    | Fluid      | Volume   | rest density, viscosity, surface tension        |
    | Cloth      | Shell    | stretch, bend, thickness, self-collide          |
    | Constraint | Joint    | type, limits, motor target, stiffness           |
    | Force      | Field    | type, strength, falloff, noise                  |
    | Emitter    | Rate     | rate, speed, lifetime, inherit velocity         |
    | Out        | Channels | transforms, velocities, contacts, ids           |
  </Accordion>
</Accordions>


# Overview (/docs/photon-ovrtx)



**Photon OVRTX** is the second Photon renderer. Same operators, same
materials, same lights — a different engine underneath. Where
[RTXPT](/docs/photon-rtxpt) converges to a reference-grade frame, OVRTX
holds a stable interactive image under constant scene churn.

<Callout type="info">
  Scenes are **portable between the two Photons**. The operator surface is
  shared, so switching engines is replacing one TOP — bindings, lights, and
  cameras carry over untouched.
</Callout>

## When to reach for OVRTX [#when-to-reach-for-ovrtx]

| You are doing                                 | Use                         |
| --------------------------------------------- | --------------------------- |
| Previz with a director dragging lights around | **OVRTX**                   |
| Look development toward a final still         | [RTXPT](/docs/photon-rtxpt) |
| Live show output at frame rate                | **OVRTX**                   |
| Fixture-accurate lighting sign-off            | [RTXPT](/docs/photon-rtxpt) |

## What differs from RTXPT [#what-differs-from-rtxpt]

* **Radiance caching** — indirect light amortizes across frames; a moving
  camera doesn't restart the world
* **Fixed frame budget** — set milliseconds, not samples; quality scales to
  fit the frame time you have left
* **No accumulation state** — every frame is complete, so downstream
  feedback loops behave

<Callout type="warn">
  The trade: OVRTX's indirect lighting is approximate. Caustics, deep glass,
  and long light chains resolve on RTXPT only.
</Callout>

## Next steps [#next-steps]

<Cards>
  <Card href="/docs/photon-ovrtx/operators" title="Operators">
    Shared surface, engine-specific pages flagged.
  </Card>

  <Card href="/docs/photon-ovrtx/parameters" title="Parameter reference">
    The OVRTX-only parameters, next to the shared set.
  </Card>
</Cards>


# Lights (/docs/photon-ovrtx/lights)



Light types and units are shared with
[RTXPT → Lights](/docs/photon-rtxpt/lights) — lumens, lux, nits, EV. What
changes on OVRTX is *how many* lights stay cheap.

## Light counts [#light-counts]

RTXPT samples lights stochastically — hundreds are fine. OVRTX shades a
bounded set per pixel:

| Tier                | Count     | Cost                                |
| ------------------- | --------- | ----------------------------------- |
| Shadowed key lights | up to 8   | full shadows every frame            |
| Cached contributors | up to 256 | shadows via radiance cache          |
| Beyond that         | unlimited | ambient pool, no individual shadows |

The engine promotes and demotes lights automatically by contribution;
pin one with its **Priority** parameter when a cue depends on it.

<Callout type="idea">
  Concert rigs: leave moving heads in the cached tier and pin only
  followspots. Promotion churn during a blackout snap is what the Priority
  pin exists for.
</Callout>

<Callout type="warn">
  A DMX-driven light strobing at cache frequency defeats the cache — flag
  fast-flicker fixtures with `Animate → Realtime` so they bypass it and
  shade directly.
</Callout>


# Materials (/docs/photon-ovrtx/materials)



Materials are **defined once, rendered twice** — the same
`Photon Material` COMP feeds both engines. This page covers what OVRTX does
differently with them; the models themselves are documented under
[RTXPT → Materials](/docs/photon-rtxpt/materials).

## Fidelity by model [#fidelity-by-model]

| Model      | On OVRTX    | Notes                                         |
| ---------- | ----------- | --------------------------------------------- |
| Principled | Full        | Indistinguishable from RTXPT in most lighting |
| Emission   | Full        | Feeds the radiance cache directly             |
| Glass      | Approximate | Single refraction event; no nested interfaces |

<Callout type="warn">
  Glass-heavy hero shots are the one place scene portability has an
  asterisk: OVRTX renders one refraction bounce and estimates the rest.
  Preview on OVRTX, sign off on RTXPT.
</Callout>

## Texture streaming [#texture-streaming]

OVRTX streams bound TOP textures at half resolution while their content
changes, snapping to full when stable for a few frames — this keeps Movie
File In TOPs from stalling the frame budget.

```python title="Force full-res for a critical surface"
op('photon_mat_screen').par.streamquality = 'full'  # opt out per material
```

<Callout type="info">
  The half-res window is invisible on diffuse channels and noticeable on
  normal maps — flag hero normal-mapped materials `full` and leave the rest
  on `auto`.
</Callout>


# Operators (/docs/photon-ovrtx/operators)



OVRTX reuses the Photon helper COMPs — only the renderer TOP is its own
operator. If both plugins are installed, the helpers serve whichever
renderer collects them.

| Operator          | Family | Shared with RTXPT |
| ----------------- | ------ | ----------------- |
| `Photon OVRTX`    | TOP    | — (the engine)    |
| `Photon Material` | COMP   | Yes               |
| `Photon Light`    | COMP   | Yes               |
| `Photon Camera`   | COMP   | Yes               |

## The frame budget [#the-frame-budget]

The defining OVRTX control is on the Render page:

```python title="Textport"
render = op('/project1/photon_ovrtx1')
render.par.framebudget = 8.0   # ms — leave headroom for the rest of the network
```

The engine spends its budget in priority order — primary visibility first,
then shadows, then the radiance cache. Starve it and the image degrades
gracefully instead of dropping frames.

<Callout type="idea">
  Running at 60 fps with a 16.6 ms frame? Give OVRTX 8–10 ms and keep the
  rest for compositing. The `Perform` page's cook-time readout tells you
  what the whole chain actually costs.
</Callout>

<Callout type="info">
  A `Photon Material` bound in an RTXPT project needs no edits here — engine
  differences are absorbed by the renderer, not pushed into your scene.
</Callout>


# Parameter reference (/docs/photon-ovrtx/parameters)



<Callout type="info">
  Generated reference — same pipeline as
  [RTXPT's](/docs/photon-rtxpt/parameters). Placeholder subset until the
  generator lands. Shared pages (Scene, Output, Activate) are identical
  across both Photons and documented once there.
</Callout>

## Render page (OVRTX) [#render-page-ovrtx]

<TypeTable
  type="{
  &#x22;Frame Budget (ms)&#x22;: {
    description: &#x22;Hard per-cook time budget. The engine degrades quality before it drops frames.&#x22;,
    type: &#x22;float&#x22;,
    default: &#x22;8.0&#x22;,
  },
  &#x22;Radiance Cache&#x22;: {
    description: &#x22;World-space indirect cache. Off falls back to screen-space only.&#x22;,
    type: &#x22;toggle&#x22;,
    default: &#x22;on&#x22;,
  },
  &#x22;Cache Density&#x22;: {
    description: &#x22;Probe spacing in scene units. Tighter costs VRAM, resolves smaller detail.&#x22;,
    type: &#x22;float&#x22;,
    default: &#x22;0.5&#x22;,
  },
  Upscaler: {
    description: &#x22;DLSS preset for the internal-to-output resolution jump.&#x22;,
    type: &#x22;menu&#x22;,
    default: &#x22;Quality&#x22;,
  },
}"
/>

## Reading the health readouts [#reading-the-health-readouts]

The Info page reports where the budget went:

| Readout          | Healthy  | Investigate when                               |
| ---------------- | -------- | ---------------------------------------------- |
| `budget_used_ms` | ≤ budget | pegged at budget every frame                   |
| `cache_hit_rate` | > 0.8    | \< 0.5 — density too low for the scene scale   |
| `stale_probes`   | \~0      | climbing — geometry churning faster than refit |

<Callout type="warn">
  `Cache Density` below 0.1 in a stadium-scale scene allocates probe grids in
  the gigabytes. Scale density with scene scale — the default 0.5 assumes
  meters.
</Callout>


# Overview (/docs/photon-rtxpt)



**Photon RTXPT** is a path tracer that lives in your network. Geometry comes
in as SOPs or USD, lights and cameras are COMPs you already know, and the
render lands in a TOP — denoised, tone-mapped, and ready for compositing.

<Callout type="info">
  Photon RTXPT requires an RTX GPU (20-series or newer) — the path tracer
  runs on RT cores. See [Requirements](/docs/getting-started/requirements).
</Callout>

## How it renders [#how-it-renders]

A **frame is a cook**. Every time the operator cooks it traces a configurable
number of paths per pixel, accumulates against the previous frames when the
scene is static, and runs the DLSS Ray Reconstruction denoiser before output.
Move the camera and accumulation resets automatically.

<Cards>
  <Card title="Scene translation">
    SOP and USD inputs become RTX acceleration structures incrementally —
    only what changed re-uploads, so animated geometry stays interactive.
  </Card>

  <Card title="Physically based by default">
    Materials, lights, and camera exposure follow the same physical units as
    offline renderers — lumens, EV, and metric scene scale.
  </Card>
</Cards>

## What's in the box [#whats-in-the-box]

* One render TOP with the full parameter surface —
  [operators](/docs/photon-rtxpt/operators) has the map
* Principled, emission, and glass [materials](/docs/photon-rtxpt/materials)
* Area, sun, dome, and mesh [lights](/docs/photon-rtxpt/lights)
* A [parameter reference](/docs/photon-rtxpt/parameters) generated from the
  same source that registers them in TouchDesigner

## Next steps [#next-steps]

<Cards>
  <Card href="/docs/photon-rtxpt/operators" title="Operators">
    The operator set and how they wire together.
  </Card>

  <Card href="/docs/photon-rtxpt/parameters" title="Parameter reference">
    Every page, every parameter, with ranges and defaults.
  </Card>

  <Card href="/docs/guides" title="First render guide">
    From empty network to a denoised path-traced frame.
  </Card>

  <Card href="/docs/troubleshooting/gpu-requirements" title="GPU check">
    Confirm your hardware before you buy.
  </Card>
</Cards>


# Lights (/docs/photon-rtxpt/lights)



Every **Photon Light** works in physical units — lumens for emitters, lux for
the sun, EV-relative intensity everywhere. Match a lighting plot's numbers
and the render agrees with the venue.

## Light types [#light-types]

| Type | Shape                | Intensity unit | Shadows                 |
| ---- | -------------------- | -------------- | ----------------------- |
| Area | rect / disc / sphere | lumens         | soft, size-driven       |
| Sun  | directional          | lux            | sharp, angular-diameter |
| Dome | HDRI environment     | EV offset      | image-based             |
| Mesh | any SOP              | nits           | from geometry           |

## Driving lights live [#driving-lights-live]

Light parameters accept CHOP exports without resetting accumulation — they're
part of the light-sampling pass, not the scene build.

```python title="DMX → Photon"
# sACN in a CHOP, mapped straight onto a light
op('photonlight_key').par.intensity.expr = "op('sacn1')['u1c1'] * 15000"
```

<Callout type="info">
  Dome + area is the standard stage recipe: dome at −2 EV for ambience, area
  lights carrying the key. Start there before adding mesh emitters — they are
  the most expensive type to sample.
</Callout>

<Callout type="warn">
  A mesh light with thousands of triangles samples poorly and shows as noise
  in shadows. Decimate emitter geometry to the silhouette — the light looks
  identical and converges far faster.
</Callout>


# Materials (/docs/photon-rtxpt/materials)



A **Photon Material** binds a look to geometry by path pattern. Any channel
can be a constant or a TOP — textures stay on the GPU end to end.

## Material models [#material-models]

<Tabs items="[&#x22;Principled&#x22;, &#x22;Emission&#x22;, &#x22;Glass&#x22;]">
  <Tab>
    The workhorse — a Disney-style BSDF matching what your offline renderer
    calls Standard Surface.

    | Channel    | Takes       | Default  |
    | ---------- | ----------- | -------- |
    | Base Color | RGB / TOP   | 0.8 gray |
    | Roughness  | float / TOP | 0.5      |
    | Metallic   | float / TOP | 0        |
    | Normal     | TOP         | —        |
  </Tab>

  <Tab>
    Anything can glow. Emission is in **nits** so LED-wall content reads at
    believable levels next to physical lights.

    | Channel           | Takes        | Default |
    | ----------------- | ------------ | ------- |
    | Emission Color    | RGB / TOP    | white   |
    | Intensity (nits)  | float / CHOP | 100     |
    | Visible to Camera | toggle       | on      |
  </Tab>

  <Tab>
    Real refraction, not a transparency hack. Budget bounces accordingly —
    see the Note below.

    | Channel          | Takes       | Default |
    | ---------------- | ----------- | ------- |
    | IOR              | float       | 1.45    |
    | Roughness        | float / TOP | 0       |
    | Absorption Color | RGB         | white   |
  </Tab>
</Tabs>

<Callout type="warn">
  Glass needs path depth: at the default 4 bounces a glass-in-front-of-glass
  shot goes black where paths run out. Raise `Max Bounces` to 6–8 for
  transmissive scenes and watch the ms/frame readout.
</Callout>

## Binding [#binding]

```python title="Photon Material COMP — Binding page"
# Bind by path pattern, most-specific pattern wins
op('photon_mat_floor').par.bindpaths = '*/floor_geo'
op('photon_mat_hero').par.bindpaths = '*/hero/*'
```

Unbound geometry gets the default gray Principled — a scene never fails to
render because a pattern missed.

<Callout type="idea">
  Wildcards make LOD swaps free: bind `*/statue_*` once and every resolution
  variant inherits the same look.
</Callout>


# Operators (/docs/photon-rtxpt/operators)



Photon RTXPT installs one renderer and three helper operators. The renderer
owns the GPU pipeline; the helpers describe the scene.

| Operator          | Family | Role                                            |
| ----------------- | ------ | ----------------------------------------------- |
| `Photon RTXPT`    | TOP    | The renderer — traces, denoises, outputs        |
| `Photon Material` | COMP   | A material definition bound by path or wildcard |
| `Photon Light`    | COMP   | A light — area, sun, dome, or mesh emitter      |
| `Photon Camera`   | COMP   | Physical camera: focal length, aperture, EV     |

## Assembling a scene [#assembling-a-scene]

```python title="Textport — minimal scene"
render = op('/project1/photon_rtxpt1')
render.par.geometry = '/project1/geo1'      # any SOP hierarchy
render.par.camera = '/project1/photoncam1'  # falls back to a default cam
render.par.lights = '/project1/photonlight*'  # wildcard collect
```

The renderer collects by **path pattern** — the same wildcard rules as any
TouchDesigner parameter that takes an OP path. Drop a new
`Photon Light` matching the pattern and it joins the next cook.

<Callout type="info">
  Helper COMPs cook at parameter-change time only. The renderer is the only
  operator doing per-frame work — keep your cull flags on the SOPs feeding
  it, not on the Photon COMPs.
</Callout>

## Cook behavior [#cook-behavior]

* **Static scene** → progressive accumulation, up to the `Max Samples` cap
* **Camera move** → accumulation resets, denoiser bridges the gap
* **Geometry edit** → only the touched acceleration structure rebuilds

<Callout type="warn">
  Time-sliced CHOP exports into material parameters force a full reset every
  frame. Route animated values through the `Photon Material` COMP's dedicated
  Animate page instead — those update without invalidating accumulation.
</Callout>


# Parameter reference (/docs/photon-rtxpt/parameters)



<Callout type="info">
  This reference is **generated** — the same source that registers parameters
  with TouchDesigner emits these tables, so they cannot drift from the build.
  Placeholder subset below until the generator lands.
</Callout>

## Render page [#render-page]

<TypeTable
  type="{
  &#x22;Samples / Cook&#x22;: {
    description: &#x22;Paths traced per pixel per cook. Raise for stills, keep at 1–2 for live output.&#x22;,
    type: &#x22;int&#x22;,
    default: &#x22;1&#x22;,
  },
  &#x22;Max Samples&#x22;: {
    description: &#x22;Accumulation cap for static scenes. 0 accumulates forever.&#x22;,
    type: &#x22;int&#x22;,
    default: &#x22;1024&#x22;,
  },
  &#x22;Max Bounces&#x22;: {
    description: &#x22;Path depth. 2 covers most stage looks; glass wants 6+.&#x22;,
    type: &#x22;int&#x22;,
    default: &#x22;4&#x22;,
  },
  Denoiser: {
    description: &#x22;DLSS Ray Reconstruction, spatial-only, or off (raw accumulation).&#x22;,
    type: &#x22;menu&#x22;,
    default: &#x22;DLSS-RR&#x22;,
  },
  Exposure: {
    description: &#x22;EV100 exposure applied before tone mapping.&#x22;,
    type: &#x22;float&#x22;,
    default: &#x22;0&#x22;,
  },
}"
/>

## Output page [#output-page]

<TypeTable
  type="{
  Resolution: {
    description: &#x22;Output size. Internal trace resolution follows the DLSS quality preset.&#x22;,
    type: &#x22;wh&#x22;,
    default: &#x22;1920 × 1080&#x22;,
  },
  &#x22;Tone Map&#x22;: {
    description: &#x22;ACES, AgX, or linear passthrough for downstream grading.&#x22;,
    type: &#x22;menu&#x22;,
    default: &#x22;ACES&#x22;,
  },
  &#x22;AOV Layers&#x22;: {
    description: &#x22;Extra outputs: albedo, normals, depth, direct/indirect split.&#x22;,
    type: &#x22;toggle set&#x22;,
    default: &#x22;off&#x22;,
  },
}"
/>

## Full table [#full-table]

<Accordions type="single">
  <Accordion title="All pages, all parameters (placeholder dump)">
    | Page     | Parameter      | Type       | Default     |
    | -------- | -------------- | ---------- | ----------- |
    | Render   | Samples / Cook | int        | 1           |
    | Render   | Max Samples    | int        | 1024        |
    | Render   | Max Bounces    | int        | 4           |
    | Render   | Denoiser       | menu       | DLSS-RR     |
    | Render   | Exposure       | float      | 0           |
    | Output   | Resolution     | wh         | 1920 × 1080 |
    | Output   | Tone Map       | menu       | ACES        |
    | Output   | AOV Layers     | toggles    | off         |
    | Scene    | Geometry       | OP path    | —           |
    | Scene    | Camera         | OP path    | —           |
    | Scene    | Lights         | OP pattern | —           |
    | Scene    | Scene Scale    | float      | 1.0         |
    | Advanced | Ray Offset     | float      | 0.0001      |
    | Advanced | Firefly Clamp  | float      | 8.0         |
    | Activate | License Key    | string     | —           |
  </Accordion>
</Accordions>


# Activation problems (/docs/troubleshooting/activation-problems)



Activation failures are deliberately specific — the `Status` readout names
the exact refusal. Find yours below.

<Accordions type="single">
  <Accordion title="`Key invalid` — the key is rejected outright">
    Three causes, in frequency order: a typo (keys are
    `NOP-XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX` — 36 characters after the
    prefix, so the dashboard's copy button beats retyping), a key for a *different plugin* (keys are plugin-scoped), or a
    revoked key after a refund. The [dashboard](/dashboard) shows each
    key's plugin and state.
  </Accordion>

  <Accordion title="`Seat in use` — bound to another machine">
    The seat is active elsewhere — possibly a dead machine that never got
    the chance to deactivate. Free it from the
    [dashboard](/dashboard) (**Seats → Deactivate**); the change is
    immediate, no support ticket needed.
  </Accordion>

  <Accordion title="`Fingerprint mismatch` — offline file won't take">
    The `seat.license` was issued for different hardware. Regenerate the
    `machine.request` *on the machine as it is now* and reissue — this hits
    people who swapped a GPU, and farm operators who cloned an image with a
    request file baked in.
  </Accordion>

  <Accordion title="`Clock skew` — system time too far off">
    Offline licenses carry a signed timestamp. Air-gapped machines drift;
    more than 48 hours breaks validation. Set the clock (GPS/NTP appliance
    on show networks), regenerate, reissue.
  </Accordion>

  <Accordion title="Activation hangs — no error, no success">
    The machine can't reach the licensing endpoint. Corporate TLS
    inspection is the usual culprit — ask IT to exempt
    `licensing.nativeops.tools`, or use
    [offline activation](/docs/getting-started/activation#offline-activation),
    which exists for exactly this network.
  </Accordion>
</Accordions>

<Callout type="info">
  None of it matching? [Contact support](/contact) with the Info DAT
  diagnostics dump (right-click the operator → **Copy Diagnostics**) — it
  includes the last ten status transitions, which is usually the answer.
</Callout>


# Drivers (/docs/troubleshooting/drivers)



Driver bugs present as **device-lost crashes** mid-session or as denoiser
artifacts — not as load failures. If the operator loads and then the GPU
resets under load, start here.

<Callout type="info">
  Short version: run the latest **Studio** driver. Game Ready drivers ship
  first and regress compute paths more often; Studio is the same driver on a
  slower, better-tested cadence.
</Callout>

## Known ranges (placeholder) [#known-ranges-placeholder]

| Driver range    | Symptom                         | Verdict          |
| --------------- | ------------------------------- | ---------------- |
| 572.00 – 572.42 | DLSS-RR denoiser NaN flashes    | Skip             |
| 566.xx          | Stable everywhere we test       | Floor for Photon |
| \< 560.00       | Load refused (`Driver too old`) | Hard floor       |

## The clean-install ritual [#the-clean-install-ritual]

When a machine misbehaves on a driver that's fine elsewhere:

<Steps>
  <Step>
    Download the current Studio driver directly from NVIDIA — not Windows
    Update, not GeForce Experience.
  </Step>

  <Step>
    Run the installer with **Custom → Perform a clean installation**
    checked. This clears cached shader blobs and stale settings profiles,
    which is the actual fix more often than the driver version.
  </Step>

  <Step>
    Reboot, then delete TouchDesigner's own shader cache folder so nothing
    stale is replayed against the new driver.
  </Step>
</Steps>

<Callout type="warn">
  Enterprise/vPro fleets that pin drivers via SCCM: the pinned driver is
  usually months behind the floor. The plugins print the minimum version in
  the status string — hand that line to IT, it is the whole conversation.
</Callout>


# GPU requirements (/docs/troubleshooting/gpu-requirements)



At load, every operator runs the same checks in order and stops at the first
failure — the `Status` readout names it. Work down the same list.

<Steps>
  <Step>
    ### `No CUDA device` [#no-cuda-device]

    TouchDesigner isn't running on the NVIDIA GPU. On laptops, force it:
    NVIDIA Control Panel → Manage 3D Settings → Program Settings →
    TouchDesigner → **High-performance NVIDIA processor**.
  </Step>

  <Step>
    ### `CUDA version` — compute capability below 7.5 [#cuda-version--compute-capability-below-75]

    The GPU predates Turing (GTX 10-series or older). No setting fixes
    this — see the support matrix in
    [Requirements](/docs/getting-started/requirements).
  </Step>

  <Step>
    ### `GPU unsupported` — RT cores missing (Photon only) [#gpu-unsupported--rt-cores-missing-photon-only]

    GTX 16-series has CUDA 7.5 but no RT cores: Matter and Aura run, the
    Photons refuse. This is the one row where plugins diverge.
  </Step>

  <Step>
    ### `Out of memory` at first cook [#out-of-memory-at-first-cook]

    The checks passed; the scene doesn't fit. Drop the internal resolution
    preset, or close Chrome — its GPU process routinely holds 1–2 GB.
  </Step>
</Steps>

## FAQ [#faq]

<Accordions type="single">
  <Accordion title="It loads on my desktop but not my laptop — same drivers.">
    Almost always Optimus: the laptop is cooking TouchDesigner on the iGPU.
    The `No CUDA device` step above fixes it. Verify with the Info DAT —
    `gpu_name` should say NVIDIA, not Intel/AMD.
  </Accordion>

  <Accordion title="Will it use my second GPU?">
    Not yet — the operator cooks on TouchDesigner's active adapter.
    Multi-GPU affinity is on the [roadmap](/roadmap).
  </Accordion>

  <Accordion title="What about laptops with shared VRAM?">
    Shared system memory counts toward nothing: the 6 GB floor means
    dedicated VRAM. A 4 GB dedicated + 8 GB shared laptop fails the check
    honestly.
  </Accordion>
</Accordions>


# Troubleshooting (/docs/troubleshooting)



Every NativeOps operator reports its state in the `Status` readout on the
Common page. That string is the fastest route to the right page below.

| Status says                             | Go to                                                            |
| --------------------------------------- | ---------------------------------------------------------------- |
| `GPU unsupported` / `CUDA version`      | [GPU requirements](/docs/troubleshooting/gpu-requirements)       |
| `Driver too old` / device-lost crashes  | [Drivers](/docs/troubleshooting/drivers)                         |
| `License invalid` / `Activation failed` | [Activation problems](/docs/troubleshooting/activation-problems) |
| Operator missing from OP Create         | [Installation](/docs/getting-started/installation)               |

<Cards>
  <Card href="/docs/troubleshooting/gpu-requirements" title="GPU requirements">
    The load-time hardware checks and what each failure means.
  </Card>

  <Card href="/docs/troubleshooting/drivers" title="Drivers">
    Known-bad driver ranges and the clean-install ritual that fixes most
    device-lost errors.
  </Card>

  <Card href="/docs/troubleshooting/activation-problems" title="Activation problems">
    Key rejected, seat conflicts, offline files that won't take.
  </Card>
</Cards>

<Callout type="info">
  Filing a [support request](/contact)? Attach the operator's Info DAT dump
  (right-click → **Copy Diagnostics**) — it carries the plugin build, driver,
  GPU, and the last ten status transitions, and it turns most tickets into
  one-reply fixes.
</Callout>