Connecting modules

A particle kernel reads the camera. A fish’s steering reads the neighbour grid. Your lighting reads ambient occlusion. Each time, a shader reads resources another module owns. It reads them through an accessor, the owner fills the accessor with its inject(), and the pipeline is created from root.pipe(owner.inject()), as with the ripple in How the kit works.

A module others read

A weather module keeps the wind in a uniform and offers windAt to other shaders. A snow module’s kernel calls it, so the snow takes the weather as an argument and pipes its fill:

export function createWeather(root: TgpuRoot) {
  const state = root.createUniform(WeatherState);
  const weather = tgpu.accessor(WeatherState);

  return {
    state,
    windAt: () => {
      'use gpu';
      return weather.$.wind;
    },
    inject: (): Inject => (cfg) => cfg.with(weather, state),
  };
}

export function createSnow(root: TgpuRoot, weather: ReturnType<typeof createWeather>) {
  const drift = root.createMutable(d.arrayOf(d.vec2f, 1024));
  const fall = tgpu.computeFn({ workgroupSize: [64], in: { gid: d.builtin.globalInvocationId } })(({
    gid,
  }) => {
    'use gpu';
    if (gid.x >= 1024) return;
    drift.$[gid.x] += weather.windAt();
  });

  return root.pipe(weather.inject()).createComputePipeline({ compute: fall });
}

• Chain fills for a pipeline that reads several modules: root.pipe(enemies.inject()).pipe(weather.inject()).
• An accessor no shader reads adds no binding, so piping more fills than a pipeline uses costs nothing.
• A factory takes each module it reads as a named argument, never a list of modules.

Three kinds of accessor

Where an accessor is made decides what a pipeline can read through it:

Kind	Made	Two in one pipeline	In the kit
Per instance	in create	both are read	particles’ emit, the grid’s walk, events’ add, live lists’ slot, text’s setLabel, the picker’s found
Definition	beside a definition	the later pipe wins	a table definition’s rows, a machine’s rows and events, the mesh pool’s vertexAt, the environment’s cube, the sun
Hook	at module scope	one, chosen on purpose	cameras.current, the lighting’s reflect, ambient, fog and sunShadow, ao.at, dof.circle, video.sample

• A per-instance accessor, like the weather’s, reads one instance’s resources, so one kernel can emit into two particle systems or walk two grids.
• A definition accessor exists before any instance, so a shader written against Enemy.position(i) works for whichever table of enemies it is piped with.
• A hook is a piece each pipeline chooses, so two descriptions of passes can draw the same drawings through two cameras, such as a scene and a reflection.

The figure resolves a pipeline piped two instances of each kind, in either order, one or none, and shows whose resources it binds.

Per instanceDefinitionHook

solid, then ghostghost, then solidsolid onlynothing

Choose which instances fill the pipeline's root. The diagram shows which resources it binds after TypeGPU resolves it on a recording root.

Each module’s card lists what it injects and of which kind.

Callbacks carry their fills

A module that takes a 'use gpu' function, such as particles’ update or bloom’s bright, builds its pipelines without knowing what the function reads. Pipe the fills into the function itself:

const warm = tgpu.fn(glowOf).pipe(weather.inject()); // reads the weather
const glow = bloom.create(root, { source, bright: warm });

Particles’ update, born, died and place, a trail’s width and shade, and the lighting’s shading hooks all take functions this way. A callback can read cameras.current.$ without a fill, because the description of passes fills the camera.

Resources that are replaced

A fill binds a fixed resource, so replacing the resource would need a new pipeline. A resource that is replaced, such as a texture that follows the screen size or each new camera frame, goes in a bindings part instead. Your program shares every part into one layout before creating the pipelines that read them, and sets that layout’s group on each pass.

• Ambient occlusion and depth of field keep their textures in parts, because they follow the depth’s size.
• A live video binds each camera frame through its part.
• passes.create(…, { shared }) sets the shared group on every pass the description opens.

Missing fills

A pipeline that reads an accessor nothing filled fails at first use or in initAsync, so warm-up catches it while loading. The kit’s accessors default to unfilled, which names the inject() to add, as in Nothing filled `cameras.current` . Yours can do the same:

const weather = tgpu.accessor(
  WeatherState,
  unfilled('the weather', 'weather', 'a `createWeather`'),
);

A pipeline that reads a part nobody shared throws as it builds and names the call to add.

All three together

Ambient occlusion and lighting use every way of connecting. The occlusion reaches the lighting through a callback that carries its fill, both read the camera through a hook, and the occlusion’s texture sits in a shared part because it is replaced when the depth resizes:

import { ao, bindings, lighting, passes, shading } from '@typegpu/kit';

const occlusion = ao.create(root, view, { depth: () => early.textures.depth });
const shared = bindings.share(root, { ao: occlusion.part }); // a part

const sky = (material: shading.Material, point: shading.Point) => {
  'use gpu';
  return shading.hemisphere(material, point) * ao.at(point.position);
};
const light = lighting.create(root, {
  shading: { ambient: tgpu.fn(sky).pipe(occlusion.inject()) }, // a callback
});

const scene = passes
  .create(root, screen, { hdr: passes.color, depth: passes.depth }, { shared })
  .pipe(view.inject()) // a hook
  .pipe(light.inject()); // definitions: the sun, the lights, the shadow

Ambient occlusion runs this scene in full, and Write a module builds a module of your own.