Procedural Textures the Future of Games?

An anonymous reader writes "bit-tech has posted an interview, with the head of Allegorithmic, Sebastian DeGuy. In it DeGuy again makes the statement that his software (which was used to make the Roboblitz game released on Steam recently) will be used to make games 90% smaller than what they currently are. He comments on why his procedural texturing technique is an evolution of the infamous .kkreiger. demo and how procedural texturing compares to Carmack's 'megatexturing'. The article includes some pretty extraordinary pictures of scenes rendered with just a few bytes as opposed to the ridiculous sizes of modern games." From the article: "Despite some similarities, technique-wise, we are quite different in several ways. First, the inner technology (the maths) that we use is based on modern maths. We use 'Wavelets', instead of classic maths method of 'Fourier Transform', which was the mathematical technique used in the past by all the procedural texturing techniques (including .kkrieger). Our technique works on a new mathematical model that I developed whilst studying for my PhD."

Comments

Tradeoff...

[HaeMaker]

They are trading file size for CPU performance. While the impact of reduced file sizes are clear, the impact on CPU is not. The question is, is our ability to add storage and bandwidth slower than our ability to add CPU and memory?

I think storage and bandwidth will start winning over CPU as we seem to have hit another Ghz wall and are throwing cores at the problem. While RAM, hard disk and flash are all getting cheaper and bigger at a faster rate.

kai's power tools

[Speare]

This debate, traditionally painted textures versus mathematically derived textures, reminds me of the feeling I got when I would use any one of the (in)famous Kai's Power Tool suite.

These tools were image processing tools with (to be polite) quirky user interface concepts. The output was always interesting, but never what you really planned. Throughout the literature and documentation, there were sprinkled sentences straight from my Jr. High School art teacher, about "happy accidents" and "explore" and "try a few different things to see what's exciting." The interfaces didn't explain themselves, you had to fiddle with them, and in the process of fiddling, you might get some image output that was astounding, exciting, bizarre, cool, inspiring. The creators of KPT saw that as a good thing.

However, there's a big difference between opportunistic art and production art. The opportunist is the lady on the edge of town who boldly wields an acetyline torch and welds together scraps of iron to sell as mobiles or unique garden fairies or whatever happens to come up. The production artist is told to make a Chanel No 5 ad, which entails a certain palette, a certain wispy but crisp attention to lighting, an interplay of gravity and weightlessness, and above all, black garments on gaunt 30-something models. Things are constrained very tightly for the production artist, and they let that constraint drive their creativity.

KPT is great for opportunity artists, but not for production artists. Write down a concept on a Post-It, and just *try* to achieve that concept with their tools. You can't figure out what the third blobdot widget from the left is doing, so you try to get it to where it is somewhat close. Then you hope the fourth blobdot widget from the left doesn't fuck up any progress you've made when you touch it. You may find a thousand really cool accidents on the way, but you will never really achieve that concept you wrote down on the note paper beforehand.

This comes back to procedural textures.

• You can tweak and tune and adjust for hours, just trying for the perfect simulacrum of a chunk of oak woodgrain, trying to achieve the ultimate blend of four levels of grain periodicity through natural variations in density, allowing for convolutions that resemble knots and sawblade artifacts, all within a neat 16 parameters.
• Or you can snap a photograph of the boardroom table, use some morphing and blending tricks to make it tile if necessary, and be done.

Which approach do you think will still be in use when they make Final Fantasy XXXIV?

Re:kai's power tools

[Control Group]

I'm not an artist, so I could be way off on this, but - I would think that the level of per-pixel detail you're talking about isn't necessary for a lot of textures used in games. How much control do you need to have over the specific wood grain of a door, for example? Wouldn't it be good enough to specify that it's a mahogany tone, with a range for grain tightness, with the grain running vertically?

Essentially, what they did with the trees in Oblivion - it doesn't matter for almost any of the trees that they look a specific way, just that they look like various flavors of deciduous tree.

I would think an awful lot of textures could be like that - anything plantlike, marbles, anything with an actual repetitive pattern (screen doors, cyclone fence, brick walls, etc). Sure, there are no doubt plenty of textures that need to be just so, but an awful lot of the game world is stuff that doesn't matter at the degree of detail you're talking about - as long as there actually is detail there.

But again, I don't do texture creation for games, so maybe I'm way off base. But the fact that it was definitely used for Oblivion, and both MS and Sony have said that they tried to design into their machines facilities to handle procedural textures more easily lead me to believe that it's not the lost cause you make it out to be.

Re:isn't it slow?

[grammar fascist]

He'll probably just comment on how "cool" the compression rates are.

He'd be right, too. Procedural texturing is just another form of compression. The big difference is that in generating textures, you work directly in the compressed space rather than letting a machine compress the finished product, so you can get totally mad compression rates.

In other words, his intuition just spanked your geeky arrogance. ;)

Re:Creation issue

[AKAImBatman]

Like an amazing fool, you keep failing to listen. And here it is, the proof of the pudding:

And if you're going to show images on the screen (AKA bitmaps)

Procedural textures are not bitmaps. The fact that you think they're the same shows just how little you understand about the subject at hand.

In fact, most procedural texturing tools map the display to different objects like spheres, boxes, and cones. The purpose of doing this is to show how the texture will look in actual usage. The only "bitmap" is the one dumped into the framebuffer during rendering. When the artist zooms in, a new preview is generated. When he zooms out, a new preview is generated. When he textures a new object, a new preview is generated. There is NO bitmap.

And, incidentally, I'm pretty sure you can do text handling in Photoshop. Just like you can do drawing in Word.

Hey everyone, Control Group thinks that the text handling in Photoshop is good enough for Word Processing! (rolls eyes)

I mean, seriously. I'm drawing blood from my tongue not to throw an insult at your lack of understanding. I honestly realize that not everyone understands the inner workings of computers, mathematics, and computer software. But you're taking stupidity to new heights here. Maybe you should take a step back and pay attention to what everyone is saying? They're not just talking out of their asses here. Some of the people on this forum have done actual, honest to God work on procedural texturing. I still have my own Perlin code sitting around on my hard drive. (Originally intended for a super-small FPS that was going to compete in a competition.) We know a few things about the subject that you obviously don't.