Procedural Textures: Gaming's Future

It looks great, I want to download a little tech demo to see how much this will take out of my computer to run. I just think about developers filling up all the space that it saved to make things look even better.

 

Most of these informations can be found on Allegorithmic's website : http://profxengine.com/index.php?PAGE=HOME

1. You design the procedural texture directly with the tools.
(You can check the gallery to see what kind of material can be made)

2. It's faster, you can see some example of this in the Gamefest presentation I think :
http://profxengine.com/resource/specifications/allegorithmic_profx_gamefest_2006.zip

 

that's not really true. you need to convert the procedural texture into a traditional texture in order to do stuff with it in the rendering pipeline. once it's a normal texture it's just as large as any other texture, so you still need to take into account memory requirements.

the only real advantage here is that the textures stored on disc are tiny. that game you have taking up 5GB of space on your HD would take up 400MB.

so it's a really good thing for digital distribution.

 

I admire people that can think in such complex way very much. Math is fantastic and I would like to pick their brains so I maybe could understand a bit more. Looks very interesting

 

Just downloaded Roboblitz. A few problems....
- The download was 350MB
- It took 30 minutes to start the demo, for the first time, it has to cache the shaders and build all the procedure textures. (it did this for the whole game, even though the demo doesn't need it)
- It didn't look that good. Some textures were nice and detailed. But the floor wasn't too sharp.
- The game's install folder is 441MB

I do realise that my system is a bit out of date (3.2 P4 Northwood, 875p, X850pro) but it's not THAT old; I can run HL2 at max settings 1920X1200.

Maybe this game uses just the basics of this procedule texture system, merely for distribution. But it did seem to take a VERY long time building those textures. I think it might be a few years before it will be able to work on mid-range systems quick enough. Without that, it's not very consumer friendly.

 

No need for BluRay no more, unless they want loads of seemless cutscenes

 

Great stuff! Now someone just needs to find a way of passing on applying this level of efficiency to hardware.

<A88>

 

In addition to making textures smaller on disk, procedural generation also has the advantage of not requiring talented texture artists to make high resolution textures. Texture art is becoming more and more of a challenge. These days you have artists making maps at a base resolution of 4096x4096. They make the normal diffuse map, a bump or normal map, a specularity map, and all sorts of other crap. Procedural generation can greatly simplify this.

It doesn't mean texture artists will be obsolete, though, since you still need people to come up with the designs. But the work isn't going to be nearly as hard. It'll make it a lot easier for smaller developers or modders who can't find or hire good, dedicated texture artists. If you have ever worked on anything bigger than a small scale mod for a game in the past four years, you know what I mean.

Also, procedural generation can scale better with texture resolution. The algorithm that generates you a 512x512 texture could generate a 4096x4096 without losing detail.

 

I'm interested, how can it create larger textures from 512*512 thats amazing !

 

Having played around with 4k and 64k demos myself, I've gotta say that I find having this technology on mainstream games is going to be a massive boon for the average user and digital distribution. The only thing about this is that levels will take even longer to load now as textures will have to be generated beforehand (on the fly generation is quite processor-intensive). So in reality I don't know if this will be that great, but for now I love it.

 

the future.... today me likes.

 

It doesn't create them from 512x512 textures, it generates them at any given resolution.

I'd also like to point out that procedural texture generation is probably 20 years old. It's just the idea of using it effectively in modern games that is new. Getting procedural textures that don't look fake and repetitive can be quite a challenge.

 

This looks absolutely amazing. The images produced are worthy of Crysis. I think the main points being made against it are a little pedantic, though. Firstly, while processor speed is a factor, we have brand-spanking new quad core processors coming out. In this context ~2cores could be used to render the textures on-the fly, making loading times more bearable. Secondly, just because we have massive 500GB+ HDDs, it doesn't mean that we should waste the space. IMHO, anyone who thinks that 5GB->1GB is not a worthwhile difference is living on a different planet. In today's context of efficiency, anything which improves the way we use the existing resources is a welcome addition. IMO, it's not rocket science: if you could fit the same games on a 80GB HDD as on a 400GB HDD, which would you go for? Surely I'm not the one with old hard-drives lying around!

-ed out

 

Couldn't we use physics engines to helpt the processor out?

 

Texture generation is easily parallelized. It could be split between CPU cores and some offloaded to the GPU. You'd be generating them directly in memory. With any luck on multi-core systems and some fast algorithms, it'll be faster than loading from disk.

 

This is just like the whole vector vs. bitmap debate for 2D graphic file formats. Procedural textures are likely just specialize pixel shader programs with several input variables. To change the textures, you just change the input variables for the shader program. From the look of the demo video, it also had procedural bump maps as well.

The downside to procedural textures is the processing requirement on the video card side. There are like a few cheats, like caching the finished texture in RAM. A texture is rendered once so that it doesn't have to be processed again for sequential frames that the textures appears in. The Roboblitz game seems do this for all the textures when the game is loaded, and not on the fly during the game.

The X-Box 360 has several CPU and GPU functions for accelerating procedural operations. The SpeedTree middleware used in Elder Scrolls IV: Oblivion is an example of that aspect of the X-Box 360's functionality. The PS3 has Cell and its vector units which could easily perform such functions as well as a nVidia GPU that can do much of this work.

The end result of games down the road will likely be moderate use of procedural textures with compressed high resolution textures. Procedural texture use will be limited to those that can be performed quickly with caching and those that won't significantly increase load times. Things like realistic floor/ceiling/wall textures and human skin fit well into these catagories. The complex textures and those that don't fit well into a procedural programs will continue to be bitmaps. Things like posters on walls, bill board signs ect. in games are examples that will continue to use bit maps. Even the developers of this technology have stated that not all textures are going to be procedural. Developer time is also a factor in how often procedural textures are used - if the gain is less than investment in time for developers, the technology will find itself in a niche.

 

kkrieger

First of all, check THIS game out. It is by the person interviewed in the article. EVERYTHING is procedural, not just the textures. Because of this, the whole thing is only 96k!
The "game" is over two years old, and is more of a proof of concept rather than a true game. It uses an old method of procedural texturing that is much less efficient(and slower) than the one proposed in the article.
Really, it is an amazing technical accomplishment, and will give you an idea of the potential for procedural methods.

 

I've just played kkrieger. I'll start with the bad points: 1. Gameplay was rather poor. 2. There didn't seem to be any anti-aliasing. 3.On my geriatric Athlon XP 2600+/512 DDR/GeForce FX 5200 it was barely playable. In fact, I get higher framerates in NFS Most Wanted. However, that being said, all I can think is WOW!!!! 96k!?!?!?!?! The textures looked absolutely amazing! As a game, this is dire, but as a tech demo, it leaves me speechless. Every other game I have seen with textures this good took up over 1GB. :thumbs:

-ed out

 

I think this is a step in the right direction; however, I'd much rather see the GPUs be able to render these on the fly. That way, a few more advantages could be realised which might actually make things look better or run faster:

- Textures covering a wide area wouldn't need to tile and thereby repeat. This especially applies to dirt overlays and suchlike.

- The granularity of the texture can be tailored to the relative size of the region of interest - that is, close-up views can be rendered with more detail as required, rather than the somewhat kludged "close-up texture" idea that's being used right now.

- It would use vastly less texture memory.

So this is great, but as others have said, it's not really going to make things look enormously better, although it could be the beginning of something that would.

Also, as has been explained, the FFT variety of this sort of thing is ancient news - I was doing procedural textures on the Amiga back in the days of Imagine. I was rather wondering how long this would take.

Phil

 

I think this is mainly just a lot of hype...


1) Procedural textures look crap compared to what an artist can make with a digital camera (for realistic-looking textures) or a paintbrush / digital palette (for more artistic, creative stuff) and Photoshop + plugins. Maybe one can write a procedural texture which can be rendered to infinitely-high resolutions, but that isn't feasible in real-time graphics engines or even necessary with finite-resolution displays.

There's a big difference between art created by a human and images generated by a computer. Computer-generated stuff is too copy-pastey, too bland, too repetitive. Sure, one can add lots of extra variables to make the textures more random, but at the end of the day, you still need human artists to create unique, high quality content (with the help of image processing software like Photoshop, of course, but that's not procedural texture stuff) for different parts of a computer games.

Just to be clear, I'm talking about state of the art games here, not stuff like RoboBlitz, Pac Man, or Tetris. For visually simple games, going purely computer-generated can work (as RoboBlitz demonstrated). But for triple-A games, it isn't. There's no way you can just write a few lines of code and have a computer spit out all the textures for a game like World of Warcraft, Half-Life 2, or Grand Theft Auto!


2) High-quality content in state of the art computer games are made by professional artists, not coders. Creating procedural textures requires coding skills and maths skill, or? Well, traditional textures in computer games are painted (sometimes purely digitally). Sometimes photographs are taken used and then modified in and processed by Photoshop to make them tessellate seamlessly and such. Either way, artists would seriously be handicapped if they had to create textures by only writing code.

Could you teach artists to create textures by writing code for procedurally generated textures? Maybe, but it would take years for them to learn, and working with and modifying their work through code (instead of something like Photoshop) would be a nightmare, and at the end of the day it just wouldn't be a faster process.

The only real benefit of procedurally generated textures is their low file size, but because they're made by writing code rather than painting stuff by hand, one cannot just convert an arbitrary image into procedurally generated texture code. Well, actually, one can compress an arbitrary image quite a lot (Jpeg, Png, Gif, I'm sure you all know about that), but that's not as small as code for a simple PG texture.


3) Load times. True procedural textures take long to generate, especially if they're complex. Computing them at run-time is out of the question for triple-A games as it would just take too long, and if one would pre-compute them, the benefit of saving storage space would be lost.


(By the way, these arguments apply to 3D models, game levels, sound, music, etc, too. For professionals, using 3D Studio Max, Maya, XSI, Photoshop, UnrealEditor, Valve Hammer Editor, SoundForge (sorry, I don't really know what the industry standard sound/music applications are ), etc to do make their stuff is way more productive than trying to hack something together by writing code.)


Besides generating pseudo-random levels (like in Diablo) and generating some random bits of environments prior to compilation (like with the forests in Oblivion), I really don't see any more uses of procedurally-generated content in state of the art computer games, at least in the near future.