Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I recall some time ago that procedurally generated textures were becoming a big deal that a lot of people/companies were really interested in with some serious benefits (smaller deployments, potentially faster loading, higher quality, scalable textures, potentially cheaper to produce, etc.).

From what I can tell, the buzz is dead and no games on my radar are using them. What happened?

I was hoping I'd see procedural textures go the way that NaturalMotion's stuff has (slow but steady adoption).

share|improve this question

closed as too broad by Josh Petrie Sep 29 '15 at 19:36

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

up vote 14 down vote accepted

Content creation tools for procedural texturing have been the biggest roadblock. Artist are very fast putting things together in Photoshop and the potential gains with procedural texturing haven't outweighed the increased content creation time.

Allegorithmic ( has some interesting tools they've developed to try and make procedural options more user friendly. Haven't played with them enough to really comment on their usability though.

share|improve this answer
Allegorithmic was the company that I originally first heard about when the buzz bomb hit and their client list has some big players but, considering they've been in business for a long time, it's still pretty small. – SnOrfus Jul 15 '10 at 3:30
Allegorithmic's Substance products look REALLY REALLY good.. If you take a look at the videos found here: – Nailer Aug 12 '10 at 11:15

The loss of artistic control, and the size increase of storage options have make this a hard sell. That, plus you'd have to retrain artists, while you hired them for what they were good at -traditional texturing. Unless size or unique texturing is really really an issue, there is general little desire to go the procedural way.

share|improve this answer

Basically, the big guns aren't supporting it, so it's not being used much. There have been cool things (albeit a little old), like .kkrieger but the loading time on that (back in the day) was reaaaaally slow, since it had to generate all the textures at loading time.

We might see something or other in next generation engines (Unreal 4 etc) but I don't think that the gain vs development is big enough.

There are examples out there in the AAA world, for example Spore has procedurally generated textures and animation for the creatures you created.

share|improve this answer

Procedural texture suffers from the problem that an Art Director can not reliably point at the work of an Artist and say "please make that part a little more X." because the procedural shading system may not support X cheaply or at all.

For example, a brick shader may support clean brown brick, but may not support brick that was painted with an advertisement 80 years ago and graffiti 10 years ago. Or it may not support having one purple brick out of 1,000 brown bricks. In exactly that one spot, because that spot appeals to the Art Director's taste.

A real texture can support all these things of course, and in this sense a real texture is superior to a procedural texture.

The procedural texture exerts artistic control by virtue of its preference for certain use cases over others. A real texture exerts little such control.

GPU hardware, however, has a strong preference for proceduralism, because texture memory is so many cycles away from the ALU units that do the shading.

share|improve this answer
I find this hard to swallow. It isn't a limitation of procedural textures that a brick cannot be a different color than the rest, it is a limitation of the implementing technology. Sure, I could agree that at some point of getting too specific would outweigh the benefits of doing thing proceedurally, but that is besides the point. – Kevin Peno Jun 18 '11 at 1:25
One brick might have been a bad example, but his other examples hold. It is very very complex and time consuming to define a new algorithm for a slight change in "feel" for a texture, but very cheap and easy for an artist to just make the change. Keep in mind that engineers typically get paid waaaaaaay more than artists, so engineer time spent doing what an artist can do quicker is just silly. – Sean Middleditch Jul 23 '12 at 19:47
@SeanMiddleditch, engineers may get paid more than artists, but the difference is - once an engineer has written code, it can be re-used forever, at no further expense. So although it might take time to develop a procedural generator that can be modified, down to the individual brick level - once it was done, it would be free to use. If a company is paying artists for individual changes, they will have to keep doing so for every new change requirement that comes up, unlike an automated solution. – Cyclops Aug 27 '12 at 9:57
@Cyclops: good luck with that magical super procedure that lets you do the exacting intentional detail an artist can. I look forward to reading your groundbreaking research paper when it's released and eventually licensing your artist-obsoleting über tech. :) – Sean Middleditch Aug 27 '12 at 16:54

well it still seem like a great idea specialy for games. Since you could proceduraly generate textures on-fly so that world around the player would look more natural. No big data needed. It can be sure used to increase even the resolution

share|improve this answer

You have the typical time memory trade off. Well, like it or not, procedural generation trades CPU time for memory conservation. Actually as storage gets cheaper and people always want shorter loading times, the trend is to go the other way around - pregenerated or photographed assets consume memory in exchange for speed.

Does a jpg load faster than a procedurally generated version? Most likely, yes. If the jpg is 2MB and you load it once, why should you bother with procedural? At runtime, the texture takes the same amount of RAM anyway (uncompressed and loaded into GPU memory)

share|improve this answer
JPEG is quite unlikely to load faster than most procedural texture algorithms. Disk access times vastly outweigh CPU/GPU processing time, and since nobody in their right mind uses JPEG for textures and uses larger but GPU-optimized compressed textures with precomputed mipmap layers, disk load time is even worse for real textures. There are reasons why procedural textures suck (mentioned in other answers), but load time is not generally one of them. I'm sure exceptions exist for particularly complicated or inefficient algorithms, of course. – Sean Middleditch Jul 23 '12 at 19:44
Yeah, like .dds. I just used JPG as an example. My point is that is procedural generation of cool looking cobblestone, or water, or trees in a forest using L-systems or whatever takes eons longer (but fits in 96k!) than just loading content on disk, then nobody will want to go that route, simply to reduce load times. – bobobobo Jul 24 '12 at 1:46

Not the answer you're looking for? Browse other questions tagged or ask your own question.