
Most people judge a render by its lighting, its framing, or its color grade. Almost nobody consciously notices a roughness map. And yet roughness is the single channel that most often separates a shot that reads as footage from a shot that reads as a demo.
Roughness is the grayscale channel in a physically based rendering (PBR) material that describes how micro-detailed a surface is at a scale smaller than a pixel. A value near zero means the surface behaves like a mirror: light bounces off in a tight, bright, sharply defined highlight. A value near one means the surface scatters light in every direction: the highlight spreads out, dims, and effectively disappears into diffuse shading. Everything interesting happens in between, and the in-between is where realism lives.
Consider a few ordinary materials and their typical roughness ranges:
Two renders with identical geometry, identical albedo, and identical normal maps can look like completely different materials if the roughness differs by 0.2. Get it right and a synthetic shot feels grounded in physical reality. Get it wrong and your metal looks like painted plastic, your skin looks like wax, and your concrete looks like felt.
The problem is that general-purpose AI video generators synthesize plausible pixels rather than simulating light transport. They do not have an explicit roughness value to be wrong about, which is exactly the danger. Instead they hallucinate a specular response frame by frame. Sometimes that hallucination is stable. Often it is not, and the highlight crawls across the surface, breathes in and out, or flips between glossy and flat within a single shot. The human visual system is remarkably sensitive to that kind of inconsistency, even when the viewer cannot name what is bothering them.
An offline roughness pass fixes this at the source. You derive a material dataset once, with real numbers, at full precision, and then every downstream render, relight, or compositing stage inherits the same physically coherent answer. Determinism is the whole point.
Before choosing a tool, it helps to understand what the tool is probably doing. Almost every AI-assisted roughness workflow is built from a small set of components that get chained together.
The output is a roughness proxy: a grayscale field that is usually 80 percent correct, with the remaining 20 percent concentrated exactly where it matters most.
There is also a structural limitation nobody escapes: if your plate has baked-in lighting, no model can fully separate surface roughness from lighting softness. A soft box produces a broad highlight on a smooth surface; a hard point source produces a tight one on a rough surface. Without additional information, both cases look identical to an estimator.
Running the pass offline gives you reproducibility, reviewability, and control. You can inspect the map, paint corrections, re-run a specific shot without touching the rest, store 16-bit or 32-bit float precision, and hand the same asset to a render farm months later and get the same result. On-the-fly inference inside a video model offers none of these guarantees. It is convenient, and it is fine for social-first content, but it is the wrong architecture for anything that needs to hold up on a large screen.
This is a practical sequence that works whether your source plates come from a camera, an AI video generator, or a mix of both.
Conform every shot to a single working color space, typically linear with a defined gamut. Convert frame sequences to a lossless or near-lossless intermediate format, and strip any display transform before analysis. If the footage is 8-bit h.264 from a phone, do a temporal denoise pass first. Compression artifacts read as fine surface detail to an estimator and will add speckle to the roughness map that has no basis in reality.
Roughness priors are material-specific, so a single global pass is almost always worse than a segmented one. Build a simple mask hierarchy: skin, metal, glass, fabric, vegetation, ground, sky, and a catch-all. Coarse masks are enough. Even rough mattes improve the result dramatically because the estimator stops averaging chrome reflections into the concrete floor.
Run the decomposition per mask region rather than per frame. Output each channel as a separate grayscale or color image: albedo, normal, roughness, metallic, height or displacement, and ambient occlusion where useful. Keep everything at the original resolution. Do not downsample the roughness map to save disk space; roughness detail survives resizing far worse than albedo does.
The artist pass is not optional. It is where the final 20 percent of quality comes from. In practice the corrections fall into predictable categories:
Never approve a roughness map by looking at the map itself. It is meaningless in isolation. Put it into a simple test scene and light it several ways: one hard key light, one large area light, one rim light at a grazing angle. If the material holds up under all three, it is ready. If the highlight explodes or vanishes between setups, the roughness range is too narrow or too wide.
Export with a consistent naming convention, generate mip chains, write a manifest with checksums, and store the project alongside the exact tool version and parameters used. When someone asks three months later why a shot looks different, the answer should be in the manifest rather than in someone's memory.
A simple batch script that walks a directory, runs the decomposition with fixed parameters, writes EXR sequences, and logs per-shot statistics will save more time than any single model upgrade. Frame sequences, EXR containers, headless command-line processing, and a job queue are all you need. Keep the pipeline idempotent so a re-run produces identical bytes.
Roughness data is small per pixel and enormous in aggregate. A 4K UDIM-based character with twenty tiles of half-float EXR channels can easily exceed a terabyte once normals, albedo, and displacement are included. Planning for that upfront avoids painful migrations later.
A few practical guidelines:
There is no universally best method. There is only the method that matches your shot count, your deadline, and your tolerance for imperfection.
Manual painting gives the most control and the best result on hero assets. It is also the slowest and depends entirely on the artist's material knowledge. Use it for close-ups where the surface occupies a large portion of the frame.
Procedural generation uses noise, masks, curvature, and geometry-driven blends. It is extremely fast, fully deterministic, and scales to thousands of assets. It struggles when the source is footage rather than geometry, because it has no idea what the real surface looks like.
AI-assisted decomposition is the pragmatic middle. It gets you to a plausible result in minutes instead of hours, and it handles the tedious per-pixel work that would otherwise consume a junior artist's entire week. It needs an artist pass, but the pass is targeted rather than exhaustive.
For most productions the winning combination is procedural base layers driven by geometry, AI decomposition for photogrammetry and live-action plates, and manual painting reserved for hero close-ups. Mixing methods per asset is normal and expected.
These come up again and again in review, and each one costs a full render cycle to discover.
Treating roughness as the mathematical inverse of gloss. A gloss map maps to roughness with a nonlinear curve, not a simple inversion. Inverting an sRGB-encoded gloss map and feeding it in as roughness produces a surface that is simultaneously too shiny in shadows and too dull in highlights.
Ignoring color space. Roughness is a data channel and belongs in linear, non-color space. Running it through an sRGB transform darkens the midtones and quietly makes everything glossier.
Baking lighting into albedo. The single most common error in AI-derived material sets. It looks acceptable in the current lighting setup and falls apart the moment anyone relights the shot.
Letting codec noise become surface detail. Denoise before decomposition, not after.
Skipping temporal consistency. A roughness map that shifts slightly between frames produces a shimmering specular highlight. It is subtle on a phone and unbearable on a cinema screen.
Using a metallic workflow map in a specular workflow. The maps are not interchangeable, and the failure mode is a surface that absorbs light instead of reflecting it.
Approving maps in isolation. A roughness map viewed as a grayscale image tells you almost nothing. Always review in context.
Forgetting wear and variation. Perfectly uniform roughness reads as CGI regardless of how technically accurate the value is.
Run this list on every shot that contains a distinctive surface.
If any answer is no, fix it before the render, not after the compositor.
Material derivation is a middle stage, not a standalone task. In a modern hybrid pipeline it usually sits between generation and finishing.
A common pattern looks like this: generate or shoot the plate, conform and denoise, decompose into PBR channels, repair the maps, render test lights, then hand the dataset to the compositor for integration with live-action elements. If the shot also contains AI-generated inserts, the same material dataset can be reused so that the synthetic element and the practical element share a consistent physical response. That shared response is what makes a composite believable, far more than edge quality or motion blur.
The same logic applies to virtual production. When your background is an LED wall and your foreground is real, matching roughness across the boundary is what prevents the seam from becoming visible when the camera moves and the parallax shifts the highlight.
And it applies in reverse: if you are generating video with an AI model and want to relight or extend it later, having a PBR dataset makes that extension possible. Without one, you are locked into whatever lighting the model happened to produce.
Yes, and the result is often surprisingly usable. Single-frame estimation is fast and good enough for background assets, distant surfaces, and any shot where the material occupies a small portion of frame. It becomes unreliable when the surface fills the screen, when lighting is ambiguous, or when the material is transparent or anisotropic. For hero assets, always estimate over a sequence rather than a single frame.
On a clean, well-lit plate with a single dominant material, maybe 10 to 15 percent. On a complex plate with chrome, glass, and skin in the same frame, it can easily be 40 percent. The good news is that corrections cluster in predictable regions, so the pass gets faster with experience.
It helps considerably. Normals tell you where curvature and edges are, which prevents the estimator from painting roughness detail onto perfectly flat regions. If you only have an image, you can derive approximate normals from the shading, but the result is noisier.
Match or exceed the resolution of the albedo for the same surface, and never go below the expected on-screen texel density. Roughness errors are more visible than albedo errors because they move with the camera as the highlight sweeps across the surface.
It works, but quality drops sharply. Compression noise in 8-bit footage is read as surface micro-detail, which produces busy, speckled roughness maps. Denoise temporally, upscale to 16-bit intermediates, and accept that fine detail will need manual reconstruction.
Anchor the estimate to a reference frame, propagate it forward and backward with optical flow, and then review the result as a scrubbing video rather than as individual stills. Any per-frame flicker you can see while scrubbing will be visible in the final render.
Only if the material and its lighting-independent properties are genuinely the same. Reusing a concrete floor map across two shots is usually fine. Reusing a skin map across two different actors is not, because subsurface behavior and pore structure differ.
Separating material classification from roughness estimation and running the pass per region instead of globally. It costs a little setup time and produces a dramatic quality jump on any shot with more than two distinct materials in frame.

Alexander
Vidu Q4 alternatives compared: Kling 4.0, Seedance 2.5, Wan 3.0, and Runway Gen-4 — 4K support, input modes, durations, audio, and what each costs in credits on Domer.
The top 4K AI image generators on Domer compared: Flux 3 Klein, Nano Banana 2.1, GPT Image 2.5, GPT Image 2, and Nano Banana Pro — 4K credit costs, reference limits, and speed.
Nano Banana 2.1 vs GPT Image 2.5 Flare compared: credit costs per resolution, aspect ratios, reference images, text rendering, and which tasks fit each model.