Automatic conversion
Wire whatever you have into whatever you need. The conversion is inserted for you, and only the baking and meshing ones cost real time.
Plug a shape into an image input, a number into a colour, a gradient into a fill: where a sensible conversion exists, it is inserted automatically. There is no convert node to hunt for.
Sockets stay honestly typed through all of this, so socket colours and previews keep their meaning.
Most conversions are instant re-labelling. A few do genuine work, turning a formula into pixels or shapes into a solid mesh. Those are the ones worth being deliberate about.
Free conversions
These cost almost nothing. The same data is read a different way.
Number into a colour: becomes a shade of grey, with the number setting the brightness.
Number into a position or vector: fills the first axis.
A Gradient into a colour input: the gradient becomes a left-to-right colour field, ready to sample or composite.
A shape into a field or fill input: Analytic shapes flow straight in as a usable field.
A light into a colour input: a light is colour over space, so it drops into colour graphs directly.
An image into a colour input: an image already counts as a colour field.
A specific kind of collection into a general one: circles flowing into a node that accepts any collection.
A scalar or distance field into a vector input: its gradient is taken, so the arrows run uphill toward higher values. The Vector Field node is where you go to flip that direction.
A vector field into a force input: a field of arrows is already a force, so it says yes to a simulation with no node in between.
Gaussian splats into a points input: each splat's position, colour, size and orientation arrive as ordinary point columns.
Conversions that cost real time
These do actual computation, often on the GPU. They are still automatic, and they are the ones to watch when a graph feels heavy.
Shapes or collections into pixels (rasterising). Shapes meeting an image input are rendered to a pixel image first. This is the most common real-work conversion.
Baking a field into an image. A procedural field, noise or a gradient or a colour formula, is rendered to actual pixels because the next node samples pixels rather than a formula. Baked at a default resolution you can adjust.
Building a Distance Field from a mesh. Measures distance to the surface so the shape can be blended, offset or combined smoothly.
Points into a solid shape. A cloud of points becomes a smooth blobby surface, metaball style, ready to mesh.
Meshing a field into geometry. Turns a Distance Field or Volume into real geometry with points and surfaces.
Baking a Distance Field into a Volume. Fills a 3D grid so volume-only nodes can read it.
A field into points. A field or image meeting a points input is sampled on a grid, one point per cell, and each point keeps what it read there:
@Cdfrom a colour field or an image,@densityfrom a scalar field,@vfrom a vector field.
A baked image or volume uses a default resolution. If the result looks soft or chunky, the inserted conversion exposes a resolution setting you can raise, with no rewiring.
Not everything converts. Some pairs genuinely do not fit, a 3D volume into a flat-image-only input for instance. The wire still draws, but it is dead: the console warns that the pair has no adapter and that the wire is non-functional until the types match. A drawn wire is not proof that anything is flowing.
Watching it happen
Select a node and look at the data viewer's header. When the cook inserted conversions on that node's inputs, an ⚠ implicit chip lists them by name, each tagged with what it cost: a time in milliseconds when the conversion cooked on its own, or fused when it was absorbed into the node's own GPU dispatch and has no separable cost. A sluggish graph is worth checking here first.
The cook glyph beside a node's title is a different thing. It sets when the node re-runs rather than reporting how often it did.