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."

isn't it slow?

[Nf1nk (443791)]

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.

Re:

[AKAImBatman (238306)]

Depends on the quality, precision, and whether or not you get a high-end GPU involved. CPUs are poorly suited to procedural texturing, but they're still able to do basic Perlin Noise Generation in real-time. If you get the DSP computing and multiprocessor capabilities of a GPU involved, the rendering time will drop like a rock. With the new 8000 series of NVidia cards, you could potentially generate dozens of textures in parallel.

Of course, the first-gen stuff will probably generate the textures when they'r

Re:isn't it slow?

[grammar fascist (239789)]

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:

[AKAImBatman (238306)]

Procedural texturing is just another form of compression.

Did I say it wasn't? ;)

My point is that procedural texturing has the ability to be a lot more than just lossy compression. It can be used to generate textures down to any level of detail necessary. Done in real-time, it would mean a revolution for video game graphics.

All I said was that Joe Average wouldn't understand that.

Re:

[ezzzD55J (697465)]

that isn't entirely fair. It's more like decompression. When you can compress other textures to small files with similar rations using wavelet transforms (for example), you can start calling it compression. The other way round (generating interesting-looking textures) is much easier..

Re:

[bestinshow (985111)]

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.

Quality

[AKAImBatman (238306)]

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.

Re:

[Bieeanda (961632)]

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.

Having played through the Roboblitz demo, and having sat through about five to ten minutes of it claiming to unpack procedural textures before the game actually began, it's pretty clear that

Re:Quality

[Chris Burke (6130)]

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.

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.

Re:

[Jerf (17166)]

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.

I would expect that if a company like this can find a powerful-enough mathematical abstraction for producing these textures, that nVidia and/or ATI would leap at the chance to put it in hardware, where it ought to speed up a

Console addendum

[Jerf (17166)]

Note I did notice them talking about working on the XBox 360 already and talking to Sony about the PS3; my point was that it's too late for the consoles to get full hardware support, not that procedural textures are impossible. It may be impractical to use procedural textures on current hardware with games that are more demanding than a standard FPS, which in computational terms is almost negligible in most cases; the average FPS is pretty much all graphics, if the textures end up eating a lot of the CPU du

Re:

[OoSync (444928)]

Maybe not up to "realtime", but probably to something a bit more useful

Useful, in this case, is defined as: less time to compute than load from the disk

In other words, the usefulness of this technique is that the latency of computing the textures can be made better than loading them off of the disk. This is especially true if you must load a compressed texture into memory and then decompress it before loading it into the rendering hardware. That ways it saves the memory size, memory bandwidth, and co

Re:

[Das Modell (969371)]

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.

Creation issue

[sammyo (166904)]

Are there tools to create the texture? It's not going to take
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:

[A beautiful mind (821714)]

Is there a Photoshop plug-in?

Hm let me think. Can I come up with a better way to show lack of understanding of the topic.

No. You win.

Re:Creation issue

[RightSaidFred99 (874576)]

The ironing is delicious. You do know that traditional textures are often created in, you guessed it, Photoshop? Ergo, his question is perfectly valid, and his point is more valid. Do you need to sit down and write code to do these procedural textures, or can ordinary tools be modified to create them.

Please try to keep up with the conversation before you mock someone else.

Re:

[oc255 (218044)]

I agree, his point was artists doing the art. Although I wonder if Gimp's script-fu goes into this space, I've never done anything with it. My best guess is that it's perl doing filters which is procedural effects maybe and not really creating game assets.

Re:

[jackbird (721605)]

The whole POINT is that they're made of code instead of pixels. Since Photoshop is a bitmap editor, the answer is no to the plugin (Gradient layers in PS are procedural textures for example, but exporting a gradient as a gradient is more in the realm of what a vector-based resolution-independent app like Illustrator or Flash is good at.)

Artist-friendly procedural texture makers exist, though, check out Darktree [darksim.com] for an excellent (albeit slow-rendering) example.

Re:

[Dunbal (464142)]

The whole POINT is that they're made of code instead of pixels.

      Eww, who wants to look at code???

      Sorry, couldn't resist...

Re:

[A beautiful mind (821714)]

The ironing is delicious. You do know that traditional textures are often created in, you guessed it, Photoshop? Ergo, his question is perfectly valid, and his point is more valid. Do you need to sit down and write code to do these procedural textures, or can ordinary tools be modified to create them.

I was thinking about that question actually. I ended up with the conclusion that the way I see it, it would be just the same as integrating a Perl parser or something like that into Photoshop. A procedural tex

Re:Creation issue

[AKAImBatman (238306)]

The ironing is delicious.

Indeed it is. I always liked waffles.

You do know that traditional textures are often created in, you guessed it, Photoshop?

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.

Re:

[Control Group (105494)]

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.

Re:

[AKAImBatman (238306)]

sounds like it could easily be a Photoshop plugin.

(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

[AKAImBatman (238306)]

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.

Re:

[AKAImBatman (238306)]

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 sho

Re:

[arose (644256)]

Which is exactly what the original poster was asking about, and sounds like it could easily be a Photoshop plugin.

And why exactly would you bolt large amounts of bitmap manipulation tools to a procedural texture designer? Making it a Photoshop plugin adds nothing to a procedural texture designer that can't be done with the black art of copy and paste.

Re:Creation issue

[Andy_R (114137)]

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 [uisoftware.com] for some beautiful procedural planets.

Re:

[Deliveranc3 (629997)]

But converting a bitmap to a procedural texture would be hella useful.

Note I'm thinking close enough technology here, obviously the bitmap cannot be entirely replicated.

Take Valve's HL2 texture from photo (W/ lightmap + reflectionmap + bumpmap) add proceedural texture to make textures manageable size (approximations of the actual textures used) = one step closer to photo to .bsp(or whatever) technology.

Will it decrease loading times?

[CastrTroy (595695)]

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.

Re:

[tfinniga (555989)]

My guess is that the load time will decrease for consoles. It seems that the bottleneck there is IO - takes a certain amount of time to load large files from the disk. This would result in smaller disk sizes. Then the programs will be run to produce images at the desired resolution on the CPU. So, there is a possibility that if the shader programs are complex enough, it'll take longer, but as IO lags behind CPU speeds, my guess is that it will still be faster to produce most textures procedurally, or vi

Tradeoff...

[HaeMaker (221642)]

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.

More cores lend their aid

[everphilski (877346)]

You can batch texture generation to cores 2/3/4 while you are playing on core 1, assuming you are running on a game which, by nature, only utilizes the first core. That is a lot of rendering power.

Granted, Valve's engine now utilizes multiple cores and we will see multi-core engines emerge, but still a core or two (of a 4/8 core processor, speaking in the future) to batch textures is not unreasonable.

Re:

[AKAImBatman (238306)]

You can batch texture generation to cores 2/3/4 while you are playing on core 1, assuming you are running on a game which, by nature, only utilizes the first core. That is a lot of rendering power.

Technically speaking, you'd batch in texture generation in with the polygon rendering. Each textel rendered would be a set of U,V coordinates to run through the texture generator. The generator would chew on the floating point coordinates a bit, then spit the result out as a color value. That's part of the reason

"Elite" used this technique over 20 years ago

[Andy_R (114137)]

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.

Re:

[rev063 (591509)]

This is a great example of using similar procedural techniques to generate entire environments, not just textures, and Elite was indeed a pioneer in this area.

The most recent example I can think of is Oblivion, which used procedural techniques to generate the forests. The branches and leaves of each tree were generated procedurally, not pre-defined. (The same may also be true of the positions and species mixture of the trees in the forest, but I'm not sure about that.)

Re:

[jackbird (721605)]

Well, Dan Perlin, Jim Blinn, and others were doing it in '84, but not on the desktop or in anything like realtime.

I've been a fan of these guys for a while.

[GreggBz (777373)]

Watch the video's. Amazing. Infinity [fl-tw.com]

Details?

[Tom (822)]

Interesting, but low on details.

Does anyone know just how much computing power the constant (re-)generation of textures takes? How long the load times are?

I guess procedural textures have their place. They look to have some fractals inside, and it appears they are great for wood, stone, grass, etc. - basically the same things that 3D animation software has been using procedural textures for since at least 1999.

Re:

[AKAImBatman (238306)]

Does anyone know just how much computing power the constant (re-)generation of textures takes?

I think the key thing to understand is that real-time texture generation happens on a textel level. So the computational power needed is a function of how many textels you need to push. Poor man's procedural texturing is already available with pixel shaders. If you can imagine a pixel shader where the only input is the screen coordinates translated into a point on the surface of the polygon, then you pretty much un

Blu-ray?

[JFMulder (59706)]

will be used to make games 90% smaller than

Seriously, I've heard Microsoft talk about procedural texture synthesis for a while when designing the 360 and how they made certain stuff in the CPU to facilitate that kind of texture generation. Who needs Blu-ray to store high res textures when a mathematical equation will do? As for FMV, who really needs them? DVD9 might be ok for a long while after all.

In a nutshell...

[InfinityWpi (175421)]

What we're saying is that graphics can be small, good-looking, or fast... pick any two?

From the itsatypo dept.

[Control Group (105494)]

I've never heard of "tinny" graphics before.

Re:

[gold23 (44621)]

I've never heard of "tinny" graphics before.

Oh yeah, they're used for shading metallic surfaces.

Old trick, and some misconceptions...

[kbonin (58917)]

Some of us in the game industry have been using variations on these methods for years, I'm building a game now where most textures are procedural. Use of wavelets for this is nothing new either, I started playing with it myself ~ a decade ago, its always been the best approach for certain classes of image, especially for generating MIP levels. I hope the "new" idea here isn't trying to patent it...

One clarification w/r/t loading times, slow speeds, ect (simplified): With normal textures, you load your tex

Spore

[BigZaphod (12942)]

I remember hearing that Spore is going to be highly procedural. Textures, models, walking animations, etc. There's a lot of room for this approach and it's not limited to just the graphics.

kai's power tools

[Speare (84249)]

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 (105494)]

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.

Not only textures

[ichigo 2.0 (900288)]

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.

Not procedural: Simply, compressed.

[TerranFury (726743)]

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.

This is probably slow as hell.

[Ant P. (974313)]

Actually, despite what a lot of replies are saying it's exactly <a href="http://en.wikipedia.org/wiki/Embarrassingly_ parallel">the sort of thing</a> 3D graphics cards are designed for. Make it fast enough, and you might not even need to store the entire decompressed texture in RAM.