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).
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 (http://www.allegorithmic.com/) 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.
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.
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.
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.
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
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)
