Procedural Textures: Gaming's Future

http://www.bit-tech.net/gaming/2006/11/09/Procedural_Textures_Future_Gam/1.html




Give us a Digg?

http://www.digg.com/programming/Int...ral_Texturing_developers_the_future_of_gaming

 

Sweet genius, imagine how much games for the PS3 could be compressed.

I quote myself "We need blu-ray space my arse"

 

Ive got to admit I can see 360 games developers using this a lot more in the future. Considering that 360 games are limited to just 8.5Gig of space (considering they don't want to make a multi-disk game), compared to Sony's possible 50Gig, this could have a massive impact in a few years once we see several itterations of games on next gen from games developers make more advanced content.

Not only that but faster access from the disk as well as there is less to read.

Considering the fact it's highly math based I can see the PS3's cores being used to simultainiously decompress and render textures on the Cells quite efficiently before sending them to memory.

 

Fantastic stuff. Like doug said, this is indeed genius - cutting out 477MB of game data is massive!

 

Maybe I didn't read the article well enough, but what are the performance gain/loss with this type of texturing, compared to regular bitmap-texturing?

I imagine not reading large textures from the hard drive could be a performance gain, but the CPU would have to actually "render" these textures into memory, so I'd say that's a performance loss as opposed to regular bitmap textures?

 

But would the X360 hardware be able to use it? I mean, I got the feeling that in order to use procedural textures, the hardware has to be built with support for them. If so, does the Xenos GPU have this support?

Or have I got this wrong?

 

A couple of random thoughts on this...

My computers run SETI@home (never got into folding) and their system is hevially dependent on Fourier transforms for signal processing. I'm wondering if the mathematical systems he's talking about would be beneficial to that system.

Second is what is the processor overhead to decompress these textures? I'm assuming that the maths involved are interger based and so current processors are well positioned to handle them, but the sheer volume of calculations to decompress each texture could be intimidating. I suppose it depends on how it's implemented by the developers. If all the textures for a level are decompressed and stored into memory when the level is loaded then it wouldn't be so bad. However if they won't all fit into memory or if for some reason they have to be processed "on the fly" then there could be a potential performance hit as the CPU struggles to keep up with that many interger operations per frame.

I wonder what similarities exist between the calculations involved for texture decompression and physics. Both are (AFAIK) heavially interger based math routines and so therefore could end up competing for the same resources. As hard as it may be to believe, I think we could be seeing the beginning to a return of games being processor limited but to the number of operations such as physics and texture decompression being dumped on the CPU. Perhaps these two operations could be combined into a unified API (DX11?).

EDIT: Christ, you guys are fast. I sit down for two thoughts and you post 5 messages before I can finish!

 

I thought procedural textures were software based, i.e. a dashboard update should be able to enable support.

Especially since the X360 GPU is unified.

 

Nope, it's a software algorythum. They've already stated that current Xbox Live games use it and you can farm out the caclulations onto the unified shader FPUs or the three CPU cores. It doesn't even need a dashboard update, the program will hold the software to tell the hardware to do the calculations. They are a middleware company: like an engine maker or a physics engine maker or a sound engine maker etc

 

I imagine that the textures are created and stored in memory like current (graphics-based) textures. As far processor time goes, he states in the article that to load and calculate the textural procedures is faster than loading and decompressing normal textures.

 

Wow, the future is cool!

 

I doubt it. A huge range of computing systems are based on Fourier transforms. If this guy had discovered an algorithm that was a lot faster and simpler than the FT algorithms he wouldn't be aiming his technology games. A lot more significant applications could benefit from a discovery like that.

If you think about it, the main advantage of this technology is to save disk space. When the game is running, it would work in exactly the same way as games do now. When the level is loaded instead of loading textures from the hard disk, the texture algorithms do their work and load the textures into memory. If during the game, a new texture needs to be generated they you might have to wait a while for that texture to appear. But that would be no different from if the textures had to be loaded from disk during the game.

In fact moving the load from hard disks which have pretty much not improved in speeds very much at all in the last few years to the CPU whose speed is increasing all the time makes a lot of sense. It is likely that when loading a level, the CPU can be working out all the textures and at the same time the disk can load the level geometry and models into memory. This should result in much faster loading times and finally unburden our slow mechanical spinning hard disks until they are replaced with better things.

 

its already been used hasnt it? in the article it says about some small dev making a game for xbox live, roboblitiz or something

they used this technique there and it worked!

 

I have a distinct feeling this will end up like the subject of another Bit's articles, anyone remember Brightside and their IMLED technology? It sounds good, but unless it attracts major players it'll end up being lost in the mists of time

 

If you enjoyed this article, give us a digg

http://www.digg.com/programming/Int...ral_Texturing_developers_the_future_of_gaming

 

jesus I thought that first image was a photo!!!

 

Same, it looks amazing.

And if anyone has seen the textures used in Roboblitz, they look U3 engine quality!

 

I like the fact that hes not a megatexturing fanboy. This type of texturing is exactly what the industry needs! Not bloat like J Carmaks approach.

He's spot on in all areas and he's very knowledgeable. I just hope more companies address this technology, because simply, the graphics are real time real life.

I just hope it's also optimized for slower technology. Not something that's a couple years old but not where we would have to spend a couple grand in an upgrade path just to run Unreal 3 with this great visual eye candy.

 

One could only imagine what Gears of War would look like with procedural textures!

 

Sounds very interesting.

As we know from computing, there is the time/space trade-off. If you want things to take up less space, you have to spend more time processing. If you want to take less time processing, they need to take up more space. The question then becomes is the saved space worth the extra time?

A few interestings points

- How intensive are these calculations, and when would they happen? Is this only on level/data load? So that once textures hit the GPU they are just like our standard bitmap textures? How about when they want to change data during the game, will it cause stuttering? (I'm being a bit dramatic here, but it is worth considering how relatively intense these operations may be).

- The main point: He mentioned in the article how it might aide in making development quicker. Does this mean that procedural textures are helpfull only in terms of saving storage space, or ALSO in terms of texture creation? Ie. Do you create your texture the normal way first, then try and figure out how to "fit" that into a procedural model. Or do you design the texture itself using the procedural tools, so that conceivably it's much faster?

- On a related issue to the last point: Are their limits to what types of textures can be created procedurarly, or rather what types of textures can be procedurally represented. Can you simply go to an existing game, look at the textures, and procedurally represent/shrink them, or must the game/textures be designed with this in mind? Ie. "Sorry, that texture can't work. But if you get rid of those specs of dust here, and darken the shading over there, then we can procedurally generate it".


I'd also like to know explicitly if the time it takes to generate 50MB of texture is FASTER than the time it takes to pull 50MB of "normal" textures off the disk. (It's suggested in the article, but not explicitly mentioned)

Interesting ideas. I'd say the "modifying textures on the fly" is the most interesting aspect. While saving storage space is nice, it's not exactly all exciting. And doesn't really have an actual impact on the game itself. (Aside for maybe loading times).

Aggies