Discussion in 'Article Discussion' started by Garside, 4 Oct 2006.
all ego rithmic, this could be nice if people use them
Been thinking a good deal on how fast games are getting larger and larger.
I remember that wasen't that something around 272KB for the entire game? and it really demanded a good PC. Though I am sure that has part to do with the compression
Though I do not see compressing the Maps and Textures as a real issue at all. Once this technology 'IF REAL' will come out and be available around the core 2 quad time and with that much processing power unpacking a map wouldn't be much of an issue. In the end I am not sure if this will make games any quicker. Correct me: but I am pretty sure the graphics card will intepret the maps in exactly the same fasion. Whether the textures are compressed or not.
The whole thing seems driven to unpack from your HDD straight onto RAM which could slash load times. The quicker it can be put onto RAM the quicker the map's should load up. Reducing HDD access times could dramatically increase the speed at which maps load, or the transitions between levels.
good news for consoles games
the 360 uses DVD, i know the PS3 will use DVD to start maybe, but it will be using blu-ray evenutally
being able to compress textures that much surely will put off the need for higher capacity discs than whats in use now
It saves in png instead of bmp, or some funky equivalent.
Anyways, this is really a plus for me, since I always seem to be running out of hard drive space at the worst possible moment. Games half the size would be a big improvement there.
I would imagine, one method of compressing textures would be fractal compression, no one's seriously used it since MS Encarta was first put onto CD (how they got all those images onto one disk). Also takes quite a bit of time for the compresser to work out what transformations applied to what parts of an image look somewhat like another part.
If it dosent need extra gpu and cpu power to work then it would be great. However I dont think that thats the case, ideally the smaller files would be easier to transfer and process through the cpu and gpu and require little ram. I want more information on this but the fact that I wouldnt need to continue buying hds interests me enough.
Just look around their site to find out how it works guys.
Files will be smaller on your HD, but not on your video card. And there will be some overhead from their conversion API.
Here's how I think it might work
We do something similar to this:
Compress three of these textures this way:
Convert all three to YUV (chrominance/luminance).
Pack the three luminance (i.e., gray scale) channels into a single DXT1 compressed texture. That gives 1/2 byte/pixel total = 1/6th byte per pixel per luminance texture. It's lossy, but can work surprisingly well.
Downsample the chrominance to 1/4 by 1/4 resolution. There are only two channels to encode, so store uncompressed (store two in an RGBA texture). Gives 1/16th * 2 bytes per pixel = 1/8th byte per pixel.
Reconstruct by using one channel of the luminance texture and two channels from the chrominance texture. Convert back from YUV to RGB. Voila.
Grand total = 1/6th + 1/8th = 8/48 + 6/48 = 14/48 = 0.2916, or roughly 30%. Freeing 70%. Hence, 70% smaller.
The downside is extra GPU cylcles (not much), and 2 GPU textures required per authored texture. There are only 16 available per pixel, so this effectively cuts it down to 8.
From what I can tell it looks like it will be:
-Smaller files on your HDD
-Faster to load and uncompress in ram
-Faster to load from ram to your graphics card
-Small overhead as the conversion takes place to decompress the data
Obviously what you gain
-Quicker load times (hopefully due to less HDD access times)
-Smaller game sizes reducing bandwidth and new media format costs
-A little bit of your HDD space back
If anyone understands the whole process a little better please correct, just how I see this taking place. We will all like to see how this plays out in the future.
Oh Kalthorn and mcnabbd welcome to the forums
Thanks for the additional info Doug & Kalthorn (& welcome to the forums). Now if ATI & Nvidia optimised for this
btw, feel free to delete my post if I am correct. I don't want to give away secrets. I'm just trying to avoid software patents. I want to keep using this technique.
Looks that i found the Codes of the (Dutch) Jan Sloot who (in 1999) claimed to made a stunning Digital Compresion System using some kind of fractal algorythms. It could compress a 720p movie to almost the size of 15mb with no reduction in quality. A day for the public presentation of his system, he died mysteriously of a hartattack and all his notes and sourcecodes where gone. There is even a book made about this mystery called "De broncode" aka "The sourcecode" and about 2 or 3 tv documentaires about the SCS
For more info see:
The stick of Jan Sloot
Jan sloot wikipedia
Dutch Quote magazine (use translations)
Quote januari 2001
>btw, feel free to delete my post if I am correct.
hehehe. I originally thought I had posted this to the allegorithmic web site. I was bouncing back and forth between it and this site. So, no need to delete
Another (obvious) way to reduce file sizes is to simply reduce the texture size. This definitely reduces the quality. But, probably not as much as you might think. The memory required changes with the _square_ of the width and height. For example: reducing the size by 30% (i.e., to 70%) in width and height reduces the memory to less than half (i.e., 0.7 * 0.7 = 0.49). Unfortunately, not all sizes are valid. GPUs usually require textures use whole memory pages (e.g., multiples of 64, 128, or 256 pixels), or even powers of 2 (e.g., 256, 512, 1024). Of course, reducing width and height each by 50% should meet these requirements. That would require only 25% of the original memory (0.5 * 0.5 = 0.25)!
Using the chrominance/luminance compression along with reducing the texture width and height by 30% (i.e., mulitply them by 0.7) would result in a texture requiring only 0.3 * 0.49 = just under 15% of the original memory.
It would be lossy for sure. But, hey it's 15% (about 6.5 to 1 compression)
It might be smaller on the disk, but I think you would need just as much texture ram because I am fairly sure that the textures are stored as bitmaps when they are used. Otherwise you would have to go through and processes them all the time when you wanted to use them, because you can't really work with a jpeg until it has been converted into a bitmap image in ram
Hi, I'm technical artist at Allegorithmic.
I just wanted to tell you that our technology has nothing to do with compression. Our textures are not compressed bitmaps, they are procedural.
The texture are created within MapZone and are exported in a single file. This file (.pfx) contains all the textures of a level for exemple.
When you launch the game, the procedural textures are computed by the GPU in a very short time, then they are compressed in DXT1 or DTX5 format and stored in the video card memory.
The compute/compress time is faster than puting bitmaps textures from hard drive into the video card memory.
The 280 textures of Roboblitz are computed in 4sec in the xbox360 or on GeForce7 card serie. The pfx file weight 280Ko.
It's because textures are procedural that the file size is reduced, once in the graphic memory the textures are stored as any bitmap texture.
Sounds good to me. Faster downloads are always welcome, and this would be very good in opening new roads for the game industry. I'm actually quite excited and hope it catches on.. can you imagine mobile games utilizing this technology? High res textures on mobile phones? These people, if it hits mainstream, have just hit a gold mine.
Is the company public?
I wonder what effect this will have with the whole blu-ray argument and the need for 25-50GB game media discs. Suddenly Microsofts decision to go with DVD makes a lot more sense.
I highly doubt we will see an increase in texture numbers in games, as developing these things take time. I think it will be used more to create new possibilities with the distribution, packaging and capabilities of lessger gaming platforms (digital distribution of better looking games. I can see it really taking off in the mobile market.)
Very cool. They look great!
This particular press release mentions that the tools will "allow companies to make games up to 70% smalller." I would think you could get _much_ smaller than that with a procedural approach. For example, the .kkreiger project (http://www.theprodukkt.com/kkrieger) fits an entire game into 64KB (not MB) by using procedural textures.
Do you know why it takes as much memory as it does? (of course, the textures look amazing, and it's smaller than authored textures )
Answering my own question (I think): This approach affects only textures. It doesn't affect audio, or geometry. So, if the textures account for 70% of the memory used, then shrinking them to 0% would yield a 70% savings.
CooCoo welcome to the forums, it is always nice to see someone from the companies we are talking about apearing here to speek to the general public, and yes the company name is strange but interesting.
if i am creating a game am i forced to make the textures in mapzone2 or can i make them elsewere, import them to mapzone2 and then export them to your very small format?
and can someone please define in a simple way what procedural textures are?
Procedural textures are not made of pixel, at least they are not before they are computed.
A procedural texture is generaly a noise map (the noise in 3ds is a procedural map), so you can zoom in it and add details to infinite. It could be compared with vectorial images.
A procedural map is made of paterns, these paterns are not pixels, but mathematical functions.
So you can found gaussians, bricks, smooth bricks .. etc in MapZone and then you combine lots of procedural maps (called fx-maps) colorize, add effect (blur, emboss, warp .. etc) to add more and more details to your texture.
MapZone is like a compositing application presented with a Graph.
Here is a screen shot of the old GUI : http://www.allegorithmic.com/v2/images/news/ScreenShotMZ2EX.jpg
MapZone 2 is still on a beta stage, the GUI as almost nothing to do with this nowaday.
It's not possible to import a bitmap texture and convert it to procedural.. it would be to easy
But it's possible to import vectorial content such as .svg into mapzone. In fact the vectorial image doesn't stay vectorial, it's converted into polygons.
I hope I answered the questions..
Separate names with a comma.