Slashdot Log In
Procedural Textures the Future of Games?
Posted by
Zonk
on Fri Nov 10, 2006 12:41 PM
from the teeny-tinny-prettiness dept.
from the teeny-tinny-prettiness dept.
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."
Related Stories
[+]
What if Game Graphics Never Aged? 398 comments
An anonymous reader writes "If you've heard of Procedural Synthesis, you already think it's amazing. It's been used to create some extraordinary visuals in tiny packages, like .kkrieger, which is less than 96 Kilobytes big but still has graphics that look like like a modern PC title. Beyond that, there's even more that Procedural Synthesis might be able to do; what if your old video games never aged, never looked out-of-date? Imagine putting Halo 2 into your Xbox 360 only to have it automatically upgraded to look like Halo 3 in graphical quality. This article examines the unexpected way that Procedural Synthesis might impact gaming in the generation after the Xbox 360, PS3, and Nintendo Wii."
[+]
John Carmack's QuakeCon Keynote Video 44 comments
Donnie D writes "Video of id Software's John Carmack is available from his address to QuakeCon 2006 last week. It was comparable to his down to earth speech presented last year when he focused on next generation console gaming. This year, he focused on multi-processor support in games. Mentioned in his address are interesting details such as NVIDIA's sponsorship of Armadillo Aerospace for the X-Prize competition, vague details on id's next game, and topics related to his cell phone games. The video includes 1 hour and 20 minutes of Carmack's address."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
isn't it slow? (Score:3, Interesting)
Re: (Score:2)
Of course, the first-gen stuff will probably generate the textures when they'r
Re:isn't it slow? (Score:5, Insightful)
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.
Parent
Quality (Score:5, Informative)
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.
Re:Quality (Score:5, Interesting)
Yeah, I bet it will be a while until they are generating the textures on the fly every frame. However, as an intermediate step one could imagine being able to easily generate a larger number of textures for varying levels of detail, rather than having to pre-determine what levels you're going to include on the disk.
Parent
Re: (Score:3, Insightful)
Creation issue (Score:2)
the industry by storm if it requires a highly specialized programer
to create a proceedural texture. Is there a Photoshop plug-in?
Great images though!
Re: (Score:2)
No. You win.
Re:Creation issue (Score:4, Interesting)
Please try to keep up with the conversation before you mock someone else.
Parent
Re:Creation issue (Score:4, Informative)
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.
Parent
Re: (Score:3, Interesting)
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.
Re: (Score:3, Insightful)
(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
Re:Creation issue (Score:4, Insightful)
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.
Parent
Re: (Score:3, Funny)
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 sho
Re: (Score:3, Insightful)
Re:Creation issue (Score:4, Interesting)
Parent
Will it decrease loading times? (Score:3, Interesting)
Tradeoff... (Score:4, Insightful)
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.
"Elite" used this technique over 20 years ago (Score:5, Informative)
Sony has been hyping procedural texturing recently, the PS3's Cell architecture is supposedly ideal for doing this kind of thing.
I've been a fan of these guys for a while. (Score:2)
From the itsatypo dept. (Score:3, Funny)
kai's power tools (Score:5, Insightful)
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?
Re:kai's power tools (Score:4, Insightful)
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.
Parent
Not only textures (Score:4, Interesting)
Not procedural: Simply, compressed. (Score:4, Interesting)
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.