NNTC repo now on GitHub

NNTC ("Not Neural Texture Compression") is a two-latent PBR texture representation where the encoder fits the GPU sampling path, not a texel-only reconstruction. The GitHub repo is here:

https://github.com/richgel999/nntc/

It's a PBR texture encoder which outputs 2-3 standard .DDS files and a JSON file containing fitted coefficients. It doesn't use neural networks to decode correlated PBR material textures (between 3-18 channels, or 1-6 3-channel RGB textures). Instead it uses plain linear operations to decode (or remap, or expand the dimensionality) of the output channels after standard hardware texture sampling/filtering.

I got this working after implementing neural texture compression using ES (Evolution Strategies), then realizing (after taking inspiration from the old PVRTC1 texture format) the problem can be easily changed so no neural networks were needed to decode the material channels. The end result is far simpler and faster to encode and sample.

The first latent the tool encodes is at full texture resolution and uses BC4's or BC5's. The encoder's backend is BC4/BC5 aware. The second latent is at 1/4 resolution and uses 8-bits/channel, and is 8,16,24 or 32 bits. The encoder supports mipmapping, and the resulting latent textures can be sampled normally (with standard filtering). 

The encoder supports 1-4 channels per latent and up to 6 RGB textures.

The encoder supports Windows and Linux and currently requires CUDA. There's a D3D11 viewer (works on any GPU) showing how to sample and then decode by applying the fitted matrix coefficients. The 2nd latent texture (which is at 1/4 resolution) needs to be sampled with a MipLODBias setting of +2.

This allows PBR textures to be stored in VRAM at roughly ~2.5 bpp, not counting mipmaps. The actual bitrate in memory depends on the channel settings and the material size in textures (it's a matrix of possible bitrates).

The more correlated (or lower dimensional) the textures in the material, the better this method works. The less correlated the textures, the more latent channels are needed. 

Also see this excellent series here:

"Dimensionality reduction for image and texture set compression"

https://bartwronski.com/2020/05/21/dimensionality-reduction-for-image-and-texture-set-compression/

This repo also includes a Prior Art Disclosure, dated September 13, 2026:

https://github.com/richgel999/nntc/blob/main/PRIOR_ART_DISCLOSURE.md

BC4/BC5 could be transcoded near-losslessly to ASTC LDR 4x4 fairly easily for mobile/tablet usage. I may add this in the future.

A variant of this idea with lower in-memory bitrates, that doesn't support native GPU texture sampling but is more flexible (supporting more channels, with quantization aware encoding), is possible. This variant would still only use plain linear operations (i.e. no MLP's for decoding), but would require the developer to roll their own filtering.