By Christopher "shaithis" Buecheler
rocedural texturing is not a new thing for much of the computer world, especially that part concerned with 3D modeling and rendering. Procedural texture effects, which are slightly different, are old hat as well. For real-time 3D games, however, it's just starting to show up. Unreal has quite a bit of it, and next-generation engines such as Quake 3:Arena (and Ritual's Uberengine, before the main code guys on it left the company) should have even more.
This article is going to cover the basics of procedural texture effects, and give an insight into how it may affect 2D artists. I'm not capable of giving a complete, in-depth look at the mathematical concepts behind procedural texture effects (for one, because I've never been a huge fan of math, and for another because it would take a book to do so), but what I'm covering should give a pretty good basic concept.
So what are these two items, and what's the difference between them? Procedural texturing is the generation of textures that stretch on forever, but never truly tile. You could use a procedural texture on a ground brush that's 512x512 units wide, without stretching the texture, and you'll see no repetitions. It'll all look like grass (or whatever texture you choose), but there will be slight differences throughout. This technology is still in its infancy stages in terms of 3D games, since at the moment it's easier to make a static 2D texture that looks really nice, and tile it, then to code and use procedural textures, which in my experience tend to be less detailed than the average handmade texture. I'm not going to cover procedural texturing in this article, because technology and my own interest are currently focused on procedural effects on static textures.
In terms of 3D Games, procedural texture effects mean applying a mathematical animation to a predefined texture in real-time. In layman's terms, the coders have found a way to make the texture "do stuff" after it's been applied to the brush. This is not the same as Quake/Quake 2's animating textures (though that's another valid way of handling certain effects). Procedural textures, because they are code-based, don't have a finite loop. Also, the frames are calculated in real-time (as the game refreshes the screen), rather than being created as static images and then compiled into an animation.
I seem to be unfairly favoring Unreal in recent articles (then again, it's definitely one of the most state-of-the-art engines available), but it is yet again the game to look to for the best examples of procedural texture effects. Note that not all of the special effects in the game are procedural texture effects. For example, the lens flares, the fog, and (I think) the waterfalls are sprite/particle/volumetric effects. The most common examples of procedural texture effects in Unreal are the bodies of water, and fires (oh, and the main menu if you look closely).
The water (and lava) in Unreal was one of the early things in the game that really jumped out at me (the sheer vibrance of the engine being the first). Here you have a repeating texture (that already has a very well-done lack of obvious patterns in it) that seems to bubble and ripple like real liquid (although in defense of reality, I must say that many of Unreal's lakes look as if they're boiling). How did they accomplish this? It's not an animation, like Quake's water. Rather, it's a procedural texture effect.
To quote mercilessly from Epic's own documentation on the subject, "the water, wet- and ice-textures can convey much more than realistic water surfaces; used as a general means of warping source art in a noisy pattern, force-fields, swirly energy bursts and convincing turbulent flames are just a few of the possibilities."
The concept of "noise" in this case has nothing to do with how loud your speakers are. Rather, it's how chaotic the effect will be. A relatively non-noisy effect might be a very slight rippling of the water. A heavy-noise effect is going to look like a pot of water at full boil. The values that determine how noisy the pattern will be can be set directly in Unreal's editor.
Some patterns are not particularly chaotic, however. Take for example Unreal's main menu. If you look at the background, you'll notice that it appears as if you're looking into a pond being hit by raindrops. This is an example of a far less chaotic procedural effect. It's also an excellent example of the difference between an animation and a procedural effect. In the former, you'd notice a pattern to the "drops", after awhile. They'd show up in the same places every time. Using a procedural effect, the engine is choosing things like location, drop size, and (at least in a similar program a friend of mine wrote a few years back), and how thick or thin the liquid is (this affects the ripples. The thinner the liquid, the less time they last).
It's important to note that these patterns are not user-defined. That is to say, the texture-artist does not first draw a greyscale map, and then apply it to the texture. The engine generates the pattern for itself, mathematically, and applies it in real-time. This is the major difference between procedural effects and "mapping" effects (bump, environment, diffusion...we'll get to those later on in the series), where the system is taking a user-created, non-animating pattern and applying it to a texture.
Procedural textures effects now are being used predominantly for chaotic textures, like water, or fire, or forcefields. Procedural effects may eventually be used for even more interesting purposes. One such use, suggested by Intel's developer website, in fact, is that of "weathering". A procedural texture could be used to simulate the effects of erosion on a rock face by adding more pits, gouges and scratches. This might make for an interesting in-game cinematic, to help denote the passage of time (especially if you made it look like stop-action photography, by having other objects in the cinematic moving very quickly, or whatnot).
Procedural texture effects have very definitely found a home in 3D gaming, where the "ooh and aah" factor of graphics becomes extremely important. It's only a matter of time before level designers have the capability not only to add shimmering ripples to their pools of water, but to corrode the edges of a metal vat holding acid in real-time. From there, it's only a matter of time until the engine's capable of literally corroding the brush, breaking it into further polygons and simulating the way in which acid "eats" through things. But that's another article altogether :)
A good writer always lists his sources, by the way. The two places I gleaned much of my information from were:
The Unreal Technology page: http://unreal.epicgames.com
Intel's "Techniques for Writing Scalable 3D Games", written by Michael Rosenzweig for the CGDC:
Until next time,
- Christopher Buecheler is a freelance 2D artist.
Credits: Graphic Content is © 1998 Christopher Buecheler. All other content is © 1998 loonyboi productions. Unauthorized reproduction is strictly prohibited, so don't do it, or we'll paint you white against a white background.