procedural Texturing a replacement for the standard model?

[notAFanB]

given that next gen should finally reach the point where PT (progressive textures) are becoming practical, and we've seen what procedurally animated textures can do (SH3).

I'd like to raise the following questions:-

1. what are the limitations of current implementations of PT in terms of content? I've been led to believe that random noise generation is it's main forte (leaves, flames, material surfaces etc.....).

2. what becomes of the artists role in texture creations at this level?

3. what are the computational costs versus sticking massive textures(compressed?) into gobs loads of memory.

4. why procedural texture do not generate a coherence problem, by this I mean that textures are reasonable static frame to frame.


I am currently of the opinion that CELL will be hard pressed to rely of PT, trading off possibly less RAM if it is computationally expensive and difficult to create the content of mannually created textures.

 

[London Geezer]

procedurally generated textures will be useful for some surfaces, but don't expect PT to be used for every surface... they can only be used with surfaces that require a certain amount of randomness in their patterns, like terrain and stuff like that.
Man-made surfaces (a picture of Britney on someone's shirt for example) will still have to be stored in memory...
i think we will see more and more the use of small procedurally generated bump maps and detail textures. the colour of someone's clothes will be stored as usual colour texture, while the detail maps can be procedurally fgenerated to simulate the fine cloth pattern when the camera gets very close to it. same for bump maps...

 

[Squeak]

(a picture of Britney on someone's shirt for example) will still have to be stored in memory...

Or it could be compressed fractaly or with wavelets, which are also kind of procedural.

 

[London Geezer]

(a picture of Britney on someone's shirt for example) will still have to be stored in memory...

Or it could be compressed fractaly or with wavelets, which are also kind of procedural.

[Straight Mode ON]
well i dont know how flattering a "compressed" picture of britney would be, since it would lose all its.. er... BUMPS
[Straight Mode OFF]

 

[Josiah]

Re: procedural Texturing a replacement for the standard mode

4. why procedural texture do not generate a coherence problem, by this I mean that textures are reasonable static frame to frame.

that all depends on the implementation, procedural textures can be random or not depending on the algorithm. the real advantage is that they can generate infinite detail as you get closer and closer, but the results should be the same every time. 5x5=25 no matter how many times you try it.

 

[London Geezer]

but if u have an algorithm to generate billions of random numbers, how could that be?
i mean if they're random then they cant be the same right...
unless....?
help me out!

 

[notAFanB]

but if u have an algorithm to generate billions of random numbers, how could that be?
i mean if they're random then they cant be the same right...
unless....?
help me out!

random number generators are not always 'random' typically they are seeded with initial number and generate some (constant) result.

the point is that different 'seeds' generate different data sets but with one-to-one corespondence.

maybe a RND generator tied to a system clock would produce not repeatable texture...*shrugs*

 

[akira888]

london boy:

There really is no such thing as a true random number on a deterministic computational device. How they work is they start with a number of some value, do some wierd math to it (usually a huge multiply followed by some shifts) to produce a number that looks nothing like it, then store that new number in the old one's place for next time, and on and on again. The key fact to remember here is that if you start with the same value you will always generate the exact same sequence of values for however many iterations you run the algorithm.

 

[notAFanB]

what Akira888 said basically. over a long enough period of time/cycles the results actually form a coherent pattern with some RND algorithms I believe so the 'randomness' is linited in practice?

EDIT: I wonder how efficient it is to produce PT content (not implementation, assuming it can be run really quickly), because lets face it alot of current texturing involves material surfaces (woodgrain, metallic, course, brick, stone, etc... and flame effects).

in short how far can we carrythe space vs computation trade off before we have to abandon the current GFX paradigm (or at least modify it substancially)?

 

[ChryZ]

A few questions:

1. How expensive is procedural texturing compared to normal texturing methods (calculating-wise)?
2. Is procedural texturing a pure software solution? Are there hardwired approaches?

 

[notAFanB]

2. Is procedural texturing a pure software solution? Are there hardwired approaches?

not sure what you mean here but technically any software driven function can be hardwired, especially if we are willing to reduce the output to a smaller (and more commonly used) sets. however I don;t believe there are any hardwired commercial solutions for procedural texturing.
\maybe a DX dev can shed some light on this issue since I pretty sure some ATI demo produce procedural flames and textures.

 

[akira888]

Most PT content (this is my guess from my limited experience) will be limited to relatively regular, non-complex surfaces, like wood or stone as many rendering programs already allow you to create textures using a "tree" consisting of predefined effects. On the other hand, any type of surface which isn't a homogenous singular "material" will still be done using good old color maps.

 

[notAFanB]

Most PT content (this is my guess from my limited experience) will be limited to relatively regular, non-complex surfaces, like wood or stone as many rendering programs already allow you to create textures using a "tree" consisting of predefined effects. On the other hand, any type of surface which isn't a homogenous singular "material" will still be done using good old color maps.

ah but what I'd really like to is if we can partition PT content from CM(colour map) content. since we have the CPU power (hardwired even) to spare how much RAM (in terms of typical ratios) could devs save?

 

[DeanoC]

london boy:

There really is no such thing as a true random number on a deterministic computational device. How they work is they start with a number of some value, do some wierd math to it (usually a huge multiply followed by some shifts) to produce a number that looks nothing like it, then store that new number in the old one's place for next time, and on and on again. The key fact to remember here is that if you start with the same value you will always generate the exact same sequence of values for however many iterations you run the algorithm.

Lots of deterministic devices have true random number generators. All you need is a truely random seed, for that you want something that follows quantum physics, radioactivity/heat is the obvious choice.
Lots of PC motherboards have a entropy source for this exact use (required for use in proper gambling machines and for good cryptographics key generation), even if you don't, things like warm-up time of hard disks/DVD are random. Pseudo-random number generators will allows follow the same sequence given the same seed, but good random numbers make sure the same seed is never generated twice (the old days used to used the real time clock to prep the seed)

If a producedral texture used a truly random source it would be ugly, butt ugly. No procedural texutre uses a random number, they use Perlin's Noise, Perlin (One of the genii of CG) realised that what we really wanted for procedural textures wasn't random at all but was entirely determistic that just looked a bit messy. Basically you create a 3D texture with random looking values in, then there is some mapping between a 3D point and a filtered random looking value .

 

[akira888]

Deano:

True, I forgot about "entropy reads."

And would not using pure random values off of the system generate a "strobe like" effect as the texture being generated would be generated in an entirely different fashion from frame to frame? Most work as you say, they take a defined seed and from there generate the image.

 

[Bohdy]

Just a question here: in Wind Waker and Mario Sunshine, the Forbidden Forest water, and slime respectively don't seem to be regular animated textures. Their shifting patten of movement and pixelated appearance when looked closely at suggests to me that they may be procedural textures (or at least procedurally animated).

Can anyone confirm?

 

[akira888]

Just a question here: in Wind Waker and Mario Sunshine, the Forbidden Forest water, and slime respectively don't seem to be regular animated textures. Their shifting patten of movement and pixelated appearance when looked closely at suggests to me that they may be procedural textures (or at least procedurally animated).

They could be PT or they could be using dependent texture reads (which Flipper is capable of doing) based either on some quasi-random value or the normal of the pixel. That's one of the ways to do "metal-shading" BTW, you take the normal of the pixel and use that to sample a value from a cube map that contains some pre-painted "shinyness" (for lack of a more acceptable term) values. There are much more elegant ways of implementing this but mine is easy.

 

[DeanoC]

Deano:

True, I forgot about "entropy reads."

And would not using pure random values off of the system generate a "strobe like" effect as the texture being generated would be generated in an entirely different fashion from frame to frame? Most work as you say, they take a defined seed and from there generate the image.

Procedural textures never use any form of random number. Adding a single random (even pseudo-random) number produces the "strobing" you mention, instead we use Perlin Noise, this is not random in any sense of the word but has no patterns that a human would notice. A psuedo-random number generator reseeds itself every call, whereas a Perlin Noise function will produce exactly the same value with the same input.

A procedural texture may look random and unrepeating, but in actual fact is totally deterministic.

 

[London Geezer]

Deano:

True, I forgot about "entropy reads."

And would not using pure random values off of the system generate a "strobe like" effect as the texture being generated would be generated in an entirely different fashion from frame to frame? Most work as you say, they take a defined seed and from there generate the image.

Procedural textures never use any form of random number. Adding a single random (even pseudo-random) number produces the "strobing" you mention, instead we use Perlin Noise, this is not random in any sense of the word but has no patterns that a human would notice. A psuedo-random number generator reseeds itself every call, whereas a Perlin Noise function will produce exactly the same value with the same input.

A procedural texture may look random and unrepeating, but in actual fact is totally deterministic.

oh god thanks for clearing that up...
so basically the sequence of numbers produced is always the same. and thats how u can avoid "changing textures"...
all u need to do is store the algorithm in memory, execute it and POOF u have a pretty non-repeating texture...
i heard someone was using this technique on PS2 already, of course not at a very advanced level, or at a level even resembling some pictures posted in other threads, but is was done, i think Drakan was using some kind of procedurally generated textures...

 

[PC-Engine]

I think SH3 used some PTing.