Texture Resolution QC

2026Solaris LOP, one HDARay engine and Karma image engineChecked against Karma CPU and XPUDemo assets CC0 Poly Haven

Houdini 22
Solaris
Karma
USD
Python
VEX
Copernicus

A LOP that measures, per prim and per UDIM tile, the texture resolution the shot cameras actually read, paints the answer on the geometry, checks it against what Karma samples, and writes the textures and the USD layer that act on it.

2:34, silent with captions, the motion at 3.6×

0.0median error in mip levels against Karma CPU, over 21 M pixels
-60 %Karma CPU peak memory on the demo set once its textures are tiled and mipmapped
25 scook of a 1.18 M-instance alpine meadow, 108 prototypes, 4.3 M faces traced
1 nodeone LOP HDA; bypass it and nothing remains on the stage

The question

Texture sizes are decided before the shots exist: a vendor spec, a rule of thumb, whatever the asset came with. The tool replaces the guess with a measurement from the shot cameras: a map of the minimum resolution every prim and UDIM tile needs for the shots as framed. That map is the main thing it gives you. Its first job is the asset that ships too small, the 4K hero prop a close-up reads at 8K, caught on the set before it is painted, or at least before dailies. The oversized background that costs memory, network and disk on every frame falls out of the same map, and is the smaller win.

The dolly onto a crate stack with the Required-size heatmap wiping across — cam_push, a dolly onto a crate stack. Required size, per UDIM tile: 8K where the camera lands, 2K down the alley.

Mip delta view on the same frame — Mip delta against the textures bound today: -3 means this 1K crate is three levels short for the close-up.

The same frame rendered with the 1K crate as shipped and with the 8K the tool asks for — The same frame at 1920: the 1K crate as shipped against the 8K the tool asks for. Three levels of detail the shot wants and the asset does not have.

The maths

A render pixel covers a small parallelogram in uv space. Texels smaller than that parallelogram are never read at that pixel, so the finest mip level a shot touches is set by its worst pixel. The tool measures that footprint the way the renderer does, with ray differentials: three rays one pixel apart, the hit on the surface's tangent plane, the uv difference between them.

J        = [ du/dx  du/dy ]     uv change per screen pixel, from three rays one pixel apart
           [ dv/dx  dv/dy ]
required = 1 / texel_size(J)    texels per tile edge: the footprint's short axis (minor), as Karma picks the level
authored = pow2ceil(required x 1.5)
mip delta = log2(current / authored)      +1 oversized by a level, -1 a level short
density needed = 1 / footprint on the surface        pixels per meter the camera puts there, same metric, blind to the uv layout
density today  = current x sqrt(uv area / world area)   what the bound texture gives per meter

Every size is for the render width. The reference here is 3840 x 2160; the push-in and the lamp camera render at 1920 and are measured at their own width, so the 8K the crates ask for is the push-in's own number (16K were it a 4K camera). Required scales linearly with the width: a show at HD throughout asks one level less everywhere, and the report lists the sizes for every Report Width.

Three loupes over the alley render showing one pixel's footprint on the ground at 6, 13 and 22 m with the texel grid of the authored size — cam_shot, 3840 wide, 35 mm. One pixel's footprint on the ground at three distances, magnified, with the texel grid of the size the tool authors for it. At 6 m a pixel covers 1.5 x 5.5 mm of cobblestone: 2,631 texels per 4 m tile edge, 4K with headroom. At 22 m: 6 x 80 mm, 1K.

Which axis of the footprint

Metric	Texel size	Matches
`minor` (default)	the short axis, clamped by Max Anisotropy (16)	Karma CPU and XPU, measured with the mip probe below: median error 0.0 / -0.5 levels
`area`	geometric mean of both axes	isotropic mip selection; one level too coarse on surfaces seen at an angle (the old default)
`major`	the long axis	trilinear filtering without anisotropy: the most conservative

Frontal surfaces give the same answer with every metric; grazing walls and floors are where they differ by a level, and where a wrong default quietly under-sizes a set.

How it runs

Witness view from above: three camera frustums, the dolly path, and the Winning camera colors — Three shot cameras from their RenderSettings (3840 static, a 1920 push-in over 48 frames, a 1920 85 mm on the far lamp), drawn as frustums with the dolly path and name cards. Winning camera mode: which camera set each tile's requirement.

Ray engine (default). A ray grid from every shot camera at every N-th frame (last frame always included), one ray per sampled pixel plus the analytic footprint of its two neighbors, VEX intersect() against the render-purpose geometry. Seconds on a set, no render setup, updates while a camera moves. Cameras are read from the stage per frame through the USD API; cameras keyframed on LOP nodes are cached over their range so each sample sees the camera where it is.

Karma image engine. The same maths on rendered AOVs: a per-prim id and a copy of st, rendered with husk at each camera's own resolution, finite differences between 4 x 4 pixel windows. Subdivision, displacement, motion blur and depth of field are in the data for free. It also renders a footprint image per frame: the finest mip level the shot reads from the textures bound today, per pixel.

Occluders. Everything a render sees blocks the rays, measured or not. A barrel behind a door gets no requirement, reads NOT SEEN and gets the minimum size, even when the door is outside the primitive pattern. Proxy and guide purposes and invisible prims never block and are never measured.

Aggregation. The maximum per (prim, UDIM tile) over every camera and frame, with the camera and frame that set it. Size Per decides what shares a size: the object (all its tiles get its neediest tile's size, what you export per asset), the texture set (every prim bound to one material, as Painter exports it), or each tile on its own.

Texture space. Each map is sized in the space its shader samples, found by walking the material graph: UsdTransform2d and place2d scale, constant multiplies, tiledimage tiling. A coordinate that comes from position (MaterialX triplanar) is world-projected and sized from the surface's pixels per scene unit, uvs or not.

Instancing. One size per prototype, the largest any instance needs, traced on 32 copies per prototype by default under a face budget, half the biggest on screen and half spread out in space among those within a level of it, so copies hidden together behind one wall cannot take every slot (if every traced copy still comes back hidden while others are in view, the prototype is estimated, never reported missed); prototypes over the budget are estimated from uv density and the nearest instance, conservatively. A million-instance PointInstancer cooks in about a second.

In Houdini, viewport only. The light version of the workflow needs no render: drop the node after the set, press Cameras From Stage, set the display flag, and the ray engine paints the required sizes in the Storm viewport within seconds. The Display Mode menu switches to mip delta, winning camera or coverage; the tile panel filters the tiles short by a level or more, selects the prims and frames them. Karma is only needed for the image engine and the probe.

Houdini UI: the alley in the Storm viewport painted with required sizes, the node parameters on the right — The Storm viewport right after the display flag: required sizes per tile, labels on the surfaces, the node in the parameter pane.

The tile panel: a red banner naming four missing texture files, cards counting tiles to fix, too small, too big, missing file, right size, not seen and no texture, above a list of objects with the size each needs, has, and a verdict — The tile panel. Cards count the tiles per verdict and filter the list on a click. Each row gives the object, the size it needs, the size it has, and a verdict such as "3 levels too small", worst first. The measured numbers sit behind Details. Click a row to select the object, double click to frame it. The red banner names texture files a material expects but that cannot be read: here the jerrycan, whose package points at Poly Haven's build server.

Size Per: Object, Texture set, UDIM tile — Size Per on the alley: one size per object, per texture set, or per UDIM tile.

The views, in the viewport

Painted on the geometry as per-face display color plus a preview material the node binds while it is active, so it shows in Storm and in the Karma viewport and renders as a QC frame. Each tile also carries its value as a small label texture, repeated by its screen size.

≤2565121K2K4K8K>8Kno texturenot seen

No texture marks a surface whose material binds no texture file at all, only a flat color, so there is no size to set. Before, such a surface could read not seen: the meadow's procedural shrub leaves carry uvs that are all (0, 0), so every sample on them was dropped.

Required size view — Required size : the brief for texturing, the size to author per tile at the reference width.

Mip delta view — Mip delta : QC once textures exist. Blue is oversized by that many levels, orange and red are short.

Winning camera view — Winning camera : which shot drives each tile, and so each cost.

Coverage view — Coverage : sampled, in frame but never hit (lower the pixel step, or occluded), outside every camera, no uvs.

Two more: Shell need colors every UV shell by the size it needs on its own, and Budget shows the levels given up to fit a memory budget. Every tile keeps its measured texres:required, texres:authored, texres:current, texres:delta, texres:camera and texres:frame as primvars (and the texel densities below), readable in Scene Graph Details, by COPs, or by anything downstream.

Texel density, the same map per meter. Studio standards are written in pixels per meter of surface, not per UDIM tile, and that is the number an asset keeps when it travels to another sequence. The tool gives both sides in that unit. Needed is what the cameras put on the surface: the same rays measure the pixel's footprint in scene units through the same metric, so a badly packed uv shell cannot inflate it (the crates 1,100 to 1,700 px/m at the end of the push-in, the back wall 120). Today is the bound texture over the uv layout (1K on a crate is 610 px/m, 1K on a 4 m wall tile 256). The requirement through the uv layout is kept beside them: where it sits a level or more above the surface need, the layout wastes the texture, and the report says re-uv and points at the shell.

A standard, proposed or anchored. With no anchor given, the tool proposes the scene's standard: the smallest density that covers 90 % of the objects by their surface need, 1,249 px/m on the alley, with the four crate parts above it listed as the exceptions that keep their camera-map size. Name an anchor asset instead, the one asset whose density the show keeps, and its density becomes the standard. Density vs anchor paints every tile's levels above or below it, texres:uniform is the size that puts the tile at it (tiny objects fall to the Minimum Size), and the report prices the uniform set against the camera need: 3.4 G texels against 3.0 G on the alley, 43 tiles oversized for the shots, 9 still short of their recommended size. One standard never fits every asset; if it fits 90 % of them and the map names the rest, that is the gain. Read as a decision, the view says where to spend: the ground and the walls fill the frame, so they get one level each, and the view then reads ground 0, walls -1, the crates still on their own camera size.

Texel density needed and today on the alley, in pixels per meter — Texel density : needed from the cameras (left) and today from the bound textures (right), px/m, the Required-size bands read per meter.

Density vs the proposed standard on the alley — Density vs the proposed standard (1,249 px/m): the walls sit 2.3 levels under it, the street seating 1.6 over, the crates one under.

The same view after the ground and the walls were bound one level up — The decision applied: the ground one level up (4K per 4 m tile) and the side walls one level up (the 2K the up-res made from the 1K plaster). Ground 0, walls -1, the crates keep their camera-map size.

Ground truth

A prediction of what a renderer reads is only worth what it is checked against. The mip probe swaps every color map for a probe texture of the same size whose mip levels carry their own level number, renders the stage with Karma through the production materials (so uv transforms and triplanar projections count), and compares the level Karma read per pixel with the tool's prediction.

Mip probe: the level Karma read per pixel, the error of the area metric, the error of the minor metric — cam_shot, frame 1. Left: the mip level Karma CPU read per pixel (red 0 to purple 7). Middle: prediction minus Karma with the area metric, one level fine on the grazing walls and floor. Right: the minor metric, gray where they agree.

21 Mpixels compared: three cameras, first and last frame
0.0median error in levels, Karma CPU (whole levels)
-0.5Karma XPU, which blends levels: half a level fine, inside the 1.5x headroom
28 / 28smoke test against the analytic answer: ray engine within 0.1 %, image engine within 4 %

What the probe caught: the first default, area, sized oblique surfaces one level too small. The default is now minor, the footprint's short axis clamped by the anisotropy limit, which is how Karma picks the level. Silhouette pixels are left out of the probe: they mix a prim's probe color with whatever lies next to it, and the level decoded from that mix is arbitrary. With them in, thin far parts of the street seating looked three levels finer than predicted; on their interior pixels they behave like the rest of the alley. Per prim, the recommended size covers what Karma reads for 23 of 30 prims on CPU (the others one whole level, the step CPU reads in) and 27 of 30 on XPU, within half a level.

Beyond the simple case

Instancing: 164 crates on a PointInstancer and 20 native barrels, one size per prototype — Instancing. 164 crates on a PointInstancer and 20 native barrels: one size per prototype, the largest any instance needs, 16 traced each. Real set: a HouLab alpine meadow, 1.18 M plant instances over 108 prototypes and the terrain: 4.3 M faces traced, 19 tree parts estimated over the face budget, cook 25 s, 10 GB peak. In the scene's render layer the scree and the boulders bind a triplanar rock material and carry no uvs, so the tool sizes them from world space; the report lists them as prims without uvs.

The HouLab alpine meadow from its hero camera, required size per tile: yellow terrain at 4K, plant instances as dark clumps, the scree and boulders in blue — The meadow from its hero camera, required size: the terrain tiles yellow (4K), the plant instances the dark clumps (each prototype at the size its nearest instance needs), the scree band and the boulders blue (512 to 1K, sized from world space).

The alpine meadow from eye height at the scree band: the beauty render on the left, required size per tile on the right — The same set from eye height, 1.6 m above the meadow where it meets the scree band. Left, the beauty; right, required size. The meadow underfoot asks for 4K to 8K, while the slope farther up drops to 1K. The scree and boulders come out at 512 to 1K: their triplanar rock material has no uvs, so they are sized in world space. The shrubs and grasses are purple: they bind a flat-color material, so there is no texture size to set. This view found that case: the shrub leaves carry uvs that are all (0, 0), so they used to read as missed and drew grey, as if unseen.

The dressed alley: the beauty render wiping to the required size per tile — A dressed set. The alley rebuilt the way a production set is: a 6 m lane between an apartment block and a factory, both fronts assembled from Poly Haven's modular facade kits (659 instanced bays), a fire escape, ducts, shutters, 45 props, 140 scattered pieces of junk on a PointInstancer, and a cross street with sidewalks, cars and power poles. 223 objects, 307 texture files, four cameras: one cook of about a minute, 13 GB peak.

The dressed alley: required size wiping to the mip delta against the textures as shipped — Against what the packages ship: 106 tiles too small, 68 too big, 25 right. In a 6 m alley the shared wall and ground textures sit 2 to 4 levels short, since one kit texture set covers every bay and the camera brushes past the nearest. The rat, the spray cans and the far street seating ship 3 to 4 levels too big. A proposed standard of 720 px/m covers 156 of 173 objects.

The tile panel's missing-texture banner — Missing textures. The dressed set found 12 texture files its materials point at but cannot read: three packages carry paths on Poly Haven's build server, and one names its roughness .exr while shipping a .jpg . Karma renders those maps black, and nothing else says so. The panel names the files, counts the objects in To fix, and copies the list. The demo set repairs them with a fix-up layer per package; the packages are never edited.

Occlusion: a barrel behind a door — Occlusion. Two identical barrels 2.2 m from the camera, one behind a door: 4K and NOT SEEN. Eight door/bin cases (closed, outside the pattern, render purpose, proxy, invisible, half open, a bin with its own proxy) pass with both engines.

The witness camera beside the door: the barrel the shot never sees carries NOT SEEN, the one in view 4K — The same two barrels from a witness camera beside the door: the hidden one carries NOT SEEN, the one in view 4K.

UV shells: one shell packed at a quarter scale — UV shells. One front shell packed at a quarter of its size drags the crate from 8K to 16K. The report names it: shell 43, 1.2 % of the uv area, needs 16K, the rest 8K; scale its uvs x2.8, tile 73 % full after.

UDIM layouts: uniform versus split by need, and what one 16K map costs — UDIM layouts. A 30 m walkway seen from one end, every plank the same uv size: 1 x 16K today, 268 M texels. From the per-shell needs the tool proposes 4K + 4K + 2K split by need: 38 M texels, 85 % fewer, with Karma's per-pixel mip map going from several wasted levels to the headroom margin.

Texture space: UsdTransform2d tiling and a triplanar cube — Texture space. A 4 m wall tiling cobblestone x4 through UsdTransform2d: 2K, not 8K. A cube with no uvs under a MaterialX triplanar: measured from world space, 4K. 100 % crops at the recommended size stay close to 8K; one level below loses visibly.

Content-aware sizes: A, B, C crops with difference images — Content-aware. A file can only hold the detail it holds: per octave, what halving it throws away. The plaster roughness carries 32 px, the cobblestone diffuse 4K of its 8K, the crate's metal mask 2K; normal maps keep 8K. B (sized by content) differs from A by 0.003, an even haze; C, one level below, by 0.005-0.007 with scratches and grit in the difference.

Texture budget. Give it a memory budget and it fits the recommended sizes into it: the map whose halving saves the most bytes per unit of visible loss goes first, loss being kind weight (normal 1.5, color 1, scalar 0.5) x screen share x levels below need. The alley at 25 % of its recommended 17.9 GB: crates differ 0.0020 from the recommended render, against 0.0060 for halving every map at the same memory (under a sun, so the normal maps count).

Outputs

The HTML report: stat tiles, mode switch, UDIM sheets per prim — The HTML report: every prim as a UDIM sheet in uv space, the four color modes switchable on the page, a filter, and a sortable table of every tile with a CSV beside it.

Report (HTML + CSV), written on demand or on every cook; with the image engine, a footprint image per camera frame with the share of soft and oversized pixels.
Tile panel inside Houdini: a red banner that names texture files a material expects but cannot read; cards that count and filter (to fix, too small, too big, missing file, right size, not seen, no texture), each tile in words (needs, has, verdict), the measured numbers behind Details; click to select, double-click to frame.
UDIM sheets: one PNG per tile per prim with the uv wireframe and the label, for Painter (UDIM import, as a reference or stencil layer) and COPs (Open In COPs builds the network).
Resize manifest: a JSON per texture file (current, target, action: resize, keep, repaint, unseen, unknown) with a shell script of the matching hoiiotool and iconvert commands. bin/texres_resize.py runs it with --execute, and the Texture Manifest Resize COP does it with nodes in Copernicus (pick an entry, see it resampled, write a .tx at the source's bit depth); sources are never modified.
Write Resized Textures: inside Houdini, no script. Files with a target below their size are resized; files at the right size but not tiled and mipmapped are converted; a UDIM set with any tile written is written whole. Everything lands as tiled, mipmapped .tx in a separate folder, pixel formats and color tags kept. Then texres_resized.usda, an over-only layer that points each material input at its new file (shaders inside native instances through a resized copy of their asset layer, so the instances stay instanced), to sublayer on the scene, or Use Resized Textures to have the node's own output read it while the analysis keeps reading the scene's own files.

Where to stop. For most shows the conversion to tiled, mipmapped .tx is the whole optimization: it is the memory lever (section 08), it changes no pixels and it needs no decision per asset. Resizing to the recommended sizes and splitting UDIM layouts by need are for the shows where network and disk are the constraint: a farm pulling every texture from a server, cloud nodes, a publish that has to stay small. The two steps stay apart: the manifest marks every file keep or resize, and the write step has a convert-only mode (every file keeps its size, only the untiled ones are converted), which is the C variant below.

Write Up-res Textures. The hero asset that ships a level short cannot be re-textured overnight, and a plain upscale adds nothing. The tool lays the detail a texture already holds one octave finer, measured against the real files: one level is honest, two is a stretch, three is a guess that still reads as the wall under the light. The method, the measurements and the whole alley from 1K are on their own page: Texture Up-res.

Three plaster walls under a raking light: the true 2K, the own-octave up-res of the 1K, a plain x2 upscale — The up-res in one frame: the true 2K, the own-octave up-res of the 1K, a plain ×2 upscale, under the same raking light

What it bought

The alley with 8K crates and cobblestone bound, content-aware on, three variants rendered with Karma at 3840 crops of the crates and of the cobblestone, each husk polled for peak working set, bytes read from files and GPU memory above the card's idle use.

Variant	Files	CPU peak RAM	CPU bytes read	XPU peak RAM	XPU GPU	XPU bytes read
A as shipped	109 untiled .jpg / .png, tiled 8K .rat	5.8 / 5.6 GB	1.98 / 2.48 GB	3.1 / 2.3 GB	+3.0 / +2.8 GB	2.61 / 1.44 GB
B tiled, same sizes	the 109 converted to tiled, mipmapped .tx	2.3 / 1.9 GB	0.62 / 0.80 GB	3.5 / 2.4 GB	+3.2 / +2.9 GB	1.46 / 1.31 GB
C tiled + recommended sizes	47 resized on top, all tiled .tx	2.3 / 1.9 GB	0.56 / 0.58 GB	3.3 / 2.3 GB	+3.2 / +2.8 GB	1.20 / 0.93 GB

crates / cobblestone close-ups. Times: CPU 42-51 s for every variant, XPU 6-9 s. Mean image difference against A: 0.003-0.004 on CPU, 0.0004-0.0019 on XPU. Repeated five times on the crates (demo/render_resized_compare.py --runs 5): CPU peak RAM A 5.78 GB (5.73 to 5.83), B 2.28 (2.27 to 2.29), C 2.25 (2.23 to 2.28); bytes read A 1.97 (1.94 to 2.03), B 0.62, C 0.57 (within 0.01); on XPU, GPU memory above idle A 3.03, B 3.22, C 3.22 (within 0.02), bytes read 2.22, 1.47, 1.22: the same numbers every time.

An 8K color map and its mip chain: what an untiled file costs against what a tiled one pages in — Why tiling is the memory lever: an untiled file makes Karma build the whole pyramid in memory when it loads; a tiled, mipmapped file pages in only the tiles of the levels the shot samples. An 8K file read at 1K costs about what a 1K file does.

A / B / C chart: CPU peak RAM, bytes read, XPU GPU memory — A / B / C on the crates close-up. Tiling: -60 % CPU peak, -70 % bytes read. Resizing tiled files: no further memory saving on either engine, 10-27 % fewer bytes read on CPU and 18-29 % on XPU.

The map is the deliverable. Tiling is the memory lever; resizing is the I/O lever, for the shows that need it. Karma XPU's memory was the same in all three variants: XPU converts every image it loads to its own tiled format (.rat), so files that are already tiled change little there, and tiling is a Karma CPU lever. The recommended sizes still cut the bytes each frame pulls from the texture server, size assets before they are painted, and catch the maps that are too small for a close-up. Disk only shrinks if the render set publishes the smaller files instead of the masters. One scene on one machine; a set that reads from a server would show whether the network saving holds up.

The single-asset experiment that preceded it (one crate in front of the camera needing its 8K level, 4,000 crates 20-200 m away needing ~256): a mipmapped 8K costs ~0.1 GB over an all-256 lower bound, near/far texture variants save nothing on CPU and cost +0.9 GB on XPU for the second prototype, and untiled files cost +0.8 GB for four 8K maps on both renderers. So the tool recommends one size per prototype and flags files that are not tiled and mipmapped; it does not recommend near/far variants.

What to take from it

Three lines: the minimum resolution map, tiled .tx as the memory lever, resizing for network and disk — The closing card of the video.

The minimum resolution map is the point. Per prim and UDIM tile, from the shot cameras: the brief before painting and the QC after. It catches the hero asset that ships a level or three short of what the close-up reads, which no amount of optimization fixes afterwards.
Tiled, mipmapped .tx is usually all the optimization a show needs. It is the memory lever on Karma CPU, it changes no pixels, and most pipelines do it already; the tool flags the files that are not render-ready.
Resizing and UDIM re-layouts are for the shows where network and disk are the constraint. They cut what every frame pulls from the texture server and what a publish weighs; they save no render memory once the files are tiled.

Every size is for the render width: 3840 here, the push-in at its own 1920. At HD throughout, one level less; the report lists every Report Width.

Limits of v1, and what is open

Instanced geometry: only N copies per prototype are traced, picked before any ray is cast (half by size, half spread out); a prototype whose traced copies are all hidden is estimated from the closest untraced copy, conservatively. Prototypes over the face budget are estimated, not traced, and get tile 1001 only. The Karma image engine does not handle instancing; use the ray engine.
The ray engine does not model subdivision, displacement, motion blur or depth of field; the image engine does. Neither models reflections or refractions (LPE AOVs in the image engine are the plan).
Geometry is taken at the current frame; cameras move, objects do not. A fast fly-by can pass closest between two sampled frames: lower Frame Step for such shots.
See-through surfaces in the ray engine: glass is measured and passed straight through (no refraction), alpha cut-outs are holes where their opacity map is under the cutoff; only UsdPreviewSurface, MaterialX standard_surface and OpenPBR materials are read, other shaders count as opaque. The image engine follows the renderer.
One reference resolution for all cameras; a camera with its own render width is measured at that width and its report sizes scale from it. Faces that straddle two UDIM tiles are assigned by their mean uv.
Open: a standalone version that loads USD outside Houdini (command line, report, manifest, heatmap layer). Not yet tried on a production show scene.

How it is built

input stage --> analyze (Python LOP) --> output
                   |
                   | reads geometry from
                   v
input stage --> ray_instances (Python LOP: instances thinned, PointInstancer copies) --> what the LOP Imports read
sopnet: import_meshes (LOP Import, purpose render) -> unpack -> visible_meshes -> face_ids (VEX) -> OUT_MESH
        import_occluders (Occluder Pattern) -> unpack -> visible -> occluders_only (pathid -1)
        OUT_MESH + occluders_only -> use_occluders -> OUT_TARGETS (what the rays hit)
        pixels (Python SOP: one point per sample pixel)
        camframes (Python SOP: one point per unique camera-frame, from the stage)
        rays (VEX: 1 ray per pixel per camera-frame, analytic differentials, max per prim+tile+shell) -> OUT_RESULT

One LOP HDA, built by a script that finds built-in node parameters by type and menu token rather than by name, so it survives Houdini releases. The ray engine is VEX; its numpy twin (raygen.reference_sample) is what the unit tests check against the analytic answer for a flat wall, and the two are kept in step. Aggregation, sizing, colors and USD authoring are Python; the pure modules (maths, colors, texture lookups, manifest, report, sheets, panel model) run without Houdini and are covered by unit tests.

Checks that run end to end in hython: the smoke test (synthetic wall, camera, RenderSettings, textures of known size, every number against the analytic answer), moving cameras (USD time samples, a keyframed Camera LOP both ways, a keyframed Transform LOP on a parent), occlusion (eight door/bin cases), texture space (UsdTransform2d, place2d, triplanar without uvs), instancing (native, PointInstancer with a million instances, class prims, the render-ready flag, the biggest copies hidden behind a wall), glass and alpha cut-outs, and the resized textures (UDIM set, .tx, layer, toggle, native instances through a resized copy of their asset layer). Karma is deterministic on this scene (A rendered twice: 0.0000), which is what makes the image-difference numbers above meaningful.

Houdini 22 (smoke test also green in 21.0.729). Demo assets are CC0 Poly Haven; the alley, the walkway, the shells, the projection and the occlusion scenes are built by scripts in demo/, so every figure on this page is reproducible from the repository.

Texture Resolution QC, October 2026. Houdini 22, Solaris, Karma CPU and XPU. Demo assets CC0 Poly Haven.