LOW POLY TEXTURES: WHEN TO USE THEM

I spent about six months of my early modeling career texturing every low poly thing I made. UV unwrapped each prop, painted little 256x256 textures, baked ambient occlusion onto the maps, the whole pipeline. Then I looked at my project folder one day and realized I had 400 megabytes of texture files for a game that could have shipped with maybe 30 kilobytes of vertex colors instead. The textures weren't even adding much. Most of them were just color, slightly grungier than a flat material would have been, doing nothing that justified the file size or the hours I'd burned making them.

That's when I started actually thinking about when a low poly model needs a texture and when it doesn't. The answer turns out to be "almost never, but the exceptions matter." Most of my work now uses no textures at all. The exceptions get one of four very specific texture types, and each one solves a problem that flat colors can't. If you're texturing every low poly model you make, you're probably wasting time and bloating your build for no visible gain.

The default should be no texture

Here's the rule I work by now: a low poly model gets flat colors via material assignments unless I have a specific reason to use a texture. The reason has to be visible in-game from normal viewing distance. If I can't immediately point to what the texture is doing that a flat color couldn't, I delete the texture and assign materials instead.

Flat materials are faster to set up, easier to tweak, lighter on memory, and they look correct on low poly geometry. The whole appeal of the low poly aesthetic comes from the interaction between flat color and flat shading. Each polygon is its own visible plane with its own light value, and the colors between polygons read as distinct surfaces. Adding a texture often muddies that effect because the texture introduces noise that competes with the geometric clarity.

I covered this in my low poly modeling guide, but it's worth restating because it's the single biggest mistake I see beginners make. They model a clean low poly chair, then slap a wood texture on it, and suddenly the chair looks worse. The grain pattern fights the polygon edges. The textured wood has implied detail that the geometry doesn't support. The whole thing reads as confused. A flat brown color on the same chair would look more intentional, more cohesive, and ship in a fraction of the file size.

So before talking about texture types, get this part: textures are the exception, not the default. If your workflow assumes every model needs UV unwrapping, you're working too hard.

Gradient textures, the Synty trick

The first texture type that actually earns its place is the gradient atlas. This is the technique Synty Studios popularized with their Polygon asset packs, and it's brilliant in its simplicity. You paint a single texture, usually 256x256 or 512x512, that contains a bunch of color gradients. Then you UV map every model in your scene to specific spots on that one texture. The whole game uses one texture file.

The gradient does two things at once. First, it gives surfaces subtle variation in lightness, so a wall isn't perfectly uniform brown but has slight tonal shift across its faces. Second, it lets you pull from a curated palette without managing dozens of individual materials. Need a slightly different green for the next prop? Move the UV island to a different spot on the gradient. Same texture file, different color, no extra memory.

The file size win is enormous. A typical Polygon-style game might have 500 unique props all sharing one 1MB texture. The atlas itself stays small because you don't need crisp detail, just smooth color transitions. And because every model uses the same texture, the GPU can batch draws aggressively. You get the visual variety of having lots of materials with the rendering cost of having one.

I use this approach for any project that needs a consistent stylized palette across many props. It's not the right choice when you want each model to feel handcrafted with its own voice, but for environment art at scale it's hard to beat. The texture itself can be made in Photoshop or GIMP in about ten minutes. Just lay out gradient strips in a grid, name the spots, and start UV mapping.

The trick that took me embarrassingly long to learn: keep the gradients vertical. UV map your faces as vertical thin slices. Then to change the value across a face, you stretch the UV vertically. To switch colors entirely, you slide the UV horizontally to a different gradient strip. This makes the texture intuitive to work with once you internalize the layout.

Pixel-style textures and the PS1 look

The second texture type that works on low poly is pixel art textures used PS1-style. This is a very specific aesthetic and you either want it or you don't, but when you want it, nothing else will do.

The PS1 era forced developers to make tiny low-resolution textures because the hardware couldn't handle anything bigger. 64x64 was common. 128x128 was luxurious. The textures were pixelated, often hand-painted with limited palettes, and they wrapped onto chunky low poly models with affine texture warping that gave everything that distinctive wobbly perspective. It looked rough then. It looks intentional now, because that aesthetic became its own thing.

If you're going for retro horror, indie throwback, or anything with PS1 vibes, pixel textures on low poly geometry is the move. You're not trying to hide the texture's resolution. You're celebrating it. Use point filtering instead of bilinear so the pixels stay crisp. Keep the textures small, like actually small, 64x64 or 128x128. Hand paint them with limited colors. Don't bake any modern detail in. The texture should look like someone made it in 1996.

This works because the texture and the geometry are speaking the same visual language. Both are low fidelity. Both have visible structure. The pixel grid of the texture and the polygon grid of the model reinforce each other. You get a unified retro look that high resolution textures on the same model would completely break.

The trade-off is that pixel textures take more skill to make than gradient atlases. You're hand-painting at low resolution, which is its own discipline. Bad pixel art looks much worse than a bad gradient. But when it works, it works in a way nothing else can replicate.

Vertex colors, the no-texture alternative

This is my favorite technique and the one I default to for anything that doesn't need a specific texture treatment. Vertex colors let you paint color information directly onto the mesh, stored per vertex, with no texture file needed at all.

In Blender, you create a vertex color layer and use the vertex paint mode to paint colors onto your model. In Unity or Godot, you use a shader that reads vertex color and outputs it as the surface color. That's it. No UV unwrapping. No texture files. No texture memory usage. The color information lives in the mesh data itself, which is tiny because you only need one color per vertex.

For per-face color rather than per-vertex, you have a couple of options. You can split the mesh edges so each face has its own vertices, then paint each set of vertices a single color. This gives you the flat per-face look that vertex colors are usually associated with. Or you can use a shader that flat-shades the vertex colors, picking one vertex's color per face. Both work. I usually split the edges because it's more predictable and lets me tweak individual face colors without affecting neighbors.

The advantages stack up fast. File size is essentially nothing extra. A model with vertex colors might be 5% bigger than the same model without colors, versus 100x bigger if you added even a small texture. Iteration is instant. Want to change a color? Paint over it. No texture export, no UV adjustments, no atlas updates. Performance is great because there's no texture sample, just a vertex attribute lookup. And the look is pure low poly because there's no texture noise interfering with the polygon clarity.

The downside is you can't have any variation within a face. A vertex-colored face is one color, end of story. If you need patterns, decals, or any kind of surface detail, you need a texture. But for the 80% of low poly models that just need clean color blocks, vertex colors are perfect.

This is how a lot of the work for our polylusion art style gets handled. Most of our props are vertex colored. The build is small, iteration is fast, and the aesthetic stays pure.

Palette textures as a middle ground

The third real texture technique is the palette texture, which sits between vertex colors and gradient atlases. You make one tiny image, often as small as 16x16 or 32x32, with all the colors your scene will use arranged as solid color blocks. Then you UV map every face to a single pixel on that texture.

This sounds redundant compared to vertex colors, but it has one big advantage: you can swap the entire palette by swapping one tiny texture. Want to do a night version of your scene? Make a new 32x32 palette with cooler tones, swap the texture reference, every model in the scene shifts color. Want to do a damaged or burned variant? Same trick.

You also get the GPU batching benefit since every model uses the same tiny texture. The memory cost is negligible. A 32x32 texture is about 4KB, which is rounding error in any modern game. And the look stays clean because you're sampling solid color blocks, no gradients, no noise, just flat color picked from a palette.

I use palette textures when I know I'll want to recolor scenes for different times of day, story states, or biomes. They give you a single point of control for the entire visual palette of your game, which is incredibly powerful for stylized work. The trade-off versus vertex colors is that you have to UV map, even if it's just clicking each face onto a single pixel. That's more work upfront but pays off if you want palette flexibility.

When realistic textures break the look

Now for the failure mode. Realistic textures on low poly geometry almost always look bad. I'm talking about the kind of textures you'd download from a PBR library, with detailed albedo maps, normal maps, roughness, the works. People try this thinking they'll get the best of both worlds, low poly performance with realistic surface detail. They get neither.

The problem is a mismatch in implied detail. A realistic wood texture has thousands of fibers, knots, grain variation, surface scratches. It implies the surface is detailed and complex. Then your geometry shows up as four flat polygons making a plank shape, and the visual contract is broken. The texture is promising detail the geometry isn't delivering. The viewer's eye keeps trying to reconcile the two and failing.

You also lose the lighting interplay. Flat shaded low poly geometry catches light in a specific way, with each polygon getting its own clear light value. Realistic textures with normal maps try to fake surface variation that the geometry doesn't have, and the result fights with the actual flat shading. Highlights end up in weird places. The whole thing looks broken.

If you must add detail to a low poly surface, do it with simple painted textures that match the visual fidelity of the geometry. A hand-painted plank texture with stylized grain that reads from a distance, no normal maps, no PBR. Or skip the texture entirely and add the detail with extra geometry, an actual recessed line for a plank gap rather than a fake one in a normal map. The geometry-based approach is more polygons, but they're polygons doing visible work, which is the whole point of low poly modeling.

Practical Blender to Unity workflow

Here's how I actually do this in practice. In Blender, I model the prop with flat shading and create vertex color layers for anything that doesn't need a texture. I use vertex paint mode for broad color blocks, then switch to face select with split edges when I need crisp per-face colors. I export to FBX with vertex colors enabled in the export settings, which is a checkbox most people miss.

For models that do need textures, I either UV map to a shared gradient atlas or assign a single pixel on a palette texture. I keep one Blender file open with the master atlas as a reference image, and I UV map directly against that. Naming UV islands by what gradient they're using helps when I come back later and need to recolor things.

In Unity, I use a custom shader for vertex colors because the default standard shader doesn't read them. The shader is about ten lines of code. Just sample the vertex color attribute and output it as the base color, with optional flat shading via screen space derivatives. There are free vertex color shaders on the asset store if you don't want to write one, but writing your own takes about fifteen minutes and gives you full control.

For the textured models, I drop them into the same scene with a shared material that points to the atlas. Unity batches all of them into single draw calls, which keeps performance silly fast even with hundreds of props onscreen. Combined with the vertex colored models that don't need any texture sampling at all, you can fill a scene with thousands of objects and barely move the GPU.

I went deeper on the rendering side in my piece on smooth lighting for low poly in Unity, which covers how to make these flat-colored surfaces actually look good under dynamic light.

When I reach for what

The decision tree I use in my own work. Default to vertex colors for everything. They're fast, small, and they look right. Switch to a gradient atlas when you have a large scene with many props and want unified color variation across all of them. Use a palette texture when you want to swap palettes for different scene states, day and night, biomes, story progression. Use pixel-style textures only when you're committing to a PS1 retro aesthetic. Avoid realistic textures entirely unless you've left the low poly aesthetic behind for something else.

The mistake I made for six months was assuming every model needed a texture because that's how 3D work usually goes. Low poly is different. Pick the lightest tool that solves your actual problem. Most of the time, that's no texture at all.