Slashdot Mirror
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."
I use a program called animation master, that hsa supported procedural textures, (they call them materials). The file size for thee things is generaly around one or two k, and they can be amazing, I did a dirty tile floor using it and it was still less than 2k. The downside is render time. it drove my near realtime render to a 30min crawl. I can't imagine using procedural textures for a video game it would just kill the frame rate.
I used to have a cool sig, back when I cared
One thing the article doesn't quite touch on is the fact that procedural texturing can produce superior quality. We currently use tricks like trilinear mipmapping and ansitropic filtering to produce the best quality out of a resampling of a static image. However, this doesn't remove the fact that the textures are still of a fixed size, and will break up or look wrong depending on how close you come to the texture.
Procedural textures don't suffer from this. If greater detail is needed, it can simply be calculated from the texturing formula. As a result, a woodgrain will continue to look like a woodgrain (to the limits of the resolution), no matter how close or far away you get. Raytraced scenery has used this advantage to good effect in the last few decades. If procedural texturing finally makes the jump to gaming, the results could be incredible.
Of course, there is a downside. Real-time procedural texturing is costly. So if the hardware isn't up to it, the advantages of the texturing will go unrealized. It wouldn't surprise me at all if the first generation merely generates static textures on load, then uses them as if they were bitmaps included with the game. Still, once the box is opened, the potential will be too tempting to ignore.
Javascript + Nintendo DSi = DSiCade
Will this actually decrease loading times? It seems to be that as games get bigger, the loading times get longer, would the decrease in space needed make it require more or less time to load the game. Obviously reading the information off the disk would be faster, but I imagine you'd have a lot of computation to do to figure out what the texture is supposed to be. Kind of like how it takes less CPU power to decode a WAV file than to decode an MP3 file.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
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.
Way back in 1984, the game "Elite" used procedural techniques to generate it's galaxy maps, allowing 8 galaxies with 256 individally named and described stars to fit in a tiny fraction of it's 32k memory. A derivative of the fibonnaci sequence saved the BBC's 1Mhz processor having to do FFTs. The idea of using procedures to generate 3D graphics has been around since another BBC game, "The Sentinel", where 9999 levels of 3D landscape were generated at up to 1fps (if you were lucky!)
Sony has been hyping procedural texturing recently, the PS3's Cell architecture is supposedly ideal for doing this kind of thing.
A pizza of radius z and thickness a has a volume of pi z z a
U&I software's "Artmatic Voyager" (successor to the much better known but non-procedural landscape renderer Bryce), and it's 2D companion Artmatic Pro are excellent tools for creating procedural art. No programming experience is necessary to create quite stunning stuff, and there is a wealth of possibilities under the hood once you start building your own algorythms. Take a look at the Artmatic Voyager Gallery for some beautiful procedural planets.
A pizza of radius z and thickness a has a volume of pi z z a
Please try to keep up with the conversation before you mock someone else.
I've never heard of "tinny" graphics before.
Reality has a conservative bias: it conserves mass, energy, momentum...
Indeed it is. I always liked waffles.
You're still missing the point. Procedural textures are procedural. There is no bitmap to edit, only a set of parameters to pass to the function of your choice. Converting the result of the procedure to a bitmap would be superfluous, as it would defeat the size gains provided by doing procedural texturing!
What you usually find in procedural texturing is a tool with various sliders and controls to modify the parameters (e.g. roughness, marbling, scaling, color, etc.) of the texture. When the artist obtains the look he's going for, he saves those parameters out. There is no need for a bitmap until runtime.
The really great thing about procedural texturing is that texture libraries become even more useful. Want a marble floor? Grab a library texture. Applied to the final product, it will look like a fresh texture rather than a rehash of an existing bitmap. The texture can be as large or as small as you need, so there's no obviously tiling like the type that makes traditional textures stand out so much. When the full potential of procedural texturing is realized in gaming, it will all but remove the need for a dedicated texture artist.
Javascript + Nintendo DSi = DSiCade
From some of the animations on the product website, it looks like the software can actually procedurally generate the textures at render time. Hence the 'aging room' videos, as the parameters to the procedural textures are altered subtley over time. I imagine the code must be running as a shader. A lot of overhead for a mere shader though, most games would simply pregenerate the textures at load time.
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?
[
You're still missing the point. Procedural textures are procedural. There is no bitmap to edit, only a set of parameters to pass to the function of your choice. Converting the result of the procedure to a bitmap would be superfluous, as it would defeat the size gains provided by doing procedural texturing!
But unless you want your game levels to be made up of completely random textures, someone still needs to decide/design what the textures will look like. And the question is, can they do that in Photoshop. Of course, you know that, since your next paragraph is:
What you usually find in procedural texturing is a tool with various sliders and controls to modify the parameters (e.g. roughness, marbling, scaling, color, etc.) of the texture. When the artist obtains the look he's going for, he saves those parameters out.
Which is exactly what the original poster was asking about, and sounds like it could easily be a Photoshop plugin.
So, like Sean Connery on SNL Celebrity Jeopardy, despite your best efforts, you've answered the question. I'm sure the OP appreciates it.
Reality has a conservative bias: it conserves mass, energy, momentum...
(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
Not only textures, but animations, models & sounds will eventually be generated procedurally. Everything natural around is procedural, with the laws of physics, evolution and genetics deciding the look, feel and sound of our environment. Having artists produce textures, animations etc manually has been just a hack & shortcut to better graphics; now that it is becoming infeasible to produce the art required by the most realistic games manually, we'll finally start to get procedural games. I look forward to seeing a rebirth of the industry, with small developers being able to compete with bigger studios thanks to the increased cost-efficiency gained from procedural art.
I'm not sure that 'procedural' is really what we want. Good textures often involve real source images, for instance.
Wavelets may be more useful to compactly encode textures generated more traditionally, and to provide better upsampling than traditional polynomial interpolation methods (bilinear, etc). Rather than generating points between samples using just the adjacent pixels, points are generated from a sum of wavelets generated by looking at all of the pixels.
An example of an image format that does just this is JPEG2000.
The interesting conclusion is that maybe graphics cards should be manipulating images in the frequency domain instead of as bitmaps.
Analogies don't equal equalities, they are merely somewhat analogous.
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
Ok, so let's recap.
Q: Is it important that an artist understand Perlin code?
A: NO. As * I * said, a tool could be created for them to create the textures.
Q: Does it make sense for a Photoshop plugin to be used.
A: NO! As I said, a procedural texture tool would have nothing to do with bitmaps.
Q: So that means it should be a Photoshop plugin, right?
A: NO! What, am I talking to a wall?
Q: But Photoshop can do text! You could use it as a Word Processor!
A: What the FSCK are you people talking about?
Q: See! You should take these infinite calculations and plug them into Photoshop. Then we be all warm and fuzzy. Ahhh.
A: GAAAAAAAAHHH!!!!!!!
Q: But you mentioned having Perlin Code to point out that you know what you're talking about. Therefore, you must be suggesting that Artists should become programmers.
A: You're a utter looney, you know that?
Q: Ah hah! Proof of a Photoshop plugin. I need to pat myself on the head for my intelligence.
A: Listen, I'm gonna go make waffles. You weirdos can think whatever you want.
----------------------
This has been another production of: All the smart people have apparently left Slashdot. Tune in next time when CowboyNeal gets modded up for swallowing and then regurgitating a whole egg.
Javascript + Nintendo DSi = DSiCade