Limitations of procedural textures?

[Repran]

Hi all,

Would like to get your input on what the limitations of procedural textures are. From the top of my head I can list a couple of materials procedural textures do well (metal, wood, stone, marble, plastic, leather, cloth, skin, even fur!).

But what are the limitations? Maybe snake skin and turtle shells?

Please do let me know if this is not the right forum for such a question.

Thanks!

Steve

 

[Nite_Hawk]

Hrm...

I suppose it depends what exactly you define a procedural texture to be, and what exactly you want it to do. (And what kind of rendering engine you pair it with!). If you want a procedural texture by itself to simulate caustics, it's not going to work too well. Otoh, procedural textures are really powerful and you can achieve a lot of effects with them if they are used correctly. I guess I would say that the limitations of a procedural texture are really the limitations of the rendering software being used. Mathematics is a power thing.

Nite_Hawk

 

[Zeno]

Hi all,

Would like to get your input on what the limitations of procedural textures are. From the top of my head I can list a couple of materials procedural textures do well (metal, wood, stone, marble, plastic, leather, cloth, skin, even fur!).

But what are the limitations? Maybe snake skin and turtle shells?

Steve

The limitations on procedural textures are not really of the type "you can make this, but not that". Rather, some things just lend themselves to a procedural description more than others. Snake skin and turtle shells would be some of the easier sorts of things to do procedurally because they are repetitive and have a nice structure to them. They "look mathematical", for lack of a better term.

This is not an exhaustive list, but it might help your understanding to see some of the advantages and disadvantages listed. Remember, a "procedural" texture is just one that is created from some combination of math functions or operations such as sin/cos,step functions,perlin noise, or whatever.

Pros:
1) Very small memory footprint before the texturemap itself is generated. The ultimate in image compression.
2) If CPU/GPU is fast enough, no texture memory is needed at all as it is generated "on the fly" in a pixel shader. This is the ideal situation.
3) If generated on the fly, procedural textures can have exactly the right level of detail.....one sample of the procedural texture can be calculated per pixel on the screen.

Cons:
1) It can be difficult to come up with a formula to get the exact look you are after. It's usually much easier to just have an artist create the texture. This is particularly true for things that show little noise or repetition, like text (silly example).
2) Tools for creating procedural textures are not mature. It is a challenge to expose the parameters of the procedure to the artists in such a way that they can tell what the effect will be. Good procedural textures are often found by luck.
3) Generating procedural textures on the fly can take a huge number of shader program instructions. It will almost always be slower than just looking up a pre-made texture.
4) Generating procedural textures at startup can take longer than loading them.

 

[Killer-Kris]

Cons:
1) It can be difficult to come up with a formula to get the exact look you are after. It's usually much easier to just have an artist create the texture. This is particularly true for things that show little noise or repetition, like text (silly example).
2) Tools for creating procedural textures are not mature. It is a challenge to expose the parameters of the procedure to the artists in such a way that they can tell what the effect will be. Good procedural textures are often found by luck.

You raised some good points I've been wondering about since the advent of shaders. How exactly does development for these sort of system work? From my understanding there are not many texture artists who necessarily understand/know the type of math to effectively use shaders to create procedural textures, but by the same token I'm not really certain I'd trust a programmer to create artistic material either.

 

[rwolf]

Here are a list of procedural textures that cannot be produced:

paper
sand
aluminum foil
ceramics
vegtable oil

 

[Goragoth]

For some neat use of procedural look up the kkrieger game (96kb!). These are not generated on the fly but rather computed beforehand (takes a long time to load). You can download it from: www.theprodukkt.com
I was quite amazed at the effects achieved by that game using only procedural textures. The game uses over 200meg of RAM after generating the textures so yeah, ultimate compression sums it up good

 

[gkar1]

Cons:
1) It can be difficult to come up with a formula to get the exact look you are after. It's usually much easier to just have an artist create the texture. This is particularly true for things that show little noise or repetition, like text (silly example).
2) Tools for creating procedural textures are not mature. It is a challenge to expose the parameters of the procedure to the artists in such a way that they can tell what the effect will be. Good procedural textures are often found by luck.

You raised some good points I've been wondering about since the advent of shaders. How exactly does development for these sort of system work? From my understanding there are not many texture artists who necessarily understand/know the type of math to effectively use shaders to create procedural textures, but by the same token I'm not really certain I'd trust a programmer to create artistic material either.

Im really hoping for texture artists gradually being replaced with procedural texture gurus who have the skills to come up with what current texture artists/designers are coming up with. I am sure there are people with the artistic and programming skills to do it.

 

[KimB]

3) Generating procedural textures on the fly can take a huge number of shader program instructions. It will almost always be slower than just looking up a pre-made texture.

Currently I'm sure this is true. But, in the next few years (say 3 or so), it will memory bandwidth limitations could well cause procedural textures to become attractive.

 

[rwolf]

3) Generating procedural textures on the fly can take a huge number of shader program instructions. It will almost always be slower than just looking up a pre-made texture.

Currently I'm sure this is true. But, in the next few years (say 3 or so), it will memory bandwidth limitations could well cause procedural textures to become attractive.

Plus you don't have issues when zoom in and out on a procedural texture.

 

[Zeno]

Currently I'm sure this is true. But, in the next few years (say 3 or so), it will memory bandwidth limitations could well cause procedural textures to become attractive.

I agree. It will be really nice when procedural textures are a viable option to help alleviate large texture memory requirements.

Plus you don't have issues when zoom in and out on a procedural texture.

True as far as level-of-detail goes. Aliasing is still an issue, though, since you're not using mipmaps to pre-average adjacent texture samples anymore. For example, a naive brick wall shader would exhibit aliasing when it is small enough onscreen that each brick only covers a few pixels. As the user moves, some of those pixels would be mathematically centered on the white of the mortar for an instant which would cause the familiar shimmering/flashing that you get now when not using mipmaps. It'll require even more instructions (or really good supersampling) to fix this problem.

 

[Simon F]

From the top of my head I can list a couple of materials procedural textures do well (metal, wood, stone, marble, plastic, leather, cloth, skin, even fur!).

But what are the limitations? Maybe snake skin and turtle shells?

That rather depends on your definition of procedural textures. If you also include texture synthesis techniques such as, eg, those based on Wang Tiles (see this paper from Siggraph 2003) then you could represent a large number of texture types.

Plus you don't have issues when zoom in and out on a procedural texture.

Not necessarily. Perlin textures, eg turbulence, can generate 'infinite' amounts of detail. In fact, you have to terminate the iterations at the appropriate depth to avoid aliasing.

 

[no_way]

But what are the limitations? Maybe snake skin and turtle shells?

Check out Darktree demo ( http://www.darksim.com ) or simply browse the repository here
This should give a pretty good overview of whats possible and whats reasonable. Leopard skin and toadskins are definitely there.

 

[Repran]

Thanks for all the gerat info guys!

In response to all those who asked me what king of textures I want to do. Basically all of the procedural textures I have in mind are from the following categories:

- Animals (scales, leather, skin, fur, bone, flesh, ivory, shells, mail, etc.)
- Plants (leaves, bark, blossoms, wood, algee)
- Soil and ore (everyting earth, rock, marble and sand)
- Metals (coper, gold, silver, iron, and what not)

Are there programs available where the user can chose from different procedural methods, provide certain parameters like fractal dimension, noise, color bands etc and get a sample texture on various shapes and lightning?

From what I have read here it seems to be more a matter of luck and artistic talent rather then chosing procedure B and sliding a few parameter bars back and forth until one gets the desired effect.

Further: Any freely available databases out there witch provide specific textures? Found some for POV-Ray - but how do I translate those e.g. into pixel shader 3.0 code?

 

[davepermen]

don't think about procedural textures. think about procedural materials. and today, most are. they have parts of it with lookuptables/textures, but a lot is done with shading. bumpmapping, perpixellighing, the whole interaction has to be done in a procedural way. now wich sort of material generates wich part runtime, and wich part is prebaked into textures, that is the question, and depends entierly on artist and situation.

 

[no_way]

Are there programs available where the user can chose from different procedural methods, provide certain parameters like fractal dimension, noise, color bands etc and get a sample texture on various shapes and lightning?

Like i already said, try Darktree. Does exactly what you are asking for.
And it does complete materials, not just textures, along with all the normal maps etc.

 

[Diplo]

But, in the next few years (say 3 or so), it will memory bandwidth limitations could well cause procedural textures to become attractive.

Perhaps I'm being slow, but how would procedual textures alieviate memory bandwidth problems? The examples I've seen generate the textures either to file or system RAM and then they are transfered to video memory like any other texture. Are you actually talking about the GPU somehow generating them on the fly, but even then, where would they be stored?

 

[KimB]

Perhaps I'm being slow, but how would procedual textures alieviate memory bandwidth problems? The examples I've seen generate the textures either to file or system RAM and then they are transfered to video memory like any other texture. Are you actually talking about the GPU somehow generating them on the fly, but even then, where would they be stored?

It's not useful to talk about procedural textures in 3D games unless you're talking about them being generated on the fly. They would be generated on a per-pixel bases, used, then discarded.

 

[Diplo]

It's not useful to talk about procedural textures in 3D games unless you're talking about them being generated on the fly. They would be generated on a per-pixel bases, used, then discarded.

Interesting. Would that mean they would have to be re-generated every single frame? Wouldn't this have a tremendous impact on peformance? (It takes a good 30-45 seconds to pre-generate the textures for 'kkrieger', and that's on a AthlonXP 2800 with 1GB RAM). Again, if I've misunderstood, feel free to tell me

 

[Killer-Kris]

It's not useful to talk about procedural textures in 3D games unless you're talking about them being generated on the fly. They would be generated on a per-pixel bases, used, then discarded.

Interesting. Would that mean they would have to be re-generated every single frame? Wouldn't this have a tremendous impact on peformance? (It takes a good 30-45 seconds to pre-generate the textures for 'kkrieger', and that's on a AthlonXP 2800 with 1GB RAM). Again, if I've misunderstood, feel free to tell me

It'll probably be fairly cheap since they won't regenerate the whole texture, just a few (dozen) pixels from this.

As far as I know there are two main scenarios in which you'd want to do that.

1.) You want to use far more textures than you have space for in video memory, so you'll have to overflow to AGP. In this case fetching a texture from main memory is going to be more expensive than just generating the pixels from the texture you need procedurally.


And very similarly

2.) In the future when GPUs reach the type of bandwidth difference from their memory that CPUs currently have from main memory, it will once again be cheaper to just go ahead and calculate the few pixels you need rather than fetch the texture from memory.

Of course I could be mistaken about all of this, and there may also be even more cases in which you'd want to do this than I know of.