Proceduralism Is A Way Of Life
November 20th, 2006 by Andy |
 |
|
 At work (as in, not AV Club) I do visual effects. Specifically, I am a 3D artist with a focus on particles, but I do a lot of general 3D work. Procedural workflows are Godlike in their power to do effects work, and ever since I was shown the light and introduced to them, I have not looked back. Basically proceduralism in 3D is using editable actions to complete a task. That’s not really all that descriptive is it. Imagine baking a cake, but at any point you can swap out the eggs for egg substitute, or remove them, and re-bake the cake. It means that the end result is created in a step by step process, wherein no single step is irreversible (if you do it right). A truly procedural workflow allows you to make something, and then change it to address what the client wants with the least amount of time and effort. If you build something right, you never have to re-do anything, you just go in and change the parameters you want and re-render it. It can be amazing to see- with just a few minutes of work you can take the scene you have created and suddenly make it completely different. I love it. Now part of a procedural pipeline is (hopefully) procedural textures. The most common of these is fractal noise- an image created by math, that you can change any time by changing the input variables. Procedural textures are great because they are infinitely editable and take almost no disk space (they are not images, just math, so they can be textures but tiny files). So say you have a room you want to cover in textures so that it looks like a real room. You could go find images that look like what you want, edit them, paint on them, change their colors, do all kinds of tweaks on them… or you could achieve the look you want using procedural textures. The joy of this route is that if you suddenly want the floor to be a different color you don’t have to re-paint it (a huge pain if the texture map is large and complex), you just change the settings. One bad thing about procedural textures is indeed a big problem- they require computation. This has made them a little undesirable in the bleeding-edge performance obsessed world of video games, where frames per second is the law of the land. That may all be about to change. The Last Boss brought this piece of news to my attention; the programmers of Roboblitz, an upcoming game for XBox Live have created some new algorithms that allow much more efficient handling of procedural textures, resulting in environments like this. Yes, the images in that gallery are made with math. I hope that more and more optimizations in this department are made, because games that look like this would be… jaw dropping. And the same technology would definitely help out my work on films too, so I applaud them. So to sumamrize, procedural textures = math, small disk space, require processing, image files as textures = harder to edit, big disk (and RAM) space. Boo texture maps, yay procedurals!!! |
||
 |
 |
November 20th, 2006 at 4:07 pm
Due to how procedural textures are rendered, they don’t play well with most game engines.
This is due to 2 factors.
1: Processing time. If a texture can be pre-rendered stored at the cost of disk space (rather than processing time), the game designers can use the saved CPU/GPU cycles and focus them on other effects (3d rendering, light, shadows, particles, reflections, refraction, physics, high dynamic range lighting, having more models on screen, higher detail levels, porn, etc)
2: Lighting. Most 3D game engines “bake” their textures. So what’s that mean? Well when the level designer is done placing all their lights, and they are ready to render (compile) the final version of the map, the light data for each surface is “baked” into the texture. So if you see a hotspot on a wall created by a torch, that hot spot is likely not being rendered in real time, it was rendered when the map was rendered by the developer. This trick is used by a lot of game engines, such as the Halflife “Source” engine (and all prior HL engines), to save resources.
But that does not mean game designers have to abandon the wonderful word of procedural textures (thankfully, because procedural textures are dope, yo), we just have to render out textures created in other applications that can handle procedural texturing (like Maya, 3D Studio Max, etc.)
As mentioned in one of my blog posts for “The Complex,” I use a program called Filter Forge to create procedural textures, complete with normal mapping, specular mapping, etc.
The down side of this is that you can not change the dynamic properties of the texture on the fly. In an ideal world I could be play-testing a map, pop open a console, and change the properties of a texture I’m looking at to see how it looks in the in-game lighting environment. To do that now, I would have to open my 3rd party procedural texturing application, change the properties, render out a new static texture, and re-render the entire in-game map. (Keep in mind that due to the complexity of some lighting environments, rendering some maps can take many hours!)
Lately there have been some amazing advancements in computer gaming hardware that take various aspects of game related processing away from the GPU (graphics processor) or CPU. There are soundcards that take over environmental processing of audio to add reverberation doppler shifting, tone control, and manipulate sound in 3d space. Ther are even physics cards that take care of in-game physics processing. One can only hope that a procedural texturing card is just over the horizon.
November 20th, 2006 at 11:09 pm
yes, traditionally procedural textures eat up more cpu and gpu cycles than is ideal, so baked and painted textures are preferred at the cost of disk space. but the article this blog entry links to is all about the fact that new algorithms developed recently are enabling games that use real time rendered procedural textures. the image at the top of this post use this technology, and there is a realtime capture video on the site linked. the advantages of procedurals (no fixed resolution, no disk space) are now within the reach of game engines because the math used to calculate them is now much faster and more efficient. a great example of proceduralism is mentioned by the last boss: Kkreiger, a fully playable fps that is only 96kb in total size, textures and all. While it is probably much simpler than many modern engines, it is if nothing else proof that procedurals are ready for primetime. we will not see them for a few years in a major way, but when they do start to take over there is no reason that you won’t be able to edit textures in game realtime, or at least without having to do long texture baking.
November 21st, 2006 at 10:17 am
Yeah, watched the videos and checked out their site. It’s super cool stuff. But we are still a ways off from complex full titles using mostly procedural textures, since they do consume more processing time. It’s not a matter of how much that “more” is, just that it’s more. Game designers go to great lengths to do hacky little tricks to save even a super tiny amount of processing time, since in the end, that time can be directed toward making the environment more complex. At the same time I’m sure there are plenty of simpler games out there that don’t have to worry about other resource hogging features that would be able to take advantage of procedural textures. I would just not expect to see it as the main texture source in the next ID/Source/Cry/Unreal engine. (But it’d be ecstatic if it was)
Though procedural textures have a lot of pros, there is still the 1 big con, that will keep them out of reach for a while. The real question is once processor speeds improve, will that extra processor time be allocated to procedural textures, or toward improving other aspects of game engines? (More advanced physics, real-time lighting/real-time shadows, more models rendered on screen at once, more advanced AI, etc)
The last big “boom” in the gaming industry was incorporating physics into just about every in-game object. I expect the next big “boom” will be incorporating more advanced real-time lighting. Some engines are doing some nice lighting tricks, but complex real-time lighting is still a major resource hog.
A lot of games have done pseudo-procedural textures though, which is still cool/useful. They are traditionally layered textures that incorporate some procedural component, like bump mapping, reflections, etc. Some components of Source engine textures are procedural, but they are generally applied to a static texture.
I can’t wait until the procedural boom hits though, and ProFX is a big step in the right direction.
January 3rd, 2010 at 3:06 pm
My husband would fall in love this website. We were recently talking about this. hehe
January 12th, 2010 at 1:36 am
I’m learning more everyday reading your blog. Thanks for all the hard work. I’m looking forward to more reading here!