AI texture generator for Blender: getting PBR maps that survive a render

An AI texture generator is only useful if what comes out is a real PBR set. Mixar generates one onto the mesh you have selected: describe the material or hand it a photograph, and base colour, roughness, metallic and normal come back projected through the object's UVs with the material already wired. No node graph to assemble, no downloads folder, nothing to reconnect.

For context if Mixar is new to you: it is a 3D editor built on Blender, with the full Blender toolset and shortcuts intact, plus an AI agent and a layer-based texturing system built into the application itself. Windows, macOS and Linux.

The rest of this page is what makes a generated set correct rather than merely convincing, because that is what decides whether it survives a moving light.

What a PBR set actually needs#

Four channels do the load-bearing work in a metallic-roughness workflow, which is what Blender's Principled BSDF, Unreal, Unity and glTF all use:

Base Colour. The surface's albedo with no lighting information in it. No shadows, no highlights, no ambient occlusion multiplied in. This is the single most common failure in generated textures, because image models are trained on photographs, and photographs have lighting in them.

Roughness. How scattered the specular reflection is. 0 is a mirror, 1 is fully diffuse. Most real materials sit between 0.2 and 0.8, and the interesting part is the variation: fingerprints, wear patches, water marks, polish on the high points. A flat roughness value is what makes a material read as CG.

Metallic. Effectively binary in practice. A surface is a conductor or it is not. Values in between exist for transition regions and for blended materials, and using them as a general dial produces materials that are physically nonsense. Rust on steel is not 0.5 metallic; it is 0 metallic where the rust is and 1 where the steel is.

Normal. Surface detail too fine for geometry. Scratches, pores, weave, dents. Tangent space, and the green channel convention matters: Blender and OpenGL use +Y, DirectX and Unreal use -Y. A normal map with the wrong green channel produces lighting that looks subtly inverted, and it is a five-minute bug that costs an hour if you do not know to look for it.

Height, ambient occlusion and emissive are useful additions. They are not the core four, and ambient occlusion in particular is a map that has to be baked from your mesh rather than generated from a description. Which maps generate and which must be baked is the distinction that causes the most wasted effort in this whole area.

How generated maps go wrong#

Lighting baked into base colour. The generator produced something that looks like a photo of the material rather than the material. Test: load the base colour alone with roughness at 1 and metallic at 0, in flat lighting. If you can see where the light was coming from, the map is wrong.

Roughness derived from luminance. A shortcut where the roughness map is the base colour desaturated and inverted. It gives variation, and the variation is wrong: dark regions are not automatically rough. Wet dark asphalt is dark and smooth. Chalk is light and rough.

Normal maps that are flat. A generated normal map that is almost uniformly (128, 128, 255) is doing nothing. This happens when the generator had no real height information to derive from.

Seam mismatches. The map is generated in image space and applied through UVs. Across a UV seam, two points adjacent in 3D are far apart in 2D, and a generator with no knowledge of the layout will not make them match. This is why a deliberate unwrap that hides seams pays off twice: once in painting, once here.

Tiling that does not tile. For a repeating material the edges have to wrap. Many generators do not guarantee it, and the tell is a visible grid at grazing angles rather than an obvious seam.

Resolution mismatched to texel density. A 4K map on an asset with 200 px/m of texel density is wasted memory; a 1K map on 2000 px/m is mush. Decide density first, then pick the resolution that serves it, not the other way round.

Getting it right in Blender#

The mechanical sequence, whichever generator produced the maps:

1. Unwrap first. Texture quality is bounded by UV quality. Overlapping islands mean the same texture region is applied twice; stretched islands mean stretched detail; wildly uneven texel density means detail resolution changes across the model. See AI UV unwrapping in Blender.
2. Build the node setup. Four Image Texture nodes into the Principled BSDF: base colour into Base Color, roughness into Roughness, metallic into Metallic, and normal through a Normal Map node into Normal. The Normal Map node is not optional decoration: it converts tangent-space RGB into the vector the BSDF expects, and wiring the image straight into Normal produces a surface that looks faintly, unplaceably wrong.
3. Set colour spaces correctly. Base colour is sRGB. Roughness, metallic and normal are Non-Color. Getting this wrong is the second most common PBR bug after the green channel, and the symptom is a material that is subtly too shiny or too dark in a way that resists tweaking.
4. Check the normal map convention. If the surface lighting looks inverted, invert the green channel with a Separate Color and Combine Color pair, or an RGB Curves node with the G curve flipped.
5. Look at it in motion. Rotate the light. A material that only reads correctly from one angle has lighting baked into it.

Where the agent changes the job#

Steps 2, 3 and 4 above are pure mechanics: the same six nodes, the same colour space settings, the same convention check, every time, for every material, on every asset. There is nothing to decide. That is exactly the work worth briefing away.

In Mixar the PBR generation path takes the selected mesh, a material description or a reference image, and produces the four maps applied to the object with the material already wired. It needs UVs to project through, and if the mesh has none it runs Smart UV Project itself before submitting rather than refusing. That is a convenience, not a substitute: the quality of the result is bounded by the quality of the UVs it lands on, and a Smart UV Project layout is many small islands with many seams. Unwrap deliberately first and the generated maps are noticeably better. Generated maps can also come from a photograph: a close-up of a real material as input, with the four channels extracted from it.

Worth knowing what the stack above them can actually do, because "layer-based texturing" covers a wide range of implementations:

Layer types

17, including fill, paint, noise, voronoi, brick, checker, wave, gradient, gabor, edge detect and AO

Mask types

18, the same procedural set plus object index, colour ID, backface and modifier masks

Mask modifiers

Invert, Ramp, Curve

Blend modes

Mix, Add, Multiply, Subtract, Screen, Overlay

Projection

UV, tri-planar, planar, spherical, cylindrical, decal

Procedural library

91 materials: metal 40, stone 14, organic 10, plastic 9, leather 5, wood 5, ceramic 4, fabric 4

Tri-planar projection is the one worth calling out, because it is the escape hatch when the UVs are poor: it projects from three world axes and blends between them, so a mesh with a Smart UV Project layout can still take a convincing tiling material without a manual unwrap. It is also the right answer for a generated terrain, which arrives as a subdivided grid with no deliberate unwrap at all.

The maps then become a starting point rather than a final answer, which is the important part. Mixar's layer painting system takes them as fill layers, so the generated set is layer one and the wear, the edge damage, the dirt in the crevices and the hand-painted specifics stack on top. Procedural masks driven by baked mesh maps, ambient occlusion, curvature and cavity, make that stacking follow the actual geometry rather than being painted by eye.

The honest limit: a generator does not know what your asset is for. It does not know that this crate is set dressing at ten metres and that one is a hero prop the camera pushes into. It does not know your project's material conventions, and it will not match an existing library without being told to. Generated maps get you to a textured, plausible, physically correct starting point quickly. They do not get you to art direction.

When to generate and when to author#

Generate when: the material is a real-world surface with an obvious reference, the asset is one of forty, you are exploring options before committing, or you need a physically correct base to paint over.

Author when: the material carries story (this specific damage, this logo, this wear pattern that tells you how the object was used), it must match an existing library exactly, or the asset is close enough to camera that "plausible" is not the bar.

Most projects need both, and the split is usually eighty-twenty by asset count and the reverse by screen time.

Baking down#

Once the layer stack is right, it bakes to flat maps. Mixar bakes the full stack per channel and writes standard PBR textures as PNG, OpenEXR, TIFF or JPEG, which is what any modern renderer or engine consumes. Mesh export goes out as glTF, OBJ or FBX, with built-in setting presets for Unity, Unreal and Godot and the ability to save your own.

Two things to check on the way out. First, the texel density is consistent across the set, or the same asset will read as sharp in one region and soft in another. Second, the normal map convention matches the destination engine, because the export step is where that decision has to be made and it is the last chance to make it cheaply. More on the export side in Blender batch export prep, and on the passes before and after in the AI agent for Blender pillar.

Frequently asked questions

What is the best AI texture generator for Blender?

The useful question is not which generator but whether the output is a complete, correct PBR set: base colour with no lighting baked in, roughness that is not just inverted luminance, metallic that is effectively binary, and a normal map with real detail and the right green channel convention. A tool that produces four correct maps and applies them through your existing UVs will beat a better-looking base colour every time.

Can AI generate PBR textures?

Yes. Generating base colour, roughness, metallic and normal maps from a text description or a reference photograph is well established. What still requires attention is everything around it: the maps are projected through the mesh's UVs, so a deliberate unwrap beats an automatic one, the maps need the right colour space settings in the shader, and the normal map convention has to match the destination engine.

Why does my generated texture look flat or plastic?

Usually one of three things. The roughness map has no meaningful variation, so every part of the surface scatters light identically. The normal map is close to uniform and adds no detail. Or the roughness and metallic maps are loaded as sRGB instead of Non-Color, which shifts their values. Check all three before blaming the generator.

Do generated PBR textures work in Unreal and Unity?

Yes, provided they are exported as standard metallic-roughness maps. The one conversion to watch is the normal map green channel: Blender and OpenGL use +Y, Unreal and DirectX use -Y. If the surface lighting looks inverted after import, that is the cause, and inverting the green channel fixes it.

Can I generate PBR textures directly onto a mesh in Blender?

Yes. Mixar, a 3D editor built on Blender, takes the selected mesh plus a material description or a reference photograph and returns base colour, roughness, metallic and normal already projected through the object's UVs and wired into a material. If the mesh has no UVs it unwraps first rather than refusing, though a deliberate unwrap still produces a noticeably better result than the automatic one.