Procedural texturing; lust or bust?

[K.I.L.E.R]

http://www.bit-tech.net/gaming/2006/11/09/Procedural_Textures_Future_Gam/1.html

GPU manufacturers would end up having built in routines for doing this stuff.
What are the chances of procedural textures replacing the current stuff?

 

[Simon F]

http://www.bit-tech.net/gaming/2006/11/09/Procedural_Textures_Future_Gam/1.html

GPU manufacturers would end up having built in routines for doing this stuff.
What are the chances of procedural textures replacing the current stuff?

I think their technique is not evaluated inside the GPU but in the CPU. It reduces the shipped data. They do, apparently, seem to have a fast compressor to DXTC.

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

Pardon? Perlin's technique is not Fourier based.

 

[3dcgi]

I believe Simon is correct. Everything I've read suggests the texture maps are generated at load time by the CPU. So the GPU shouldn't need to do anything. However, it would be interesting to know if the GPU can speed up the process.

 

[KimB]

Well, I think that procedural texturing has its uses on the content development side of things, but I don't think it'd be good for realtime generation in games, because I don't think game developers would relish the idea of the materials in their games looking as if they were just cut and pasted from some standard library. If the procedural textures are generated as a function of the development program, they could just be a base from which the artist can work to place a personal touch on the texture.

 

[DudeMiester]

I would disagree. First of all, there's nothing stopping the artist from modifying the generation functions of the texture or creating a detail/tweak overlay as a final stage. If anything, it will have an effect opposite of what you describe, in that one can cause various parameters to be automatically varied over the game scene, so that no two textures are alike. Finally, I think they would relish the idea of their textures/materials being from a standard library, since that's how most professionals do it in the offline rendering world anyways. Imho, there is a definite future for procedural textures, especially with multi-core CPUs and the explosion of game size.

 

[poopypoo]

I also think you have to look at procedural tech from more than just a AAA point of view. If it means that the Rapala Pro Fishing guys get to spend more time on creating a good, deep fishing game (damn fellas need to play some old japanese SNES bass fishing games...), and hammering out the clipping bugs, and less time creating textures, then great. Maybe I can get a good fishing game for under $20. Same goes double for homebrewers, modders, and shareware, or say, small-budget MMORPGs.

 

[Rodéric]

Definetly worth investigating, procedural skies are really beautiful, with the right set of parameters available to the artists, I have no doubts that procedural textures can significantly reduce the amount of work having to be done by the artists.
At worst it would be a first step in creating huge textures, and the artists would modify it by hand later on.

No need for the GPU to handle Perlin Noise, precomputing a few Octave w/ different parameters and using those should do the trick, at least for now.

 

[Anarchist4000]

No need for the GPU to handle Perlin Noise, precomputing a few Octave w/ different parameters and using those should do the trick, at least for now.

True but being able to have an infinite resolution on a texture using Perlin could have it's advantages. For instance distance from the object could be used to determine the number of octaves to process. You could dynamically control the detail on a surface without having to bother really extremely large textures and the memory and bandwidth consumed by them. If it's in your face and the only thing getting rendered running many iterations isn't a huge deal. If it's off in the distance so only one is needed the performance hit should be minimal.

Sky and marble seem to be really good uses for procedural as well as some other 'flat' base surfaces. I suppose something along the lines of bumpmaps wouldn't hurt much either. They could be quick to calculate and give the appearance of a rough surface.

I don't see them replacing true textures but IMHO there is definitely a place for them to be used.

 

[Rodéric]

...
I suppose something along the lines of bumpmaps wouldn't hurt much either. They could be quick to calculate and give the appearance of a rough surface.

I don't see them replacing true textures but IMHO there is definitely a place for them to be used.

Reminds me a talk I had about using procedural textures to generate detail map, be it basic "detail" map or "height" map, think about procedural "veins" on a leather surface...