Note, you could put a object into a GPU, think of an object as a struct with pointers, you call one function, it calls other functions.. Each function could be a thread, that works on a different buffer, one a perlin function making a cloud texture, another to compute the reflection mapping, another to apply the reflection mapping results to the normal map made by the perlin function..
See the problem with the ubber shader is that to apply the functions in a different order, you'd need to make a different permutation of the function or add this specification to the existing function..
The problem with function mapping is that to add more functionality you have to add more arguments, and for any arguments not used you have to put in nulls or spaces. So your simple texture has just become a complex mess of passed in structs, pointers and magic cookies. Maybe for a simple function, this is not so bad, but a ubber shader could result in ubber spaghetti code.
Maybe we should adopt Lisp on a shader level? At least we could make functions that make functions. Like say "apply reflection shader effect to diffuse shader" to make reflective plastic shader.
See the problem with the ubber shader is that to apply the functions in a different order, you'd need to make a different permutation of the function or add this specification to the existing function..
The problem with function mapping is that to add more functionality you have to add more arguments, and for any arguments not used you have to put in nulls or spaces. So your simple texture has just become a complex mess of passed in structs, pointers and magic cookies. Maybe for a simple function, this is not so bad, but a ubber shader could result in ubber spaghetti code.
Maybe we should adopt Lisp on a shader level? At least we could make functions that make functions. Like say "apply reflection shader effect to diffuse shader" to make reflective plastic shader.