Material Workflow

How to Create PBR Textures: A Production Workflow from Source to Engine

Create a PBR texture by preparing a neutral, tile-safe source; deriving a coordinated map set; reviewing each channel as data and as a lit material; validating dimensions, normals, seams, and classifications; then exporting with the destination engine’s color-space, normal, and packing conventions.

Intermediate Environment artistsGame developersMaterial artists Published

Release notes

What changed?

  • : Evergreen workflow created Moved the permanent source-to-engine process out of the blog and separated it from the product manual and technical overview.

Direct answer

How do you create a game-ready PBR texture?

Use an image-derived workflow when the visible source contains enough surface evidence and speed matters. Author or bake the maps from geometry and measured references when silhouette, hidden depth, exact roughness, or physically measured material response is critical.

Use PLAYTEX AI for the coordinated middle of the workflow: Image to Texture Generator prepares an existing photo or surface image. PBR Map Generator derives and exposes the aligned material channels. The validator and focused checkers provide evidence before export. The product guide documents specific controls; this page owns the broader production process.

What you will get

  • Turn a photo, scan, render, or generated image into a controlled material source.
  • Create a coherent PBR map stack without confusing derived estimates with measured truth.
  • Catch seams, wrong color spaces, inverted normals, and packing errors before engine import.
  • Package and test the material for a specific renderer rather than exporting a generic ZIP blindly.

Best use cases

  • Building a tileable brick, stone, wood, fabric, soil, plaster, or metal surface from a photo.
  • Turning approved concept imagery into a first-pass game material for iteration.
  • Rebuilding an inconsistent material set from one clean source image.
  • Preparing a material for Blender, Unity, Unreal Engine, Roblox, Three.js, or glTF delivery.

Acceptance test

Approve the asset only when these are true

  • Start from a front-facing, evenly exposed source with recoverable detail.
  • Remove baked illumination and prove the source tiles before map generation.
  • Generate every required channel from the same approved source and UV layout.
  • Review flat maps and a moving-light 3D preview; neither view is sufficient alone.
  • Validate dimensions, normal vectors, scalar-map behavior, seams, and target conventions.
  • Export only required maps with explicit names, color spaces, orientation, and packing.
  • Test the imported material at real texel density, lighting, distance, and device quality.

Correct the earliest responsible stage

When a final material fails, trace the problem backward. A visible repeat belongs in source tiling. A fixed shadow belongs in delighting. An inverted bump belongs in normal orientation. A plastic-looking metal belongs in metallic classification or roughness response. A blurry mobile result may belong in the resolution and compression plan.

Correcting the earliest responsible stage keeps the material coherent. Painting over the symptom in one downstream map often creates a second mismatch elsewhere in the stack.

Keep source, authored maps, and delivery maps separate

Preserve the approved source and readable individual maps as working assets. Create packed textures, resized variants, or platform compression as delivery derivatives. This separation makes later corrections, engine changes, and audits much easier.

Record the physical tile scale, intended shader, normal convention, color-space settings, and packing layout beside the asset so another artist or build system can reproduce the import.

Settings Reference

Source preparation decisions

A clean source prevents the same error from appearing in every downstream channel.

  • Perspective and crop: Defines the usable surface plane and removes geometry or context that should not repeat. Correct it before tiling whenever mortar lines, boards, panels, or weave directions converge.
  • Delighting: Reduces broad captured shadows and highlights so scene lighting can control them later. Use it when the source has a fixed light direction, then compare relighting and color preservation rather than trusting one corrected thumbnail.
  • Tile scale: Sets the physical area represented by one repeat and determines apparent texel density. Choose it from the real material and expected viewing distance before sharpening or generating high-frequency detail.

Map-generation decisions

Treat generated channels as a starting model that needs material-aware review.

  • Normal strength: Changes the apparent slope of small surface detail under lighting. Tune it in 3D at intended scale; reduce it when edges look inflated or noisy.
  • Roughness range: Controls highlight width and reflection clarity across the surface. Match known material classes and inspect moving reflections instead of maximizing grayscale contrast.
  • Metallic classification: Separates conductor and dielectric regions. Use material knowledge; brightness in a photo is not proof that a region is metal.
  • AO, height, and emission: Adds conditional cavity, relief, or self-lit information. Enable each only when the surface and destination shader justify it, then keep the effect restrained and testable.

Delivery decisions

Engine configuration determines whether correct source maps render correctly.

  • Color space: Controls whether texture values are gamma-decoded as visible color or preserved as linear data. Use sRGB for base color and emissive color; use linear for normals, masks, height, AO, metallic, roughness, and packed data.
  • Normal orientation: Defines the tangent-space Y direction stored in the green channel. Match the renderer’s OpenGL or DirectX convention whenever bumps appear inverted along one axis.
  • Resolution and compression: Controls memory, download size, mip behavior, artifacts, and retained detail. Choose it from real screen coverage and target hardware; do not preserve 4K files when the asset never resolves that detail.

Source-to-engine PBR workflow

Create a PBR texture by preparing a neutral, tile-safe source; deriving a coordinated map set; reviewing each channel as data and as a lit material; validating dimensions, normals, seams, and classifications; then exporting with the destination engine’s color-space, normal, and packing conventions.

Step 1: Define the material and target renderer

Record the real material classes, intended scale, camera distance, shader inputs, normal convention, packing layout, and memory budget. These decisions determine which maps and resolutions are useful.

Step 2: Capture or choose a usable source

Prefer a front-facing surface with even exposure, limited glare, recoverable shadows, sufficient detail, and no dominant object that will become obvious repetition.

Review the photo workflow

Step 3: Clean perspective and baked lighting

Crop to the useful surface, correct perspective, neutralize broad illumination, remove transient objects, and preserve real material color before deriving technical maps.

Prepare the source image

Step 4: Make and verify the repeat

Offset or synthesize a tile, repair both axes, inspect a repeated field, and measure edge continuity. Avoid solving only the outermost pixel row while leaving obvious low-frequency repetition.

Make an existing texture seamless

Step 5: Generate a coordinated map stack

Derive base color, normal, roughness, metallic, AO, height, and emission from the same approved source. Disable channels the material or shader does not need.

Open PBR Map Generator

Step 6: Review, validate, and correct

Inspect each map at full resolution, rotate the material under neutral lighting, validate the set, and correct the earliest source or parameter responsible for each failure.

Validate the material set

Step 7: Package for the engine

Apply explicit suffixes, color-space rules, normal orientation, resolution, compression, and channel packing for the destination renderer. Keep a readable source set beside any packed delivery textures.

Step 8: Test in the shipping context

Inspect the material at real scale and camera distance under representative lighting, graphics quality, compression, mip levels, and target devices. Record the approved settings with the asset.

Common Pitfalls

  • Generating maps before removing captured lighting or proving the source repeats.
  • Assuming a single image contains measured roughness, metalness, hidden height, or ambient occlusion.
  • Making every map independently and allowing dimensions, seams, or features to drift out of alignment.
  • Using extreme normal, AO, height, or emission values because the flat map looks more dramatic.
  • Exporting a generic package without matching the destination color-space, normal, and packing rules.
  • Approving the material only in one preview instead of testing real lighting, scale, compression, and devices.

Can I create PBR textures from one photo?

Yes, one photo can be a useful authoring source after perspective, lighting, and seam cleanup. The derived technical maps are estimates, so validate them with material knowledge and a lit preview.

What maps should I generate first?

Start with a clean base color, normal, and roughness. Add metallic, AO, height, emission, and opacity only when the material and destination shader need them.

Should I make the texture seamless before generating PBR maps?

Usually yes. Building all maps from one approved seamless source helps keep borders and features aligned. Validate the final channels because processing can still alter edge behavior.

How do I know whether a PBR texture is game-ready?

It must survive three checks: the source and seams are clean, the maps contain coherent data, and the imported material works under target-engine lighting, scale, compression, mip levels, and device constraints.

Is this the PBR Map Generator manual?

No. This guide owns the complete production workflow. The PBR Map Generator guide documents the product controls, while the technical overview documents algorithms, outputs, and limitations.