Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Procedural Textures the Future of Games?

Zonk posted more than 7 years ago | from the teeny-tinny-prettiness dept.

Math 132

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

cancel ×

132 comments

isn't it slow? (2, Interesting)

Nf1nk (443791) | more than 7 years ago | (#16794912)

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? (0, Redundant)

WilliamSChips (793741) | more than 7 years ago | (#16794948)

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

Re:isn't it slow? (1)

TheThiefMaster (992038) | more than 7 years ago | (#16794988)

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? (1)

AKAImBatman (238306) | more than 7 years ago | (#16795038)

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? (4, Insightful)

grammar fascist (239789) | more than 7 years ago | (#16795998)

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? (1)

AKAImBatman (238306) | more than 7 years ago | (#16796352)

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? (1)

ezzzD55J (697465) | more than 7 years ago | (#16796898)

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

Prerender (1, Insightful)

Anonymous Coward | more than 7 years ago | (#16795444)

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 (2, Insightful)

bestinshow (985111) | more than 7 years ago | (#16795846)

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.

Re:isn't it slow? (1)

maxume (22995) | more than 7 years ago | (#16797330)

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

Quality (4, Informative)

AKAImBatman (238306) | more than 7 years ago | (#16794938)

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 (2, Informative)

Bieeanda (961632) | more than 7 years ago | (#16795574)

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 (4, Interesting)

Chris Burke (6130) | more than 7 years ago | (#16795590)

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 (1)

Jerf (17166) | more than 7 years ago | (#16795700)

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.

Console addendum (1)

Jerf (17166) | more than 7 years ago | (#16795762)

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.

Re:Quality (1)

OoSync (444928) | more than 7 years ago | (#16796324)

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 (2, Insightful)

Das Modell (969371) | more than 7 years ago | (#16796962)

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 (1)

Red Flayer (890720) | more than 7 years ago | (#16797380)

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 (1)

AKAImBatman (238306) | more than 7 years ago | (#16797690)

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 (1)

russellh (547685) | more than 7 years ago | (#16798944)

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 (1)

AKAImBatman (238306) | more than 7 years ago | (#16799370)

Ah hah! Now I understand why the Infinity FAQ [fl-tw.com] 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 (0)

Anonymous Coward | more than 7 years ago | (#16798288)

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.

Creation issue (1)

sammyo (166904) | more than 7 years ago | (#16794964)

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 (1)

A beautiful mind (821714) | more than 7 years ago | (#16795064)

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 (4, Interesting)

RightSaidFred99 (874576) | more than 7 years ago | (#16795296)

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 (1)

oc255 (218044) | more than 7 years ago | (#16795600)

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 (1)

jackbird (721605) | more than 7 years ago | (#16795602)

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

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

Re:Creation issue (1)

Dunbal (464142) | more than 7 years ago | (#16796370)

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 (1)

A beautiful mind (821714) | more than 7 years ago | (#16795648)

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 (3, Informative)

AKAImBatman (238306) | more than 7 years ago | (#16795716)

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 (2, Interesting)

Control Group (105494) | more than 7 years ago | (#16795924)

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 (2, Insightful)

AKAImBatman (238306) | more than 7 years ago | (#16796236)

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 (-1, Troll)

Control Group (105494) | more than 7 years ago | (#16797086)

You're trying and trying to make a point, but, like a poor marksman, you just keep missing the target.

The simple fact is that you're going to need an artist to design the procedural texture. 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, as opposed to an obscure set of formulas to apply or equations to solve. You describe a tool with sliders and gizmos, which is the answer he was looking for.

We're talking about creating the textures without generating a bitmap at any point in the process.

This, though, I don't believe in the slightest, since it would mean that the artist would never get to see the results of her work. I don't think that's going to cut it in the art creation world. 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.

Do you download wordprocessor plugins for Photoshop as well?

And, incidentally, I'm pretty sure you can do text handling in Photoshop. Just like you can do drawing in Word.

Re:Creation issue (3, Insightful)

AKAImBatman (238306) | more than 7 years ago | (#16797492)

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 (1)

sammyo (166904) | more than 7 years ago | (#16798694)

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 (1)

mjtaylor24601 (820998) | more than 7 years ago | (#16798870)

"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 (2, Funny)

AKAImBatman (238306) | more than 7 years ago | (#16799262)

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 (1)

Achoi77 (669484) | more than 7 years ago | (#16800504)

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 (2, Insightful)

arose (644256) | more than 7 years ago | (#16796726)

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 (1)

Control Group (105494) | more than 7 years ago | (#16797194)

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.

MOD PARENT -1: STUPID (0)

Anonymous Coward | more than 7 years ago | (#16796780)

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

Why do this in a 2D art package... (1)

tjwhaynes (114792) | more than 7 years ago | (#16797174)

... 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... (1)

Control Group (105494) | more than 7 years ago | (#16797460)

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

Re:Creation issue (1)

modeless (978411) | more than 7 years ago | (#16798218)

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 (1)

AKAImBatman (238306) | more than 7 years ago | (#16799510)

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

Re:Creation issue (3, Interesting)

Andy_R (114137) | more than 7 years ago | (#16795214)

U&I software's "Artmatic Voyager" (successor to the much better known but non-procedural landscape renderer Bryce), and it's 2D companion Artmatic Pro are excellent tools for creating procedural art. No programming experience is necessary to create quite stunning stuff, and there is a wealth of possibilities under the hood once you start building your own algorythms. Take a look at the Artmatic Voyager Gallery [uisoftware.com] for some beautiful procedural planets.

Re:Creation issue (1)

iainl (136759) | more than 7 years ago | (#16795504)

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 (1)

SoapDish (971052) | more than 7 years ago | (#16795548)

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 (1)

Deliveranc3 (629997) | more than 7 years ago | (#16795880)

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 (1)

sammyo (166904) | more than 7 years ago | (#16798580)

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.

Will it decrease loading times? (2, Interesting)

CastrTroy (595695) | more than 7 years ago | (#16794976)

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? (0)

Anonymous Coward | more than 7 years ago | (#16795230)

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? (1)

tfinniga (555989) | more than 7 years ago | (#16795506)

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.

Tradeoff... (3, Insightful)

HaeMaker (221642) | more than 7 years ago | (#16795028)

They are trading file size for CPU performance. While the impact of reduced file sizes are clear, the impact on CPU is not. The question is, is our ability to add storage and bandwidth slower than our ability to add CPU and memory?

I think storage and bandwidth will start winning over CPU as we seem to have hit another Ghz wall and are throwing cores at the problem. While RAM, hard disk and flash are all getting cheaper and bigger at a faster rate.

More cores lend their aid (1)

everphilski (877346) | more than 7 years ago | (#16795158)

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 (1)

AKAImBatman (238306) | more than 7 years ago | (#16795338)

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.

Re:Tradeoff... (1)

CheShACat (999169) | more than 7 years ago | (#16798466)

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 (4, Informative)

Andy_R (114137) | more than 7 years ago | (#16795056)

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 (1)

91degrees (207121) | more than 7 years ago | (#16795206)

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 (0)

RightSaidFred99 (874576) | more than 7 years ago | (#16795340)

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 (1)

jackbird (721605) | more than 7 years ago | (#16795764)

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 (1)

rev063 (591509) | more than 7 years ago | (#16796296)

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 (1)

mrchaotica (681592) | more than 7 years ago | (#16797712)

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

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

GreggBz (777373) | more than 7 years ago | (#16795060)

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

More benifits then just game size.. (1)

GfxGeek (994243) | more than 7 years ago | (#16795114)

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.. (1)

slipster216 (903231) | more than 7 years ago | (#16795306)

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.. (1)

sowth (748135) | more than 7 years ago | (#16800224)

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.

Details? (1)

Tom (822) | more than 7 years ago | (#16795166)

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? (1)

AKAImBatman (238306) | more than 7 years ago | (#16795552)

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 [wikipedia.org] 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? (1)

modeless (978411) | more than 7 years ago | (#16798616)

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.

Yeah, lets go back to 2d! (1)

sowth (748135) | more than 7 years ago | (#16800324)

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.

Blu-ray? (1)

JFMulder (59706) | more than 7 years ago | (#16795270)

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? (0)

Anonymous Coward | more than 7 years ago | (#16795752)

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... (1)

InfinityWpi (175421) | more than 7 years ago | (#16795314)

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

From the itsatypo dept. (2, Funny)

Control Group (105494) | more than 7 years ago | (#16795406)

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

Re:From the itsatypo dept. (1)

gold23 (44621) | more than 7 years ago | (#16796190)

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

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

Re:From the itsatypo dept. (1)

sneakybastige (841985) | more than 7 years ago | (#16799736)

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

Re:From the itsatypo dept. (1)

ensignyu (417022) | more than 7 years ago | (#16800842)

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 [reference.com] ".

Remember Tron? (0)

Anonymous Coward | more than 7 years ago | (#16795466)

Didnt they use these same techniques in Tron [wikipedia.org] ?

Old trick, and some misconceptions... (1)

kbonin (58917) | more than 7 years ago | (#16795486)

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 (1)

BigZaphod (12942) | more than 7 years ago | (#16795528)

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. (0)

Anonymous Coward | more than 7 years ago | (#16795554)

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

Has anyone tried... (0)

Anonymous Coward | more than 7 years ago | (#16795804)

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 (5, Insightful)

Speare (84249) | more than 7 years ago | (#16795922)

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 (3, Insightful)

Control Group (105494) | more than 7 years ago | (#16796082)

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 (2, Insightful)

bumchick (201482) | more than 7 years ago | (#16798180)

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 (1)

Chris Burke (6130) | more than 7 years ago | (#16798982)

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.

Use texture synthesis, right now! (0)

Anonymous Coward | more than 7 years ago | (#16795980)

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 [microsoft.com]

De Guy's in trouble (0)

Anonymous Coward | more than 7 years ago | (#16796002)

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 (1)

lagfest (959022) | more than 7 years ago | (#16796244)

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

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

Anonymous Coward | more than 7 years ago | (#16796284)

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

Not only textures (3, Interesting)

ichigo 2.0 (900288) | more than 7 years ago | (#16796364)

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 (1)

flitty (981864) | more than 7 years ago | (#16796424)

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. (3, Interesting)

TerranFury (726743) | more than 7 years ago | (#16796570)

I'm not sure that 'procedural' is really what we want. Good textures often involve real source images, for instance.

Wavelets may be more useful to compactly encode textures generated more traditionally, and to provide better upsampling than traditional polynomial interpolation methods (bilinear, etc). Rather than generating points between samples using just the adjacent pixels, points are generated from a sum of wavelets generated by looking at all of the pixels.

An example of an image format that does just this is JPEG2000.

The interesting conclusion is that maybe graphics cards should be manipulating images in the frequency domain instead of as bitmaps.

This is probably slow as hell. (1)

Ant P. (974313) | more than 7 years ago | (#16796874)

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

Re:This is probably slow as hell. (1)

Ant P. (974313) | more than 7 years ago | (#16796906)

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

Nobody mentioning Demos yet? (1)

Etcetera (14711) | more than 7 years ago | (#16797546)

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 [pouet.net] by farbrausch [wikipedia.org] 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 [wikipedia.org] that uses all procedural textures and fits into a 96k binary.

They've even released a tool [wikipedia.org] 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 [urulive.com] please hire these guys as interns?)

Re:Nobody mentioning Demos yet? (1)

Etcetera (14711) | more than 7 years ago | (#16800436)


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. (1)

kinglink (195330) | more than 7 years ago | (#16799038)

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

Wavelet patent (1)

Trogre (513942) | more than 7 years ago | (#16800652)

So, anyone know when the patent on wavelets expires?

Does anyone still care about algorithm patents?

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...