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."
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.
It's slower to load, but in action it's just as fast as 'normal' textures. The only difference is the texture being rendered was generated on your machine during the game's loading sequence instead of in photoshop on some artist's machine. They're both just pixels when it gets to drawing.
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.
Which approach do you think will still be in use when they make Final Fantasy XXXIV?
[
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.
I got my Linux laptop at System76.
(raises eyebrow) Do you download wordprocessor plugins for Photoshop as well? Because that's about how much procedural textures and Photoshop's framework have in common. Sure, you could "write a plugin". But that plugin would have to manage everything from the parsing of the file format, to the full interface, to the handling of the files. It would make just about as much sense as a Microsoft Office "plugin" for Photoshop. i.e. None at all.
We're not talking about script-fu type of stuff here. (Which is, BTW, a type of procedural texturing.) We're talking about creating the textures without generating a bitmap at any point in the process. The two are not even close to the same. That is, unless Photoshop recently obtained an infinite zoom feature, handling of images of infinite size, and no longer has any pixel manipulation tools?
Now give back those mod points. You're perpetuating stupidity.
Javascript + Nintendo DSi = DSiCade
Analogies don't equal equalities, they are merely somewhat analogous.
I would like to nitpick by pointing out that "infamous" does not mean what "anonymous reader" thinks it means. An "infamous" game has a notoriously bad or evil reputation.
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.
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.
Javascript + Nintendo DSi = DSiCade