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

Comments

isn't it slow?

[Nf1nk]

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:isn't it slow?

[WilliamSChips]

Yes, it's slow. I tried .kkrieger and although it was very impressive visually, it was slow and choppy.

Re:isn't it slow?

[TheThiefMaster]

If the game baked the textures into a traditional bitmap in memory then it would just mean longer load times. Or maybe not, depending on how slow the storage you're loading from is.

You could even generate the textures to various detail levels (mips) asynchronously depending on the mip levels that the game tries to render.

Re:isn't it slow?

[AKAImBatman]

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're installed. In which case the user will notice that the 50 meg file they downloaded just decompressed into 10s of gigs of data. He'll probably just comment on how "cool" the compression rates are.

Re:isn't it slow?

[grammar fascist]

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:isn't it slow?

[AKAImBatman]

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:isn't it slow?

[ezzzD55J]

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:isn't it slow?

[maxume]

It'll only kill the frame rate until it doesn't. That is, the hardware will probably catch up.

Re:isn't it slow?

[KDR_11k]

It can be used to generate textures down to any level of detail necessary.

Only if the material has been described to any level of detail necessary. More description means more work and more filesize so I don't expect the "quality" of the description to exceed what is visible in an average situation.

Re:isn't it slow?

[Anonymous Coward]

> More description means more work and more filesize so I don't expect the "quality" of the
> description to exceed what is visible in an average situation.

If you're using fractals, you can get more detail just by doing more iterations. In that case, "more description" == "larger integer."

Re:isn't it slow?

[KDR_11k]

Except I haven't seen many surfaces in real life that are fractals. If you want to make a game about some crazy virtual reality, sure but 99% of the games on the market are based on real life or movies, neither of which contains many fractal surfaces in common situations.

Re:isn't it slow?

[WilliamSChips]

Not any exact fractals, but the shape of most leaves, and many other surfaces that need to maximize something(our lungs and bloodwork, for example), are fractal down to a microscopic level.

Quality

[AKAImBatman]

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:Quality

[Bieeanda]

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 that's what these guys are doing with it. I imagine that it'd be a real boon to something like Vanguard, whose installer purportedly weighs in at 16 gigabytes and expands to over 20, due to massive textures.

Re:Quality

[Chris Burke]

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:Quality

[Jerf]

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 lot. Maybe not up to "realtime", but probably to something a bit more useful, when combined with another couple of generations of generic advancement (as it's not going to be on the next set of cards) and some hardware-based lazy computation/caching. (For optimal performance, you may need to sometimes "predeclare" that a user is going to suddenly zoom in on a given texture; otherwise, with a hardware base you can allow "texture pop-in" to occur.)

If they come up with something both decent and useful, I suspect we can have something useful within a couple of years.

Bad news is that it may or may not be too late for the current consoles. The PS3 and XBox360 could certainly use something like this, not for graphical reasons, but to help with development costs.

Re:Quality

[OoSync]

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 computation associated with decompressing a texture.

Re:Quality

[Das Modell]

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.

Re:Quality

[Red Flayer]

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.

You mean fractal texturing? The difference here is that from different distances, you should be getting different images -- you shouldn't be able to recognize wood-grain from all distances. I.e., from 20 feet you should be able to see surface contours but not the fine wood-grain, from 10 feet you should be able to see the wood grain, from .2 inches the wood grain becomes a macrofeature, and appears to be a single stripe.

Re:Quality

[AKAImBatman]

You mean fractal texturing?

No, not specifically. But the principles are similar.

The difference here is that from different distances, you should be getting different images

We're saying the same thing, I think. I'm pointing out that zooming in on a block of wood using traditional texturing will result in a pixelated mess. Zooming in on a procedurally textured block of wood will give you the detail of the wood. Ideally, you'd start to see that the solid lines of the wood are actually a marbling. As you get closer, you should be able to make out the ringed texture from cutting. Even closer and all you see is the roughness of the surface.

The formula could give as much (or as little) detail as you want. It's up to the texture creator. In theory it's possible to provide an infinite amount of detail. In practice, you're limited by both computational time and the practicality of computing such microscopic detail. It's a bit like calculating Pi. Getting each digit gets computationally harder and harder. But the ability does exist to make a texture good enough that an observer in a virtual world would never be able to detect its artificial nature. :)

Re:Quality

[Anonymous Coward]

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.

The other big issue with procedural texturing, is that the simpler algorithms have a characteristic look which wrecks realism. If you think the render hit is big already, wait until you start blending and layering them.

The best solution is to keep using image textures, but blend them with simple procedurals that add detail, and vary from usage to usage. The same wall, for example, could be clean in one location, but dirtied up in another with a procedural. That way you don't need twenty different versions of a wall, just the one.

Re:Quality

[russellh]

Zooming in on a procedurally textured block of wood will give you the detail of the wood. Ideally, you'd start to see that the solid lines of the wood are actually a marbling. As you get closer, you should be able to make out the ringed texture from cutting. Even closer and all you see is the roughness of the surface.

an important question about generated stuff is how much is random and how much is predetermined. Random is more interesting, but different each time unless the result is stored. There is a balance to strike here. Personally I like the idea that the detail doesn't exist until you look at it (generated), but that detail needs to be remembered for the next time you look at it so it's the same. I suppose it could "age", and old stuff cleaned out just like our own memories. I remember thinking about these issues when I first played Ultima, in 1985...

Re:Quality

[AKAImBatman]

Ah hah! Now I understand why the Infinity FAQ has an answer to this very question.

Procedural is not the same as random. Procedural is a set of parameters that can be mathematically unfolded into a large amount of information. Random is a set of numbers that are unpredictable by nature. The confusion probably comes in because many Procedural methods use pseudo-random number generators. However, a pseudo-random generator is not random. For a given seed, you will always get the same sequence of numbers.

The seed is usually one of the parameters used to decide the look of the texture, so there ends up being nothing random about procedural texturing. :)

Re:Quality

[Profound]

static : procedural is a time/space tradeoff. Graphics card technology is starting to bottleneck on bandwidth between insanely fast procecessors so in the future it looks like procedural will see the advantage tipped its way.

But there is also the business side of it:

Static looks as the designers indented it, can be made by artists (though requiring a lot more work)
Procedural requires surrendering some design vision to randomness only works on some things and requires more programmer time.

Pretty cool though, the future is definitely "Here's how to generally describe wood grain" rather than woodgrain_72.bmp

Re:Quality

[mikael]

The techniques are called "texture analysis" and "texture synthesis". Before the advent of framebuffers in the late 1960's, psychologists tried to understand the human perception of texture. After this time, many researchers have tried to find ways
of synthesizing new textures from existing textures, particularly from aerial imagery. These have included quilting methods (copying and pasting small bits of texture from one image to another larger image). Other methods include using the FFT to convert an image into its equivalent sum of sine waves. Wavelets try and break down an image into a frequency distributing of a particular shape (a lunar surface could be reduced down to a crater shaped heightmap and a frequency distribution). However, on some occasions you want to preserve repetitiveness (brickwork), while on others you don't want such an effect (terrain, oceans). A good way to avoid this, is through the use of Wang tiling which allows short range repetition, but prevents long range repetition. Basically, you want a texture function that gives you the same colour/normal/height for the same texture coordinate each time. The most practical ways so far are the use of Perlin noise functions. There are also advanced lighting models which factor in the direction of the light source, the viewpoint, and even subsurface scattering.

Re:Quality

[KDR_11k]

The first and foremost issue is describing the texture. It can get VERY difficult to describe a surface. Describing woodgrain is not enough, that'll just end with an artificial-looking block. You need to add construction details (e.g. nails), wear and tear and lots of irregular shapes to avoid monotony. Very few surfaces in a professional CG image use procedural textures, almost all of it is handpainted because procedurals look bad at their current state of development and developing procedurals that are complex enough to generate a good result would take months to make. Especially for irregular surfaces that aren't of a consistent texture (e.g. people) your algorithm would get complex as all hell because you'd have to account for every part of the surface.

Currently it's just VASTLY cheaper to paint textures by hand.

Re:Quality

[russellh]

The seed is usually one of the parameters used to decide the look of the texture, so there ends up being nothing random about procedural texturing. :)

There ya go. I think I have always just assumed that this would end up being... boring. because they shouldn't be all the same. but then, this is jumping a bit ahead of the game.

Creation issue

[sammyo]

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:Creation issue

[A beautiful mind]

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

[Andy_R]

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.

Re:Creation issue

[RightSaidFred99]

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:Creation issue

[iainl]

Really? I could have sworn I played around with procedural textures in Bryce. But that was at least 8 years ago, when one of the mags had version 3 on a coverdisk.

Re:Creation issue

[SoapDish]

Maybe you should read the interview more closely (I know that this is slashdot).

The point has been addressed:
1. There are tools out there (this technology is old).
2. Several other companies have had tools for a while, but his method uses waveletts instead of fourier transforms.

The whole Photoshop plug-in thing is missing the point, because procedural graphics are very different from bitmaps. Photoshop does bitmaps. Also, converting a procedural texture to a bitmap defeats the purpose.

Re:Creation issue

[oc255]

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:Creation issue

[jackbird]

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 for an excellent (albeit slow-rendering) example.

Re:Creation issue

[A beautiful mind]

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 texture definition file editor is nothing to do with images. You could technically integrate such realtime editor into Photoshop, but what would be the fricking point? You couldn't use the normal photoshop tools with it anyway. TFA mentions that the company this article is about created a end-user tool to do the work easily anyway. Correct me if I'm wrong.

Re:Creation issue

[AKAImBatman]

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:Creation issue

[Deliveranc3]

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.

Re:Creation issue

[Control Group]

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.

Re:Creation issue

[AKAImBatman]

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

Re:Creation issue

[Dunbal]

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:Creation issue

[arose]

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

[Control Group]

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.

True - but the original question wasn't whether Photoshop would be the ideal tool for technical reasons, but whether it could be incorporated into Photoshop because that's the tool artists already know how to use. Or, more generally, the question was: are procedural textures something current artists could learn to create fairly easily, or would they have to become "programmers lite"? If the former, then procedural textures could start cropping up in titles. If the latter, the uptake will be a lot slower.

While Photoshop would add nothing to the procedural texture designer, it might still be worthwhile from a UI/learning curve standpoint.

Re:Creation issue

[AKAImBatman]

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:Creation issue

[modeless]

There is no reason the set of functions used to generate the procedural texture couldn't be exactly the tools that Photoshop provides, and the arguments to those functions the mouse movements and other inputs the artist gives to Photoshop. Then Photoshop would be exactly the right interface for constructing procedural textures.

Basically you would just save out the entire Photoshop undo history to a file and use it later to reconstruct the image. Of course, unless you're Adobe, reconstructing the image would require reimplementing Photoshop. But perhaps the GIMP or Krita could be modified in this manner.

I would be very interested in seeing how large an image constructed in this manner would be and how fast the reconstruction could take place. It would be possible to take so many actions in painting an image that the procedural description would be longer than the output bitmap. But I have a hunch that for most images that would not be the case. Artists could also deliberately use painting styles that are more efficient.

Re:Creation issue

[sammyo]

I don't get it... Well actually I do.

Ok, who uses the tools?

Who creates images/textures?

Who creates a cutting edge killer game with NO ARTISTS?

How many artists have high expertise developing algorithms?

Artists. Not programmers.

How many tens and hundreds of thousands of great textures have been developed by programmers? Not
a couple neato keen demos. High volume, rapid turnaround production?

Sheesh, yes I'm slightly off topic if the only issue worth discussion is the relative performance
between FFT's and Wavelet computation. Artmatic looks really great for the creation of
alien landscapes, but I'd love it if their tool had some natural environments.

Realtime procedural textures are quite cool, but there is a bunch more *standard* infrastructure
that will be needed before the revoloution occurs. It's a another example of probably great
technology that will go nowhere due to misunderstanding the user base.

Re:Creation issue

[sammyo]

Yes, we understand what a proceedural texture is. You are not listening, that is not what we are talking about.

How many *Artists* have used your 'Perlin code sitting around on my hard drive' ?

How long would it take you to develop an intuitive UI? Intuitive for an artist, that is.

Re:Creation issue

[mjtaylor24601]

"I still have my own Perlin code sitting around on my hard drive"

That's all well and good for you but the problem is the artist whose job it is to make the texture look right is (most likely) incapable of understanding the complex mathematics and programming that would go into designing the procedural texture algorithm.

The current problem with procedural textures is that it requires someone conversant in wavelet / Fourier mathematics and programming in order to be able to generate them. They won't be of much practical use in industry until we can develop a way for artists to deal with them. This is thrust of the original question. What mechanisms are there for manipulating procedural textures that might be usable by the average game artist?

As I understand the issue what you would need to do to make procedural textures useful in a general sense is have some programmers who are fluent in the requisite mathematical and programming aspects to come up with a generic library of procedural texture algorithms. You could have a set of procedures for stone textures, another for wood grains, others for marble, and so forth.

Each of these procedures would have a set of input parameters that control what the resulting texture looks like. In order to be useful to an artist there needs to be a mechanism by which an artist can manipulate these input parameters and view the results to see if they've got the texture looking the way they want it.

This is what would require a "photoshop plugin". The artist would open up photoshop (which in this hypothetical example is the tool they are familiar with) select which procedure they want to use, and be given some widget that would allow them to manipulate the input parameters (via sliders for example, as was suggested above) and would show them the resulting texture (perhaps mapped to a sphere or cone or what have you). Once they had the texture looking right, they would "export" the texture, which would in effect just save which procedure to use and the value of each of the input parameters.

As a side note I think the GP understands the concept of procedural textures just fine, and I don't see any need to insult him/her.

Re:Creation issue

[AKAImBatman]

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.

Re:Creation issue

[AKAImBatman]

That would be a procedural tool on a very different order than the ones being discussed here. :)

Re:Creation issue

[Achoi77]

This arguement is a prime example of what happens when an individual with an artistic mentality goes head to head with one with scientific mentality, thinking that they are discussing the same thing. Unfortunately the original poster came up with a question that was poorly worded and was interpreted different by different parties.

The OP was never asking about how to generate bitmaps. What he was asking was whether or now there could be a method for an *artist* to come in(that has no understanding of how the texture is generated) and create good looking textures. The reason why photoshop was mentioned in the first place, was merely because it's a tool that a LOT of digital artists have on their computer - which would mean from a marketshare/distribution standpoint, getting them to install a plugin would be less intimidating (and more marketshare penetrating) than having them install a whole new app that does the same thing. Nobody is talking about going into photoshop and applying a couple of filters to a bitmap and then saving it to a file. I beleive what they are talking about is using photoshop as a tool to see how the artist's tweaks to the procedure will result in an appropriate texture generation that will suit the artists's needs so that the artists can show their project manager in an experience that is familiar to them - albeit which is not the 'natural' way a user would be using photoshop in the first place, but in the business world, familiarity counts.

Telling the computer to "create me a partially reflective white hardtop marble surface with some scratches made from a shopping cart, with EXTRA grit and grime" may be a cool (and beautiful) novelty at first, but over time if every game uses the same generation then there is going to have a certain look of generic artificiality that truly lacks an 'artists touch.' I don't mean "use less grime" or "this portion dirty and this portion coated in blood," I mean certain stylistic decisions that cannot be easily deciphered by concrete values.

And to reiterate what the above posters have stated, photoshop's text editing/layout tools have indeed come a long way. It even has a spell checker. I'm pretty sure you _can_ download wordprocessor plugins for photoshop - which does not necessarily make it a good idea. But it is entirely possible. :-P

Re:Creation issue

[McCaliber]

When the full potential of procedural texturing is realized in gaming, it will all but remove the need for a dedicated texture artist.

Unfortunately, you have to replace your dedicated texture artists with just as many dedicated procedural texture artists. Or even more expensive engineers cranking out procedural shaders with exposed sliders for the artists to tune.

Re:Creation issue

[LordKronos]

That artist is going to need a tool to do so. This is the question the original poster posited: will the tool be something that artists are already or could easily become comfortable using,

So how could they be comfortable in Photoshop in such a way as to apply to procedural textures.

They are comfortable with how to draw the texture? doesn't apply to procedural.
Comfortable enough to know how to clone, dodge, and burn? Doesn't apply.
Comfortable with applying layer masks? doesn't apply.

About the only concept of Photoshop that would be remotely applicable to procedural textures would be adjustment layers. And why is that? Because adjustment layers are just a couple of sliders. So sure, it could be done in Photoshop as a bunch of adjustment layers. But now you are using a tool where 99% of the tool's features are not applicable to the task at hand, and the 1% that does apply is severely sub-optimal for the task at hand. In much the same way that Photoshop's text tool would be severely sub-optimal for word processing.

There is a very good reason why 3DSmax and Maya are NOT plugins for Photoshop. That reason applies to procedural texturing too.

Re:Creation issue

[Anonymous Coward]

I can see that photoshop might be a familiar environment, and you could write theoretically anything as a photoshop plugin. But for tweaking the parameters of a procedural texture algorith, how the heck would that work?

I guess you could display a couple of sliders, buttons, and floating-point number input fields. And then... how would you show the results? You'd need the plugin to be actively rendering the texture onto some surface... so now you've got some sample 3D models and a whole bloody raytracer to show you some examples of how your texture might work... Now I don't know how much of this can be handled in the Photoshop core (I use the Gimp lolz). But I suspect this would destroy the convenience and familiarity benefits of using Photoshop as a base platform in the first place?

Re:Creation issue

[Lerc]

Actually this is the only part of the issue that chould have any impact.

fr-08 fr-019 and a decent number of 64 k demos have shown thad good quality and small size is obtainable. Even older there are procedurally generated data in 8 bit games. That wasn't so much revolutionary as obvious that you'd be an idiot to try and store things in raw data form.

I don't know how people can present these ideas as something new and wonderful, It's more like they are finally getting around to doing something that they should have done some time ago.

The only two things that should be a factor are, Speed of image generation and ease of texture design. Speed solves itself over time, especially when you start getting multi-core when you have a nice task bundle like 'generate texture X'.

There needs to be good tools for design. Some exist now. More will exist soon. I would have started an open source one myself a while back except for may 'must not start another project' mantra.

It bugs me a little though to see obvious things become standard once a critical mass of PHBs become aware of them. I welcome the change, I just hate the obvious being called revolutionary.

Re:Creation issue

[arose]

While Photoshop would add nothing to the procedural texture designer, it might still be worthwhile from a UI/learning curve standpoint.

No it wouldn't be, the designer wouldn't get any more familiar just because you call it via a menu in Photoshop, it would use none of the Photoshop's tools or workflow concepts.

Or, more generally, the question was: are procedural textures something current artists could learn to create fairly easily, or would they have to become "programmers lite"?

Not only could they, but they already do. Many 3D programs incorporate procedural texture designers and good 3D artists use them. Artists not familiar with them however will probably need to aquire a little more technical knowlage to design procedural textures efficiently. OTOH people who are familiar with Photoshop or other bitmap editors will find that many non-drawing concepts translate well into the new domain--noise generation, layers, gradients, etc.

Re:Creation issue

[smallfries]

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.

After your long-winded argument with the other two posters I think that you've browbeat them into submission. But you are still wrong. I don't think anyone in this thread thought that procedural textures had anything to do with bitmaps, you've brought this up as a strawman. The real question, as you well know, is what kind of tool would an artist like in order to generate procedural textures?

Here's a clue. It's not a source-code editor. I've done work in both procedural texuring, and procedural geometry and I use a text editor. But I'm a programmer and my efforts look pretty shit. So it is some kind of GUI editor as you agreed above. But do artists like learning new interfaces? Or new applications? Or are they quite happy and quite comfortable in a world where everything looks like photoshop?

So although the texture itself is not a bitmap, approximations of it that an artist can see and manipulate will be bitmaps. The tools to manipulte it will seems to be a mixture of vector and bitmap(y) operations. Artists don't want to randomly adjust sliders that control the coefficients of an equation until they get what they want. They want to paint some colour operations over a bitmap and have the editor find the some coefficients that do something like this at this particular level of approximation. And yes, I know just how hard that problem is, but it does not mean that a photoshop plugin is impossible. And it would certainly aid adoption of the technology, so a shit version may spring up for other reasons.

Re:Creation issue

[KDR_11k]

A problem I see is that it would probably be smaller filesize-wise to just store the resulting image instead of all the operations involved since a proper artist will do a VERY large number of strokes during the entire process. Never mind what happens when they photosource.

Re:Creation issue

[KDR_11k]

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

We call those "JPEGs", you may have heard of them.

Re:Creation issue

[Anonymous Coward]

Read ControlGroup's post (currently at -1 Troll)

And if you're going to show images on the screen (AKA bitmaps), then suddenly it seems a lot closer to Photoshop's core functionality than writing a memo does.

He's an idiot, and so were the people defending him.

So although the texture itself is not a bitmap, approximations of it that an artist can see and manipulate will be bitmaps. The tools to manipulte it will seems to be a mixture of vector and bitmap(y) operations.

Now you're just making stuff up.

Re:Creation issue

[Briareos]

Basically you would just save out the entire Photoshop undo history to a file and use it later to reconstruct the image. Of course, unless you're Adobe, reconstructing the image would require reimplementing Photoshop. But perhaps the GIMP or Krita could be modified in this manner.

Fractal Design^w^wMetaCreations^wCorel Painter allows you to record all or part of your drawing session as a macro (or do this automatically when you open a new image) which allows you to play back the file and watch the image being recreated, or stop at any point and tweak the parameters used in the macro, reorder the steps or add new ones.

A macro recorder that produces a script-fu script while working could probably do something similar for the GIMP.

Quite nice, but probably not useful for generating real-time procedural textures for games, which would need to be shader programs that the hardware can grok directly... :)

np: Underworld - Cups (Beaucoup Fish)

Re:Creation issue

[Anonymous Coward]

THERE IS NO NEED TO BE RUDE WHEN YOU USE THE INTERNET.

I think that an artist might well be using Photoshop on a project involving procedural texture generators. Photoshop is the swiss army knife of computer art: if nothing else, it's an image viewer. Most likely, it will be used to edit other graphics related to the project.

I think that, if you wanted to sell a procedural texture generator tool, the label "Includes Photoshop Plugin" would be a big selling point. I think it is something than an artist would want, even though any attempt to edit a generated image would invalidate it. I would want Photoshop and GIMP plugins for a procedural texture generator, because that fits neatly into my existing software. Or is that just a stupid idea?

FWIW both Photoshop and GIMP do already appear to include procedural image generators (plasma, clouds, fractals).

Re:Creation issue

[Control Group]

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.

Anything you display on the screen is a bitmap. There's memory inside the computer, see, made up of "bits", that "map" to pixels on the screen.

This is a bitmap. And if you're going to show the artist the texture, which I predict most artists are going to want, then you're going to generate a bitmap.

I don't give a flying fuck if it's mapped to a sphere, a toroid, a spatula, or a p-brane: if you're showing it on the screen, it's a bitmap.

Will it decrease loading times?

[CastrTroy]

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:Will it decrease loading times?

[Anonymous Coward]

Loading times will be reduced, yes. But you'll need a VERY beefy machine to render textures in realtime at a reasonable framerate. I think the solution to this is a dedicated processor for nothing but textures (not a GPU, but an even-more specialized processor). Video cards in computers may eventually include those, but I think they'll be beaten to the punch by the console makers (Nintendo, Microsoft and Sony). Sony is already halfway there, with the Cell architecture, they just need a processor optimized for rendering textures on the fly.

From what I've heard, all three console makers are heading towards the Cell archtecture for their next-generation systems (the ones following the 360/PS3/Wii), and I think that by that point Sony will have figured out most of the programming issues associated with Cell. If games are already filling up expensive Blu-Ray discs, they'll be eager to find something that's more efficient. I think Sony is being a trailblazer (with its PS3) for the other console makers, either by showing them how NOT to make a console, or what the future is. I'm of the opinion that the Cell _will_ take off, but only by the time the next generation of systems comes around. At that point we'll all thank Sony for working out the kinks in the Cell architecture, and for making procedural textures standard on all consoles.

Re:Will it decrease loading times?

[tfinniga]

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 via some mix of procedural and data driven.

Re:Will it decrease loading times?

[CryoPenguin]

Kind of like how it takes less CPU power to decode a WAV file than to decode an MP3 file.
On a decent computer, decoding an MP3 takes some fraction of a percent of the cpu (here: Athlon64 2.4GHz, 0.4%). It is in fact faster to read and decode an MP3 than it is to read a WAV off my harddrive.
That said, I understand the point you were trying to make, and I can't say which way the tradeoff goes for the procedural graphics being discussed.

Re:Will it decrease loading times?

[CastrTroy]

It becomes more apparent when talking about slower computers, as newer computers don't even take a hit when trying to decode mp3, but trying to do the same thing on a 486 would have made the music unplayable. I remember trying to play mp3s on my 486, and they skipped like crazy. If the result of procedural texture is decreased frame rates, like some posters have already have pointed out is a problem, then I don't see how it would really help in this generation. However, I'm sure future generations of consoles with faster or dedicated processors will gain a big advantage by using this technology. The best thing about it is if you have a faster processor, or want to wait long enough, then you could upgrade the graphics in a game, without buying the game again.

Tradeoff...

[HaeMaker]

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.

Re:Tradeoff...

[CheShACat]

I think this kind of response shows a flagrant lack of understanding of how computers even work. Have you ever heard of a bottleneck? Regardless of how trends may or may not continue, the average current PC is facing such a tiny bottleneck on disk loading time compared to the amount of processor time available. I have a *very* low end dual core PC, yet it is still difficult for me to max out my processing power for any kind of sustained amount of time due to the amount of effort it takes my (hardware) Raid 10 array to do its thing. Procedural textures are long overdue, there has been an increase of thousands of percent of processing power in the last few years, but compared to the shift from say 100MB/sec UDMA to 300MB/sec SATA2?? Are you kidding???!!!

"Elite" used this technique over 20 years ago

[Andy_R]

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:"Elite" used this technique over 20 years ago

[91degrees]

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

Did this generate the data on the fly then? I always assumed that it generated the landscape at the start of the level and would just draw from a buffer during the actual game.

the PS3's Cell architecture is supposedly ideal for doing this kind of thing

It's true that parallel systems work well for this general class of tasks. Something as general purpose as a Cell may be overkill. You can do quite a lot just with programmable pixel shaders.

Re:"Elite" used this technique over 20 years ago

[RightSaidFred99]

You're not following. This isn't about using procedural techniques to generate maps, 3D graphics, or anything else. This is specifically textures. Meaning instead of drawing a picture of e.g. rust or cracked glass and layering it on 3D model, they generate the picture algorithmically.

So it's more specific (and difficult) than what you describe, and most certainly wasn't done in 1984.

Re:"Elite" used this technique over 20 years ago

[jackbird]

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

Re:"Elite" used this technique over 20 years ago

[rev063]

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:"Elite" used this technique over 20 years ago

[mrchaotica]

I'm sure you know, but for the benefit of everyone else the technology used in Oblivion is SpeedTree.

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

[GreggBz]

Watch the video's. Amazing. Infinity

More benifits then just game size..

[GfxGeek]

Quality of texture is a huge advantage of procedural textures, not just for the fact that they don't pixelate as you approach them, but your ability to multisample is limited by computation speed, not bandwidth. Which brings up the biggest advantage of procedural textures: Bandwidth For every pixel that is written to the framebuffer, hundreds (if not thousands) of bytes are read from memory in texture sampling. Scaling the clockspeed and adding more processing cores is easy and cheap, increasing bandwidth is expensive.

Re:More benifits then just game size..

[slipster216]

But thats not how things are done in games - the textures are generated, then cached as traditional textures for use on the video card. So you don't have any quality benifit from procedural techniques, and in most cases loose quality because an artist cannot simply grab the brush and paint some pixels. If procedural textures are going to become a mainstream in game graphics, it's not going to work the way it does now. These approaches are mathmatical in nature, and require a special kind of thought process which is quite different from how artists trained in traditional painting think. Additionally, we have more than enough storage on modern hardware, and more on the way, so it's not like we'e hurting for space or anything. If these textures were being generated on the fly, per frame, then they might offer some advantages, but thats not really a good use of the processing power right now.

Re:More benifits then just game size..

[sowth]

Procedural textures can be created by the GPU, so creating them on the fly is not as big a problem as you think.

No shit you will need "artists" who know how to create procedural textures rather than someone who uses photoshop. Why the hell are so many bringing this up as if it isn't obvious. Do you people work for the government or something?

Would you take someone off the street who happens to know how to sculpt clay and ask her to make 3d model on a computer? I don't think so. It has about as much chance of working as you getting a bj from a CEO.

Re:More benifits then just game size..

[KDR_11k]

Would you take someone off the street who happens to know how to sculpt clay and ask her to make 3d model on a computer?

Actually, yes. Once that person learns how to work their 3d application the knowledge transfers easily. Anyone can mash clay together, almost everyone can make a stick figure out of it but only an artist can make it look exactly the way it should look (for sufficiently complicated objects, that is). Knowing how detail is created, how anatomy works, etc is the important part, the tools are just the way to write it down. I've seen people go fluently between digital and "analog" art simply because the basic understanding of art applies to any tools.

The biggest problem with that transfer is that artistic ability and mathematics use different halves of the brain, an artist trains to use his right side as much as possible (since the left tends to abstract details away and thus mess up the result) while math needs the left one. That will probably end in severe confusion.

More cores lend their aid

[everphilski]

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:More cores lend their aid

[AKAImBatman]

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 why procedural generation is so popular in Raytracing. You can simply and easily punch in non-integer coordinates for each pixel to always get the correct value. There's no need to interpolate an image, and the result looks just as good no matter what your angle or distance is.

Details?

[Tom]

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:Details?

[AKAImBatman]

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 understand how real-time procedural texturing can work.

As a result, the cost of generation will vary depending on the procedure used to generate the texture. Perlin Noise is a fairly fast algorithm that can be used to generate marbled textures. You might consider studying it to come up with a good feel for how many computations per pixel would be required.

Of course, if the desire is to simply shrink the size of downloads, then the cost of computations doesn't matter. One could quickly and easily generate all the textures needed when the software is installed, then forget all about procedural texture generation.

Re:Details?

[modeless]

You are quite mistaken if you think that's how people are proposing to use procedural textures in games in the next few years. It's all "generate bitmap in main memory, upload texture to graphics card" right now. Per-pixel procedural textures for realtime graphics are a long way off.

Personally, I'm not sure it will ever make sense to do per-pixel procedural textures. Why would you do computations every frame when you can do them once and amortize the cost over hundreds of frames? That way you can use hundreds of times more processing power per generated texture pixel and get nicer textures. You can still get the benefits of reduced storage for textures you don't currently need on screen, and you can still get the benefits of being able to generate any resolution texture you want. As long as texture memory is big enough to hold all the textures you need for a few frames at once, there's little downside.

Blu-ray?

[JFMulder]

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.

Re:Blu-ray?

[Anonymous Coward]

They have to keep the ISOs fat so that people are deterred from downloading the games instead of buying them. Probably the best is to use procedural textures (for fast loads) and store multiple encrypted copies of a 4 GB game on a 25/50 GB disc. Each time the game needs a piece of data it loads one of the copies at random on the disc. To "compress" the game from 50 GB to 4 GB crackers would need to find and remove the decryption and load-randomization code.

In a nutshell...

[InfinityWpi]

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

From the itsatypo dept.

[Control Group]

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

Re:From the itsatypo dept.

[gold23]

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

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

Re:From the itsatypo dept.

[sneakybastige]

I do so abhor tinny graphics. Oh, how I do appreciate a good, woodsy graphic instead....

Re:From the itsatypo dept.

[ensignyu]

Actually, I think "tinny" might be a good description of procedural graphics as they are now. How do you create a formula that looks natural? It can create a decent approximation, but not quite perfect if you look closely. So it's "tinny".

Re:From the itsatypo dept.

[KDR_11k]

Yes, they're all plasticky nowadays.

Prerender

[Anonymous Coward]

It's slower to load, but in action it's just as fast as 'normal' textures. The only difference is the texture being rendered was generated on your machine during the game's loading sequence instead of in photoshop on some artist's machine. They're both just pixels when it gets to drawing.

Re:Prerender

[bestinshow]

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.

Remember Tron?

[Anonymous Coward]

Didnt they use these same techniques in Tron?

Old trick, and some misconceptions...

[kbonin]

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 texture from disk, generally in one of the dds formats, then upload the desired subset of pregenerated MIP levels to texture memory. With procedural textures, you generate the texture (and the needed set of MIP levels), and upload them to texture memory. There is no need to regenerate and reload them unless someone decides to flush texture memory. The only time difference is disk load vs. generation, and you (generally) do that once.

Spore

[BigZaphod]

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.

Patenting math.

[Anonymous Coward]

"We have the most powerful, modern and patented approach and on the engine side, we are the only ones to propose an engine for next-gen consoles and PCs. In conclusion, the market exists, but as Torsten Reil (CEO, Natural Motion) says: "Allegorithmic is the leader in real-time texture synthesis"."

Let the patented math flamewar commence.

Console addendum

[Jerf]

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 due to lack of hardware support.

Then again, it may not be so bad. Hard to tell without knowing more.

Has anyone tried...

[Anonymous Coward]

One of the things I like about procedural textures is the ability to cut down on the repetitive look of normal textures. In that vein, has anyone tried using multitexturing and scaling textures by prime numbers or otherwise modifying them so that the tile edges don't line up very often? I haven't gotten around to trying it myself, how did it look?

kai's power tools

[Speare]

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]

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.

Re:kai's power tools

[bumchick]

Great post, thanks.
I never used procedural texture tools, but it seems creating a large library of textures using the 'explore' approach, and selling the library as middleware, could be perfect for many game studios.

Re:kai's power tools

[Chris Burke]

I know exactly what you mean about Kai's Power Tools, which was more like a kaleidoscope than actual image editing tools.

I think that in general, though, the constraints on texture artists aren't that great. The art director may call for "wood paneling", but isn't going to necessarily want a particular species of oak. In fact, a randomly-happened-upon wood grain that looks nice may be better than one designed to look like a particular grain. Seeing as how today textures never have enough detail to convey pine vs maple, I don't see it being a big issue in the future.

At the same time, for things which do have very particular desired results, procedural textures probably won't be used. For example, in your Chanel No 5 ad, the gaunt 30-somethings would be done traditionally, while the mosaic floor might be done procedurally. Character models and such are going to continue to be done in the old way.

Re:kai's power tools

[ockegheim]

I think that once there are tweakable libraries of textures that are useable by artists, procedural textureing will really take off.

Re:kai's power tools

[BoberFett]

Perhaps, perhaps not. Given a title like Grand Theft Auto where there are hundreds of nameless victims... errr.... models walking around, there is no reason that most of them need to look a certain way. Given current limits of memory/storage/bandwidth however, there are only a handful of models which each might have a handful of handful texture sets. The end result is that when you look down the street at 50 pedestrians, you see identical sextuplets walking toward you.

With procedural modeling and texturing, you can describe these characters with a single algorithm and simply seed it differently to get completely different results. They can all have unique hairstyles, clothes and skin without the need for hundreds of megabytes worth of models and textures. Then take that and apply it to all the objects you see. There will need to be some static art, things that algorithms may not be appropriate for such as signs. But those can be layered with other procedural textures to create unique looking objects. A gas station on the bad side of town could be identical to the one in a good neighborhood, but just given a grime factor and the correct textures are generated on the fly. Two of the same car, but one hasn't been washed in months and is covered in mud. That can be done to an extent with current graphics techniques, but it doesn't have nearly the flexibility of a procedural system.

That's where the next big jump in suspension of disbelief will occur. Not to mention the massive art creation savings that game creators could see.

Use texture synthesis, right now!

[Anonymous Coward]

Way superior image quality and way easier to controll.

Basically you take a existing texture and generate as much new texture as you like. On the GPU. With 80 fps. http://research.microsoft.com/~hoppe/apptexsyn.pdf

De Guy's in trouble

[Anonymous Coward]

Allegorithmics have been hawking their wares for a while now and still only one game uses it.

I like their tech but it's not what artists want. They want compression, not some new abstract way to generate really efficient textures which they don't have full control over.

It's like they bring a digital audio model to digital video (literally, compare their tool with Reaktor - it's the same basic idea). But the domains are too different. You have to synthesize (or sample) audio because that's where the conceptual space is - a waveform editor is useless for creating the sound you want, but filters and modulators make sense. But the conceptual space in video is in each pixel, not in some algorithm which relates them via abstract mathematical functions.

I've always thought this stuff would be useful if you didn't have any artists, but since artists are about 1/2 the cost of programmers I think it's an evolutionary dead-end.

So - future of video games? I doubt it.

CUDA

[lagfest]

I would imagine something like nvidias CUDA may do wonders for generating procedural textures.

'Feature', not 'future'! ;-)

[Anonymous Coward]

'Feature', not 'future'! ;-)

Not only textures

[ichigo 2.0]

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.

Xbox 360

[flitty]

Before the 360 release, didn't Ars_technica have an article on this procedural synthisis? I remember reading about a forest where you defined basic principles of the forest, then it is randomized and created realtime in the architecture of the 360. I remember they talked about how they focused on this during the development. Am i wrong here?

Not procedural: Simply, compressed.

[TerranFury]

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.

MOD PARENT -1: STUPID

[Anonymous Coward]

Ever hear the saying, "Just because you can, doesn't mean you should?"

This is probably slow as hell.

[Ant P.]

Actually, despite what a lot of replies are saying it's exactly <a href="http://en.wikipedia.org/wiki/Embarrassingly<nobr>_<wbr></wbr></nobr> 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.

Re:This is probably slow as hell.

[Ant P.]

aagh... that's the last time I mess the HTML up. I swear.

Why do this in a 2D art package...

[tjwhaynes]

... when it is already available in most 3D design packages?

If you have used a 3D package (Blender, Maya, etc.) the first time you texture a model is probably done with a procedural texture. If you have special needs for a texture, then you might start thinking about UV mapping or projection mapping. If you just need rock, grass, water, wood or skin, reach for the procedural materials first and worry about overlays later.

Now there is a gap to be filled between the material properties available in a 3D editor and the rendering of the world in a game engine but it's hardly a wide one to fill. For an open source package like Blender, the gap is narrowed further by the ability to see precisely how the materials are calculated in the editor. I suspect that there already exist such capabilities in the high-end 3D graphics toolkits.

Cheers,
Toby Haynes

Re:Why do this in a 2D art package...

[Control Group]

Then that's also an answer to the question - artists can use their current tools, they'll just shift texturing from one current tool (Photoshop) to another current tool (Maya).

Nobody mentioning Demos yet?

[Etcetera]

In all these comments? Sheesh, and I thought you guys were nerds :)

Demos have been doing procedural textures for years... almost a necessity when you're trying to squeeze x number of minutes of... stuff into a 64k binary file. Take a look at fr-08: .the .product by farbrausch for a pretty stunning example of the amount of compression you can get when you need it. They've also got a proof-of-concept FPS that uses all procedural textures and fits into a 96k binary.

They've even released a tool for procedural generation publicly.

Given the benefits of procedural generation in terms of space, I wish more games would look into using them... especially online MMORGS or other situations where bandwidth is an issue. It's probably faster and more efficient on a decent CPU/GPU to create procedural textures than it is to download a bzipped version thereof. (Nudge: Can someone at Cyan Worlds please hire these guys as interns?)

Re:Nobody mentioning Demos yet?

[Etcetera]

Wow... so how did I comment on this story while totally missing what was already put in the summary -- and TFA? No more posting before coffee. =/

Procedural Generation doesn't work like that.

[kinglink]

At least it doesn't work right, or well like that.

Play Just cause and Oblivion. Which one uses Procedural generation.

Answer: both of them. Just causes uses it for almost everything, it has 300 square miles of land, that while it's all procedurally generated, they did NOTHING with. The ground looks like crap on the 360, the gameplay is about the same all over the place, and the buildings are.. well sparse and dull.

Oblivion has 16 miles of land. Oblivion doesn't use it for everything. However every tree is done with procedural generation and it looks good because trees arn't important. Have an important tree? You can toss it in there too along side procedurally generated trees.

The secret is to use Procedural generation in moderation, and to have a back bone of the game that works well with procedural generation. This technology isn't a new technology, it's just the new buzz word. However it isn't needed and hardly worth using most of the time unless in special cases (speed tree for instance).

The biggest problems with Procedural generation is it's "heavy" it takes up a decent (not large but hardly inconsequencial) amount of CPU time, and for the most part it produces lackluster items on large scale. It is all based off math, and for it too look good you need something with a very specific formula. For something to look unique you need a randomize or multiple formulas. This is hardly a beginner theory, and hardly something that every game company should devote resources too.

With expensive CPU operations, we can come back to "but we have 6 threads". And we do. But each thread isn't 3 gighertz, it's 1.5 gigs or less (forget the actual number). Walk into a new area it has to procedurally generate the area, which means a load time. It can be done on the fly but now that's a new complication that could go wrong. We already are throwing one or two processors to GPU functionality in many engines, another one should go to physics. another one to gameplay, one to interface, and then anything else special you want to do. With Procedural generation you're talking about a bigger bottleneck in the processor, lower DMA times, but the simple fact it won't save the day.

The bottom line is this. Procedural generation works, but needs a lot of work to look good, and even more work to work well. As such it should be used sparingly, though middleware like speedtree. Full scale games based solely on it are still a bad idea (such as Just cause).

Yeah, lets go back to 2d!

[sowth]

Why would you do computations every frame when you can do them once and amortize the cost over hundreds of frames?

Okay. Why would you do computations for 3d all the time, when you can just create a RGBA bitmap once, and move it around the screen/ zoom all you want? It certainly would cut down CPU usage. Why have 3d acceleration at all?

The answer is it looks better. The main reason it is in the "generate bitmap, upload to vid card" stage is more because enough programmers aren't experienced with using the GPU to render proc textures and such. Many probably don't even have access to the specs to program the GPU at all.

Re:Yeah, lets go back to 2d!

[modeless]

Your analogy is spurious, and your "answer" isn't convincing. Care to explain what exactly makes a per-pixel procedural texture "look better" than one precomputed with sufficient resolution (but still procedural), when you can spend 100+ times more processing power on the precomputed one?

I can see per-pixel procedural textures being useful if the texture is changing rapidly. But for the vast majority of textures, precomputing makes so much more sense. It allows you to do computations that simply aren't feasible to do per-pixel.

Re:Yeah, lets go back to 2d!

[BoberFett]

I can think of one very good reason, variety of textures. The same algorithm with slightly different variables plugged in. Games are beginnning to require massive amounts of texture data. 2GB of main memory will be required to run things smoothly soon. The new top Nvidia card has 768MB of RAM. And still there are repeating textures everywhere: buildings looks the same, sections of tile, walls, windows. This takes the gamer out of the game. The more varied the environment, the more believable it is. To increase texture variety using the current design methods requires not only more and more memory, but more artist time. In the interest of lowering art costs and increasing quality games are starting to generate trees and foliage procedurally. The same will happen to textures.

Re:Yeah, lets go back to 2d!

[modeless]

I'm not arguing against procedural textures in general; they are the future of the game industry for sure. I'm arguing against calculating them on-the-fly in pixel shaders as opposed to precomputing them at load time and storing them as bitmaps in texture memory. That doesn't prevent you from using procedural textures to provide variation. You are slightly constrained in how much variation you can show at once by texture memory, but it's not a huge restriction considering how big texture memory is nowadays (since it often has to hold an entire level's worth of non-procedural high-resolution textures because it takes too long to load them and only one resolution is available to load).

Re:Yeah, lets go back to 2d!

[sowth]

Calculating on the fly creates many "natural" variations in the visual. You'd need some huge bitmaps to hold anything remotely similar in appearance. Even then, close up views of the texture would be a problem--procedural textures have infinite zoom. In addition, it is difficult to match the algorithm so that it tiles well enough where it doesn't look really crappy.

You don't need to spend 100+ times the processing power either. In the eighties my Atari 130XE took eight+ hours to do a low rez fractal--I think at 320x240 or so. Now my "out of date" computer's CPU (1.8GHz underclocked to 1.2) can do the same julia fractal at 1024x768 in under a second. The GPU would be much much faster because there are many of them in parallel, and most procedural textures aren't quite as complex as a julia fractal. It would probably need only several cycles per pixel on a given algorithmic unit. Considering a GPU core has many units calculating at once, I don't see how it is going to be a huge slowdown over memory hogging bitmaps. Most (if not all) video cards can do texture compression on the fly. That is a processor intensive function too.

Raytracers have been using procedural textures for a long time. I should know, I've been raytracing as a hobby for several years, and I almost always use a procedural texture. If you really must see, I have an account at deviantart. They aren't very good, but many of them are raytracings with procedural functions used on both the color and normals. I don't think they would have turned out as well if I had tried to muck with bitmaps. I have special trouble with getting the tiling to match.

Wavelet patent

[Trogre]

So, anyone know when the patent on wavelets expires?

Does anyone still care about algorithm patents?

Re:Wavelet patent

[Trogre]

Apparently not...

Comment removed

[account_deleted]

Comment removed based on user account deletion