AI map generator: which texture maps can be generated, and which must be baked

This is about texture maps: the base colour, roughness, metallic, normal and mask channels that make a surface read correctly under light. If you arrived looking for AI level or terrain map generation, this is not that, and the rest of the page will not help.

Still here? Then the short version is that Mixar generates the material maps onto your selected mesh and bakes the geometry-derived ones from it, which are two different operations that get confused constantly. (Mixar is a 3D editor built on Blender: same toolset and shortcuts, with an AI agent and a layer-based texturing system built into the application.)

With that out of the way: "AI map generator" covers two genuinely different operations that get discussed as though they were one, and confusing them is the source of most bad results. Some maps are generated from a description or a photograph. Others are baked from the geometry itself and cannot be generated at all, because the information they encode lives in the mesh rather than in any image.

Knowing which is which is the whole skill.

The two kinds of map#

Generated maps describe a material. What colour is this surface, how rough, is it metal, what fine surface relief does it have. This information comes from the material's nature and can reasonably be inferred from a description ("worn brass, lightly polished") or extracted from a photograph of the real thing.

Baked maps describe a mesh. Where does this surface occlude itself, where are its convex edges and concave crevices, how thick is it, where would dust settle on it. This information exists only in the geometry. No amount of describing the material produces it, because it is not a property of the material.

The failure this prevents: asking a generator for "an ambient occlusion map" of a material. You will get an image that looks like ambient occlusion and it will correspond to nothing about your mesh. It will darken the wrong places, and it will look subtly wrong in a way that is hard to diagnose because the map itself looks plausible.

What generates well#

The core PBR set generates reliably from a text description or a reference photograph.

Base colour. The albedo, with no lighting in it. Loads as sRGB in the Image Texture node; everything else on this list loads as Non-Color. This is the single most common defect in generated and photographed maps alike: shadow and highlight from the source get baked in, and then every light in your scene fights a light that is already painted on.

The ten-second test: plug base colour alone into an Emission shader, or set Roughness to 1.0 and Metallic to 0.0 under flat lighting. If you can tell where the light was coming from, the map is wrong.

Roughness. Most real surfaces live between 0.2 and 0.8; values below 0.1 are mirror-polished and above 0.9 are chalk. The variation matters more than the average, and a flat roughness value is the single biggest reason a material reads as CG. Watch for roughness that is the base colour desaturated and inverted, a common shortcut that breaks the moment the light moves: wet asphalt is dark and smooth, chalk is light and rough.

Metallic. Effectively binary. A surface is a conductor or it is not, and the in-between values exist for transition pixels, not as a dial. Rust on steel is 0 where the rust is and 1 where the steel is, never 0.5 across the whole map.

Normal. Tangent space, and the green channel convention decides whether it works: Blender and OpenGL are +Y, Unreal and DirectX are -Y. Inverted-looking lighting after an import is almost always this, and the fix is a Separate Color into Combine Color with G inverted, or an RGB Curves node with the G curve flipped. A generated normal map sitting near uniform (128, 128, 255) is contributing nothing.

Height, ambient occlusion and emissive where the material genuinely has them. Mixar's paint channels are Base Color, Roughness, Metallic and Normal by default, with Height, AO and Emissive addable per material.

Generating from a photograph is often better than generating from a description when the material is a real one. A close-up of the actual surface, shot flat and evenly lit, gives the extraction something concrete to work from.

What must be baked#

These come out of your mesh, in a render pass, and they are the inputs that make a texture stack follow the actual object rather than sitting on top of it. In stock Blender that pass is Cycles baking, which is worth reading once if only to see that the bake types are a fixed list rather than something a generator could substitute for.

Mixar ships sixteen, and the names are worth knowing because they map directly onto what each one is good for as a mask:

Pointiness is the one to reach for first. It gives convexity and concavity in a single map, which covers both edge wear and crevice dirt, and it is the mask most wear-focused stacks are built on.

Two practical notes. These bake through Cycles, so Cycles must be enabled or the bake reports an error rather than failing silently. And they belong as mask inputs in the layer stack, not as final textures: an ambient occlusion map multiplied into base colour is the classic mistake, because it bakes lighting into albedo, which is the defect this article opened on.

Putting them together#

The generated set is layer one. The baked maps drive what goes on top.

1. Unwrap deliberately. Every map is projected through the UVs, so the layout bounds the ceiling on all of it. Mixar's PBR generation will run Smart UV Project itself if the mesh has no UVs at all, which stops the operation failing but is not a substitute for unwrapping properly. AI UV unwrapping covers the difference.
2. Bake the mesh maps. Ambient occlusion, curvature and cavity at minimum. Automating baking in Blender covers cages, ray distance and the ordering.
3. Generate the base material from a description or a photograph, and apply it as the bottom fill layer.
4. Stack the story on top. Edge wear masked by curvature, grime masked by inverted ambient occlusion, dust masked by the dust bake. Now the wear follows the object's actual form instead of being painted by eye.
5. Check under a moving light. Rotate a light source. A material that only reads correctly from one angle has lighting baked into it somewhere.
6. Export. Standard PBR maps as PNG, OpenEXR, TIFF or JPEG, with the normal green channel set for the destination engine.

Steps 1, 2 and 6 are mechanical and identical every time, which makes them the parts worth briefing to an AI agent for Blender rather than performing per asset.

The diagnostic checklist#

When a generated material looks wrong and you cannot say why, check in this order:

Six checks, most of them ten seconds, and between them they account for the large majority of "the generator produced something bad" reports. More on the texturing side in the AI texture generator guide.

Frequently asked questions

What is an AI map generator?

In texturing, it is a tool that produces PBR texture maps from a text description or a reference photograph: base colour, roughness, metallic and normal, sometimes with height, ambient occlusion and emissive. It is worth separating from mesh map baking, which produces ambient occlusion, curvature, cavity and similar maps from the geometry itself. Generated maps describe a material; baked maps describe your mesh, and no generator can produce the second kind because that information is not in any image.

Can AI generate a normal map?

Yes, for fine surface relief that is a property of the material, such as the grain in leather or the pitting in cast metal. What it cannot generate is a normal map of your specific mesh's detail, which is a bake from a high-poly version of that mesh. Two checks on any generated normal map: that it carries genuine detail rather than an emboss of the base colour, and that its green channel convention matches the destination engine.

Which texture maps have to be baked rather than generated?

Anything encoding geometry: ambient occlusion, curvature or pointiness, cavity, dust, thickness, position, object-space normal, and high-to-low detail transfers. These describe how your mesh occludes and curves, so they can only come from a render pass over the actual mesh. They are best used as mask inputs driving where wear and grime appear rather than as final textures in their own right.

Why does my generated material look flat or plastic?

Because a channel that should vary does not, and there are only a few candidates. Test them in isolation rather than guessing: view the roughness map on its own and see whether it has real structure or is one grey value with noise on it; set the normal strength to zero and see whether anything changes, because if it does not the normal map is carrying nothing; and check the colour space on roughness and metallic, since loading either as sRGB shifts every value in it. The fourth candidate is lighting baked into the base colour, which is a different failure and looks like it under a moving light.

Can I generate and bake texture maps in the same application?

Yes, and keeping them together matters because the two kinds of map feed each other: the baked mesh maps drive where wear appears on top of the generated material. Mixar, a 3D editor built on Blender, generates the PBR set onto a selected mesh and bakes the sixteen geometry-derived maps from that same mesh, so the masks and the material stay in one file rather than being reconciled across two tools.