Allegorithmic Texture Compression

[Geo]

http://www.bit-tech.net/news/2006/10/04/Game_file_sizes_could_soon_be_70_smaller/

What the heck is this about? Is this practical, another perpetual motion machine, or a tech that requires such a huge infrastructure change that it simply won't happen?

Confused by the fact that I hadn’t heard about this technology before, I spoke to one of the men behind it directly - Dr Sébastien Deguy. He assured me that there were no catches with his system, that if a game contained 1GB of textures he would be able to reduce that to 300MB and lose no quality. When I asked why everyone wasn’t using the program at the moment he explained it was due to people needing to be retrained in learning a new system. He was optimistic however, that soon all games companies will be using their new texture tools.

 

[Bob]

If "lose no quality" really means bit-exact decompression, then it's another perpetual motion machine. If it were true, why don't we convert all our files into textures, use this fancy new compressor an always keep *everything* compressed down to 30%? Better yet: Feed the output of the compressor to itself and get your files down to 1 bit each!

 

[arjan de lumens]

People needing to be retrained sounds like a rather serious showstopper for this kind of technology; just why would I not prefer to just store my textures in JPEG or S3TC format instead?

I would initially guess that this is some sort of procedural-textures framework, similar to what kkrieger is using (which would explain why retraining would be needed); however I do not really see the point unless you really need to distribute kkrieger-sized games.

 

[Thowllly]

Reduce 1GB of textures to 300MB? Normal texture compression already does better than that I guess they ment compared to 1GB of compressed textures.

Anyway, looking at their webpage I only see stuff about procedural texture generation, nothing about algoritmic texture compression. If you have to remake all of your textures by hand with their tools, then it's not as usefull as their trying to pass it of as...

 

[3dcgi]

That is the point Arjan. It's similar to kkreiger. Roboblitz is an Xbox live arcade game that has to fit in a 50MB download, but it has 80 MB of textures. They used ProFX to create procedural versions of most of the textures. At load time the procedural algorithms are run to create the actual textures. In the future these textures might be created on the fly (if there is extra ALU power) or if the texture creation is faster than reading the full size textures from disk this tech can decrease the load time.

So in the end all they've developed is software to create prodecural textures with control over placement, etc. and they can be viewed as middleware for using these in game like environments.

I listened to most of the audio presentation from Microsoft's Gamefest so you'll find the above info repeated there.
http://www.microsoftgamefest.com/

 

[Simon F]

If "lose no quality" really means bit-exact decompression, then it's another perpetual motion machine. If it were true, why don't we convert all our files into textures, use this fancy new compressor an always keep *everything* compressed down to 30%? Better yet: Feed the output of the compressor to itself and get your files down to 1 bit each!

Ahh.. but I think that they aren't compressing an existing texture, but generating one from scratch using, e.g., Perlin functions and/or Wang tiling (or similar).

Confused by the fact that I hadn’t heard about this technology before, I spoke to one of the men behind it directly - Dr Sébastien Deguy. He assured me that there were no catches with his system, that if a game contained 1GB of textures he would be able to reduce that to 300MB and lose no quality. When I asked why everyone wasn’t using the program at the moment he explained it was due to people needing to be retrained in learning a new system. He was optimistic however, that soon all games companies will be using their new texture tools.

....... and when the algorithms are run and the textures are decompressed/generated, how will this system save memory and texture cache bandwidth?

I, for one, would like to see the procedural version of Lena


[UPDATE] One of the links from the referenced page seems to suggest that they are at least using a technique like, say, graphcut textures.

 

[bloodbob]

Int Function LenaProcedual( int x, int y )
Begin
Var bitmap type BMP
bitmap = LoadBMP( "Lena.bmp" )
return GetPixel( bitmap, x,y )
End


Or you can always do fractal compression which is procedual.

 

[rwolf]

priceless bloodbob

 

[zsouthboy]

bloodbob,
I'm totally adding that to some source code.

somewhere.


credited to you.

haha

 

[Simon F]

Int Function LenaProcedual( int x, int y )
Begin
Var bitmap type BMP
bitmap = LoadBMP( "Lena.bmp" )
return GetPixel( bitmap, x,y )
End

Hmmm..... I have considered burning it into rom in the chip

 

[Simon F]

[UPDATE] One of the links from the referenced page seems to suggest that they are at least using a technique like, say, graphcut textures.

FWIW I just looked a bit closer at one of their examples and it has some unpleasant discontinuities: (e.g the horizontal line up in the top left corner)

 

[RejZoR]

Ahh.. but I think that they aren't compressing an existing texture, but generating one from scratch using, e.g., Perlin functions and/or Wang tiling (or similar).



....... and when the algorithms are run and the textures are decompressed/generated, how will this system save memory and texture cache bandwidth?

I, for one, would like to see the procedural version of Lena


[UPDATE] One of the links from the referenced page seems to suggest that they are at least using a technique like, say, graphcut textures.

It's not point in saving the memory at runtime but saving the space for game in install form (installer).
And since like >60% of all content size are usually textures it's kinda logical.
It was not really a problem in the past with 256x256 textures, but today where you have 1024x1024 and even bigger textures, bigger environments and everything, you simply need more space. Like DL DVD...

 

[bloodbob]

Like DL blu-ray

Mmm 50 gb goodness.

 

[Arun]

FWIW, I'm working on something quite nice for texture compression, although of a very different nature. Hopefully I'll have results to post in a few days, and will be able to opensource it relatively soon!

Uttar

 

[bloodbob]

Wavelet compression + texture synthesis goodness?

 

[pocketmoon66]

I'm suprised we've not yet seen a hardware implementation of Perlins improved noise. The rework KP did a few years back was designed to produce a hardware friendly function, with a minimal real estate requirement. We've had a noise function is several Shader Languages for a while now but AFAICR they all return 1!

 

[Simon F]

It's not point in saving the memory at runtime but saving the space for game in install form (installer).
And since like >60% of all content size are usually textures it's kinda logical.
It was not really a problem in the past with 256x256 textures, but today where you have 1024x1024 and even bigger textures, bigger environments and everything, you simply need more space. Like DL DVD...

I appreciate that but what of the other problem of making it render quickly? I'd like to know if it can generate, say, an S3TC (or PVRTC ) format directly?

FWIW, I'm working on something quite nice for texture compression, although of a very different nature. Hopefully I'll have results to post in a few days, and will be able to opensource it relatively soon!

I'm looking forward to that with anticipation.

 

[NocturnDragon]

I appreciate that but what of the other problem of making it render quickly? I'd like to know if it can generate, say, an S3TC (or PVRTC ) format directly?

As an example, the 73 full materials (about 200 maps: diffuse, specular, normal, etc.) in the GDC demo level, representing 80MB of DXT compressed content, are being generated in 4 seconds at load-time. The ProFX description file weighs only 280KB!

From that description it looks like it can generate compressed textures directly

 

[zsouthboy]

I'm suprised we've not yet seen a hardware implementation of Perlins improved noise. The rework KP did a few years back was designed to produce a hardware friendly function, with a minimal real estate requirement. We've had a noise function is several Shader Languages for a while now but AFAICR they all return 1!

Carmack said "no" to hardware implementation of things like Perlin noise; write a shader instead.

 

[pocketmoon66]

Carmack said "no" to hardware implementation of things like Perlin noise; write a shader instead.

Even with G80 that's still too expensive to things like pure virtual (procedural) textures. I'd be interested to read JC's comments (as always!) - do you have a link ?