Neural Texture Compression using Hypernetworks
Abstract: Recent work on neural texture compression has demonstrated that it is possible to learn small, per-material texture representations (composed of latent textures and a small Multi-Layer Perceptron decoder) that can be decoded in real-time during shading to reproduce the input to a physically based shading model. However, existing methods require performing gradient-descent optimization per material for a given MLP and latent configuration. In this work, we train a single hypernetwork that outputs both the latent features and the MLP's weights and biases. Though the solution space is high-dimensional, this approach produces results comparable in quality to the current reference neural texture compressors. We further extend this approach to infer multiple decoders at once or even produce decoders that learn super-resolution.
Paper Prompts
Sign up for free to create and run prompts on this paper using GPT-5.
Top Community Prompts
Explain it Like I'm 14
Overview
This paper is about shrinking big sets of game graphics called “textures” so they take less space and load faster, without making them look worse. The authors use a special kind of AI called a hypernetwork to turn a full set of material textures (like color, bumps, shininess) into a much smaller package that can be quickly turned back into the original look during rendering.
What questions did the researchers ask?
- Can one smart AI model learn to compress any material’s textures (not just one at a time) into a tiny format that still looks real when shown in a 3D scene?
- Can this be done faster than older methods that had to “re-learn” a new mini-model for each material?
- Can the same idea also do cool extras, like making low‑resolution textures look high‑resolution (super‑resolution)?
How did they do it?
Think of a material (like “wood” or “metal”) as a folder of image layers (textures): color, bumps, roughness, etc. These layers are big. The goal is to replace that folder with:
- a few small helper images (called “latent textures”), and
- a tiny calculator (a small neural network called an MLP) that uses those helper images to rebuild the original layers on the fly when rendering.
Older methods had to train a separate tiny calculator for every material, which was slow. This paper trains one big “teacher” network (a hypernetwork) that, when given any material, instantly outputs:
- the helper images (latent textures), and
- the tiny calculator’s settings (its weights and biases).
Here’s the approach in everyday terms:
- A hypernetwork is an AI that builds another AI. In this case, it looks at the input textures and spits out both the compressed helper images and the tiny calculator that will rebuild the textures later.
- The helper images are saved in a GPU‑friendly format called BC1 (a common “block compression” used in games). This means the compressed data works well with existing graphics hardware and features like mipmapping.
- The tiny calculator (MLP) is just a small formula the game can run per pixel to reconstruct the textures during rendering.
- Inside the hypernetwork, they use a Transformer (a pattern‑finding model) with:
- a “t‑Encoder” that makes a small global summary of the material (like taking notes about what makes this material special),
- “tokens” (little summaries of 4×4 pixel patches) that talk to that global summary using cross‑attention (the model learns which parts of the summary help each patch),
- a BC1 conversion step that turns those tokens into the helper images BC1 expects, and a linear step that turns the summary into the tiny calculator’s settings.
- Training: They show the hypernetwork many materials and ask it to produce helper images + a tiny calculator that reconstruct the original. They measure how close the result looks to the real textures (using simple pixel differences plus a “looks‑like” score that better matches human perception) and update the hypernetwork to do better next time.
What did they find?
- Quality: The compressed results look close to the originals, keeping small details like scratches and wood grain. The quality is on par with leading neural texture compression methods.
- Speed of setup: Because a single hypernetwork can generate the compressed package for any material, you don’t need to run slow, per‑material training. That makes building game assets faster.
- Hardware‑friendly: Storing helper images as BC1 means you still get the benefits of normal GPU texture handling (random access, mipmapping), and the tiny calculator is small enough to run in shaders.
- Flexible extras:
- One shared calculator: They can make the hypernetwork produce a single tiny calculator shared by many materials (helpful for simpler, faster rendering pipelines).
- Multiple calculators at once: The same system can output different sizes of tiny calculators (for different quality/speed trade‑offs).
- Super‑resolution: By feeding the model low‑res input and training it to match a high‑res target, the compressed package can upscale materials, making them look sharper without needing a separate high‑res source.
Why is this important?
- For games and real‑time graphics, textures take lots of space and bandwidth. Better compression means faster downloads, less storage, and smoother performance.
- A single, general hypernetwork simplifies production: artists can add new materials without waiting for per‑material training.
- Because it works with standard GPU features, it can fit into existing engines more easily.
- Super‑resolution from the same system can make assets look better without increasing the original file sizes.
In short, the paper shows a practical way to compress complex material textures using one powerful AI that prepares small, hardware‑friendly data and tiny calculators for fast, high‑quality rendering—and it can even make textures look sharper when needed.
Knowledge Gaps
Knowledge gaps, limitations, and open questions
Below is a concise list of missing, uncertain, or unexplored aspects that future work could address:
- Quantitative rate–distortion analysis is missing: no bits-per-texel breakdown of per-material payloads (BC1 latents + MLP) and no comparison against NTC/NBC/BCF1 baselines across multiple quality targets; no RD curves or ablations linking latent count/MLP width to bpp and perceptual error.
- Runtime performance is unreported: no measurements of shader-time decoding cost (cycles/pixel, occupancy, memory bandwidth), workgroup divergence behavior, or overall frame-time impact across GPUs/consoles; no comparison to prior per-material optimizers when many materials are visible simultaneously.
- Encoding-time advantage is not quantified: the paper claims to avoid per-material gradient descent but provides no measurements of hypernetwork inference time per material, throughput for large libraries, or wall-clock savings versus existing optimizers.
- Payload size accounting is unclear: the size of per-material MLP weights and latents (and any per-material normalization parameters) is not reported; when using a shared MLP, the quality drop vs per-material MLP and the payload savings are not quantified.
- Hypernetwork footprint and deployment: the encoder weighs 294 MB (unquantized) with no discussion of encoder quantization, distillation, or pruning; practical integration into DCC/build pipelines and memory/latency constraints for batch encoding remain unaddressed.
- Generalization and OOD robustness lack quantitative evidence: only qualitative examples are shown; no systematic metrics on held-out datasets, domain-shifted materials (e.g., scans with unusual spectra or strong anisotropy), or failure analyses.
- Channel and material coverage is limited: experiments appear to use Albedo/Normal/ARM; no evaluation on broader OpenPBR maps (e.g., clearcoat, sheen, anisotropy, subsurface, emissive, opacity/alpha), nor on varying channel subsets or inconsistent authoring conventions.
- Rendering-aware fidelity is not evaluated: no perceptual error under relighting/viewing scenarios (e.g., FLIP over rendered images), no assessment of specular lobe integrity, roughness distribution bias, or shading energy conservation relative to ground truth.
- Mipmapping and filtering behavior of latents is not analyzed: although BC1 enables hardware filtering, there is no study of mip-chain generation for latents, cross-mip consistency, anisotropic filtering, temporal stability (flicker), or UV seam behavior.
- Normal map integrity and constraints are not enforced/evaluated: no guarantee or test that decoded normals remain unit-length, avoid biasing tangent frames, or preserve correct prefiltering across mips.
- Differentiable quantization details are underspecified: BC1 conversion uses sigmoid + quantization, but gradient handling (e.g., straight-through estimators, gradient scaling) and its effect on stability/convergence are not described or ablated.
- Architectural sensitivity is underexplored: token count choice (“|t| ≥ |wb|”), DiT depth/heads, and BC1-conversion strides/kernels lack sensitivity studies; no guidance on minimal configurations achieving near-SOTA quality.
- Shared-MLP vs per-material MLP trade-offs are not quantified: quality loss, robustness across diverse materials, and runtime benefits (e.g., removal of tile classification) are asserted but not measured.
- Multi-MLP head variant lacks evaluation: no results on quality/performance trade-offs when emitting 16/32/64-width MLPs, compatibility of a single set of latents across heads, or runtime head-selection policies.
- Super-resolution claims lack fidelity and stability tests: no benchmarks vs SOTA SR for materials, no assessment of artifact risks (hallucinated detail altering material semantics), temporal stability, or preservation of physically plausible normals/roughness.
- Scalability to very high resolutions (8K/16K) and non-square or atlas textures is untested: memory, throughput, and quality implications are unknown, as are behaviors with large atlases and repeated tiling.
- Hardware and format generality is unclear: method targets BC1 latents; no exploration of BC7/ASTC/ETC2 or mobile constraints, nor cross-API portability (DirectX/Vulkan/Metal) implications.
- Error control and target-driven encoding are absent: no mechanism to hit a user-specified bpp or perceptual error; no lambda scheduling or learned rate term to balance quality vs size.
- Dataset and licensing/curation details are minimal: precise train/val/test splits, data augmentation effects, and licensing implications (e.g., Sketchfab asset usage in commercial pipelines) are not discussed.
- Reproducibility: there is no statement on code, model, or training recipe release, hyperparameter seeds, or checkpoints for community validation.
- Failure cases and qualitative artifacts are not documented: no examples of when the method underperforms (e.g., extreme microstructure, strong anisotropy, thin features, high-contrast normals) or guidance on mitigation.
Practical Applications
Overview
This paper introduces a single hypernetwork that, given a PBR texture set (e.g., diffuse, normal, roughness, metallic), outputs both: (1) block-compressed latent textures and (2) the weights/biases of a tiny MLP decoder evaluated in shaders at render time. It eliminates per-material gradient-descent optimization, preserves hardware-friendly BC1 mipmapping and random access, can emit multiple decoders (quality tiers) or a single shared MLP (to improve GPU coherence), and can be repurposed for material super-resolution.
Below are concrete applications organized by deployment horizon, with sectors, potential tools/workflows, and dependencies that affect feasibility.
Immediate Applications
The following can be integrated today with engineering effort and standard GPU stacks.
- Neural material compression plug-ins for asset pipelines (software, gaming, AR/VR)
- What: Replace per-material SGD with a one-shot hypernetwork forward pass to produce BC1-based latents + MLP weights for each material.
- Where: Game engines (Unreal, Unity), DCC tools (Substance 3D Designer/Painter, Blender, Maya), in-house asset build farms.
- Benefits: Drastically reduces authoring/iteration time for neural texture compression; preserves hardware texture filtering; maintains high-frequency detail (scratches, wood grain).
- Tools/workflows that could emerge:
- “Neural Material Compressor” CLI/SDK integrated into asset import.
- Engine-side shader libraries for MLP decoding (WMMA/tensor-core optimized).
- DCC export options “Export Neural Texture Set (BCF1)”.
- Dependencies/assumptions:
- GPU shader support for small MLPs; matrix-multiply intrinsics (WMMA, equivalent) for performance.
- Hardware BC1 support (ubiquitous).
- Build-side GPU availability to run hypernetwork inference.
- Quality targets met with chosen MLP width (e.g., 16/32/64).
- Shared-MLP deployment to improve runtime performance (software, gaming, AR/VR)
- What: Fine-tune hypernetwork to output one shared MLP for all materials; only the latents vary.
- Where: Real-time engines with tiled shading/wavefront execution.
- Benefits: Reduces shader divergence and removes tile classification/logistical overhead; smoother GPU occupancy.
- Tools/workflows:
- Engine switch “use shared MLP” vs “per-material MLP”.
- Packager that guarantees a single decoder configuration across the title.
- Dependencies/assumptions:
- Acceptable quality with a single decoder across material diversity.
- Runtime normalization/denormalization handled (as in the paper).
- Multi-decoder quality tiers per asset (software, gaming, AR/VR)
- What: Hypernetwork emits 16/32/64-width MLP weights for the same latent textures; engines choose at runtime.
- Where: Performance-scaling on PCs/consoles; VR with dynamic foveation; graphics settings menus.
- Benefits: One asset package supports multiple quality/performance tradeoffs without re-optimizing per material.
- Tools/workflows:
- Asset packers storing several MLP heads and a single set of latents.
- Runtime policy selecting decoder based on frame budget.
- Dependencies/assumptions:
- Slightly larger package due to multiple decoder heads (still much smaller than raw textures).
- Engine logic to switch decoders seamlessly.
- Material super-resolution for legacy assets (software, gaming, VFX)
- What: Train the hypernetwork to take downscaled inputs but reconstruct higher-resolution textures; deploy as “upres” pass.
- Where: Upgrading existing libraries (e.g., 1k→2k), late-stage polish for shipping titles, VFX preview.
- Benefits: Higher apparent texture detail without re-authoring; smaller downloads with on-device reconstruction.
- Tools/workflows:
- Batch SR-encoding tool for libraries.
- QA tool comparing reconstructed vs. original high-res (PSNR/SSIM/DISTS).
- Dependencies/assumptions:
- Availability of target high-res (for training) or acceptable perceptual quality without it.
- Shader-time cost budget for SR-influenced decoding remains acceptable.
- Content distribution efficiency for live-ops (software, gaming, web 3D)
- What: Ship BC1 latents + small decoders rather than full-res texture stacks; stream latents/mipchains incrementally.
- Where: Patches/updates, web GL/WebGPU demos, asset stores.
- Benefits: Smaller downloads and patch sizes; faster install times; better cache utilization.
- Tools/workflows:
- CDN/patcher aware of latents and mipchains.
- Asset store flag “Neural-Compressed Material”.
- Dependencies/assumptions:
- Client GPU can evaluate MLP in shaders (WebGPU support for matmul desirable but not mandatory if small).
- Robotics and simulation texture optimization (robotics, simulation, digital twins)
- What: Compress scene materials for simulators (Isaac, Gazebo, Omniverse) to reduce memory footprint and loading times.
- Where: Embedded GPUs, edge simulators for autonomy training, VR training simulators.
- Benefits: Smaller environments and faster iteration on limited hardware; maintain appearance for sensors/vision.
- Tools/workflows:
- Sim platform plugins implementing the decoder shader module.
- Batch conversion for large scene libraries.
- Dependencies/assumptions:
- Compatibility with simulator shading stack; MLP evaluation supported or emulated efficiently.
- Academic research baselines and ablations (academia, ML/graphics)
- What: Use the hypernetwork as a baseline to study hypernetworks for compression, cross-attention architectures, and token-to-MLP mapping.
- Where: Graphics/ML research labs; course materials on neural compression.
- Benefits: Eliminates per-instance optimization; enables large-scale controlled experiments and architecture searches.
- Tools/workflows:
- Reference code, training scripts, datasets of SVBRDFs.
- Dependencies/assumptions:
- Reproducible training environments; dataset licensing for PBR assets.
- Sustainability and storage cost reduction (operations, platform policy)
- What: Reduce texture storage and bandwidth, lowering storage costs and energy consumption in content pipelines.
- Where: Studio build farms, cloud storage, distribution platforms.
- Benefits: Lower operational cost and carbon footprint for content delivery and build artifacts.
- Tools/workflows:
- Storage policy updates to prefer neural-compressed assets at rest.
- Dependencies/assumptions:
- Governance alignment; quality thresholds accepted by art direction.
Long-Term Applications
These require additional research, scaling, standardization, or hardware/driver support.
- Standardized “Neural Material Format” across platforms (standards, software, hardware)
- What: A Khronos/glTF extension and engine standards describing BC-latents + shader-MLP decode semantics and filtering rules.
- Where: glTF, Vulkan/Direct3D/Metal shader ecosystems, console certification guidelines.
- Benefits: Interoperability across tools/engines and predictable performance/quality.
- Dependencies/assumptions:
- Industry working groups; test suites; consistent shader intrinsics for small MLPs; legal/IP considerations.
- Fixed-function or driver-accelerated neural decode (hardware, drivers)
- What: Dedicated microcode or fixed-function blocks to evaluate small MLPs for textures at raster time.
- Where: Next-gen GPUs/APUs, mobile SoCs.
- Benefits: Lower energy and latency vs. general-purpose shaders; higher throughput.
- Dependencies/assumptions:
- Vendor adoption; ISA extensions; backward compatibility with current shading languages.
- Progressive and adaptive neural texture streaming (software, networking)
- What: Progressive delivery of latents across mips/regions; adaptive refinement based on view/importance.
- Where: Open-world streaming, cloud gaming, web delivery.
- Benefits: Time-to-first-pixel reductions; bandwidth-aware asset quality.
- Dependencies/assumptions:
- Engine support for region-based latent updates; streaming protocols; prediction of runtime decoder tiers.
- On-device/on-console material compression for UGC (software, mobile/console)
- What: Run hypernetwork inference on-device to compress user-generated materials without server round-trips.
- Where: Modding tools, creator platforms, mobile content creation.
- Benefits: Privacy and reduced server costs; instant publishing.
- Dependencies/assumptions:
- On-device ML performance for one-pass inference; memory footprint constraints; power budgets.
- Extending beyond 2D textures to 3D/temporal signals (research, VFX, simulation)
- What: Hypernetwork-based compression for volume textures, animated textures, procedural parameter fields, displacement/microgeometry.
- Where: Film VFX, scientific visualization, medical simulation, fluid/smoke volumes.
- Benefits: Storage/bandwidth savings for high-dimensional assets; real-time decode of richer signals.
- Dependencies/assumptions:
- New decoder designs preserving filtering and random access; training datasets; shader/hardware support for larger inputs.
- Cross-domain super-resolution and relighting-aware enhancement (research, software)
- What: Jointly train for compression and super-resolution/relighting consistency across diverse BRDF parameters (clearcoat, anisotropy).
- Where: High-end engines, virtual production, automotive visualization.
- Benefits: Fewer bespoke textures; higher fidelity across lighting conditions.
- Dependencies/assumptions:
- Broader datasets; architecture changes to cover additional channels and more complex material models.
- Security and rights management for neural assets (policy, platform security)
- What: Obfuscation/encryption/signing of latent/decoder payloads; watermarking to deter reverse-engineering.
- Where: Asset stores, competitive multiplayer anti-cheat, DRM-constrained platforms.
- Benefits: Protects IP while using compact representations.
- Dependencies/assumptions:
- Platform cryptography support; standardization for secure shader asset loading.
- Automated QA and perceptual gating for neural materials (tooling, operations)
- What: Tools that compute perceptual metrics (e.g., DISTS) and scene-based gating (lighting/view sweeps) to approve neural-compressed assets.
- Where: Studio CI/CD, asset marketplaces.
- Benefits: Guarantees visual quality; reduces manual review burden.
- Dependencies/assumptions:
- Scene libraries for validation; fast render test harnesses; agreed thresholds by art direction.
- Hybrid pipelines combining neural and traditional compression (software, research)
- What: Use neural latents for correlated channels (e.g., albedo/ARM/normal) and fallback to hardware formats for outliers; automatic channel selection.
- Where: Engines with heterogeneous content.
- Benefits: Balanced performance/quality; simpler migration path.
- Dependencies/assumptions:
- Heuristics/trainers for channel selection; packaging formats for mixed assets.
Notes on feasibility across all applications:
- The approach assumes BC1 compatibility and small-shader MLP evaluation is acceptable within frame budgets. Performance is best on GPUs with matrix-multiply acceleration (tensor/matrix cores). Older or low-end devices may require shared-MLP mode and narrower decoders.
- Hypernetwork inference occurs offline in build pipelines; training a robust hypernetwork requires a representative, licensed dataset.
- For web and mobile, shader-language and API support for matmul and FP16 may impact runtime efficiency; WebGPU adoption can help.
- Visual quality depends on MLP capacity and variant (VarA/VarB BCF1); QA tools should tune and validate per project.
Glossary
- BC1: A GPU block compression format encoding 4×4 RGB texel blocks for efficient storage and sampling. "a set of block-compressed textures (using BC1)"
- BCF1: A neural block-compression variant that stores latent features as BC1 textures and decodes them with a small MLP. "Specifically, we use the BCF1 variant of Belcour and Benyoub~\cite{belcour2025tsnc}."
- Block-compressed textures: Texture formats that compress fixed-size blocks (e.g., 4×4 texels) to reduce memory and bandwidth while allowing random access. "hardware block-compressed textures to reduce bandwidth and storage while preserving random access and mipmapping"
- BRDF: Bidirectional Reflectance Distribution Function; describes how light is reflected at an opaque surface. "and even to fit neural BRDF models~\cite{gokbudak2024hypernetworks}."
- Cross-attention: An attention mechanism where queries attend to keys/values from another sequence or source. "We apply blocks of cross-attention between the image tokens and the latent tokens ."
- DiT (Diffusion Transformer): A transformer architecture adapted from diffusion models; here used as the hypernetwork backbone. "A DiT-style~\cite{dosovitskiy2020vit,peebles2022dit} architecture processes a normalized input tensor of shape "
- Differentiable BC1: A differentiable approximation of BC1 encoding used to enable end-to-end training with backpropagation. "we replicate the differentiable BC1~\cite{belcour2025tsnc}"
- DISTS: Deep Image Structure and Texture Similarity; a perceptual image quality metric. "We use a blend of the norm and DISTS~\cite{ding2020dists}"
- Gaussian splats: Screen-space Gaussian primitives used to approximate images or scenes. "Other methods, such as using 2D Gaussian splats~\cite{zhang2025image}, have been proposed"
- Hypernetwork: A neural network that generates the parameters (weights/biases) of another network. "we train a single hypernetwork that outputs both the latent features and the MLP's weights and biases."
- Latent textures: Learned per-material feature maps that serve as compressed representations fed to a decoder. "a set of latent textures "
- Mipmapping: A multi-resolution representation of textures to improve sampling quality and performance. "preserving random access and mipmapping~\cite{delp1979image,franti1994compression,nystad2012adaptive}."
- NBC (Neural Block Compression): A method where latents are stored in block-compressed form and a small MLP decodes the final textures. "we use the neural block compression (NBC) of Weinreich et al.~\cite{weinreich2024nbc}"
- Neural Radiance Fields (NeRF): A neural representation modeling view-dependent radiance to synthesize novel views of 3D scenes. "to produce Neural Radiance Fields~\cite{sen2023hyp}."
- Neural Texture Compression (NTC): Learning-based compression of texture sets with neural decoders for high ratios and real-time decoding. "do not match the adaptation to graphics hardware and locality of evaluation that both NTC and NBC provide."
- OpenPBR: An open specification of physically based material parameters and conventions. "see OpenPBR specification~\cite{andersson2024openpbr}"
- Physically Based Rendering (PBR): Rendering grounded in physical light transport and material models. "Physically based rendering (PBR) has become the standard for generating photorealistic images in computer graphics~\cite{pharr2023pbrt}."
- PSNR: Peak Signal-to-Noise Ratio; a reconstruction fidelity metric measured in dB. "We report the PSNR and SSIM metrics for the different architectures"
- Quantization: Converting continuous values to discrete levels, typically to reduce data size or enable hardware formats. "and quantizing the result."
- Sandwiched normalization: Applying normalization around sublayers (e.g., before and after) to stabilize transformer training. "We use a sandwiched normalization~\cite{kim2025peri} for both the attention and the feed-forward parts to avoid dead signals."
- SiLU: Sigmoid Linear Unit activation function used in neural networks. "SiLU activation functions~\cite{hendrycks2016gaussian}."
- SSIM: Structural Similarity Index; a perceptual metric for image similarity. "We report the PSNR and SSIM metrics for the different architectures"
- Super-resolution: Inferring higher-resolution outputs from lower-resolution inputs. "even produce decoders that learn super-resolution."
- SVBRDF: Spatially Varying BRDF; material reflectance parameters that vary over surface position. "increase the resolution of SVBRDFs while maintaining their appearance under relighting."
- t-Encoder: The module that encodes an input texture set into a compact set of global tokens. "first the input image is fed to the t-Encoder to extract a small set of global tokens "
- Tokens: Patch-level embeddings processed by the transformer to represent images. "We convert the input texture set into a set of tokens "
- VarA/VarB: Two BCF1 layout variants specifying latent resolutions and strides. "Depending on the BCF1 variant used (the varA or varB defined by the BCF1 method~\cite{belcour2025tsnc})"
- Weight decay: An optimization regularization that penalizes large weights to improve generalization. "the Adam~\cite{kingma2014adam} optimizer with weight decay~\cite{loshchilov2017decoupled}."
- Workgroup: A group of GPU threads scheduled together; relevant for shader execution and divergence. "prevent having multiple MLPs in the same workgroup, which can impede performance."
Collections
Sign up for free to add this paper to one or more collections.





























