Texture resolution is where a project's memory budget mostly goes, and the decision is made per asset.
What decides it
- How close does the player get? The dominant factor.
- How much screen space does it occupy? A skybox and a coin need very different resolutions.
- What texel density are you targeting? Resolution follows from density and surface area, rather than being chosen independently.
- What can you afford? Total texture memory is a hard budget on most platforms.
Powers of two
Textures at power-of-two dimensions mip-map cleanly and compress with block formats. Non-power-of-two textures are supported and often handled worse — some formats will not compress them, which costs far more memory than the size saved.
Stick to powers of two unless you have a specific reason not to.
Mip-mapping
Pre-computed smaller versions, selected by distance. They cost about a third more memory and they are not optional — without them, distant textures shimmer badly as the sampler skips pixels. Always generate them for anything seen at varying distance.
Compression
Block compression reduces texture memory several-fold at some quality cost. Format depends on platform. The important point is that uncompressed textures are not a shipping option on any platform — the memory difference is too large.
Normal maps need a format that preserves their precision; using a colour-oriented format on a normal map produces visible banding.
Practical approach
Author high, ship down. Keep source textures at generous resolution and let the build pipeline produce the platform-appropriate size. That way raising quality later does not mean re-authoring.
Generated textures
Generated maps arrive at whatever the generator produced, which may be far above or below what the asset needs. Resample to your project's density rather than accepting the source size — and remember that upscaling a small generated texture adds pixels, not detail.