Why Use Power-of-Two Textures in glTF Files?

Power-of-two (POT) texture sizing—using pixel dimensions that are powers of two, such as 512×512, 1024×1024, or 2048×2048—is a fundamental standard in real-time 3D rendering. When embedding or referencing textures within glTF (GL Transmission Format) files, adhering to POT dimensions ensures broad hardware compatibility, optimal memory utilization, full support for mipmapping, and seamless integration with GPU-native texture compression formats.

Hardware and WebGL Compatibility

The glTF format is widely adopted as the "JPEG of 3D," frequently delivered over the web using WebGL and WebGPU runtimes like Three.js, Babylon.js, or Model Viewer. While modern desktop GPUs can handle non-power-of-two (NPOT) textures, older hardware and legacy APIs such as WebGL 1.0 place strict constraints on them. In WebGL 1.0, NPOT textures cannot use repeat-wrapping modes (wrap-s and wrap-t set to REPEAT or MIRRORED_REPEAT) and cannot utilize full mipmapping. When an engine encounters an NPOT texture under these constraints, it must either disable wrapping and filtering or dynamically resize the texture on the CPU, causing runtime performance hitches and increased loading times.

Efficient Mipmap Generation

Mipmaps are pre-calculated, progressively downscaled versions of a texture used to improve rendering performance and eliminate aliasing artifacts on distant surfaces. Because each mip level reduces the image dimensions by half (e.g., 1024 to 512, then 256, down to 1×1), POT dimensions divide evenly down to a single pixel. NPOT dimensions, such as 1000×600, require rounding at fractional divisions, which complicates mipmap generation, introduces visual artifacts, and demands extra processing overhead during asset ingestion.

GPU Texture Compression Standards

Modern glTF pipelines rely heavily on extensions like KHR_texture_basisu (using Basis Universal / KTX2) to compress textures for rapid transmission and direct transcoding into native GPU formats such as BCn, ETC2, and ASTC. These compression schemes operate on fixed blocks of pixels—typically 4×4 blocks. POT textures naturally conform to these block constraints, ensuring that textures can be uploaded directly to VRAM without needing CPU-side decompression, padding, or re-sampling before rendering.

Memory Optimization and Bandwidth

Graphics hardware allocates memory in binary blocks. Non-power-of-two textures often force the GPU driver to pad the texture in video memory (VRAM) to the nearest power-of-two dimension anyway. This internal padding wastes memory bandwidth and capacity without yielding any increase in visual fidelity. Using deliberate POT dimensions guarantees that every byte stored in the glTF file and allocated in VRAM contributes directly to the rendered image, preserving performance across mobile devices, low-power hardware, and WebXR applications.