Quote: "You don't know the subject."
I'm relying on the information relayed by the SSAO tutorial I linked to. The method they're using is sending a certain number of rays for the shader to acquire data and then use the shader to interpret the data to generate an image, which is attached to a plane, which is positioned in front of the camera, which is similar to how fullscreen shaders work with DB.
Different shaders work differently, yes, I mean, EVOLVED's water shaders require 2 cameras before applying the shader. Some shadow shaders will use a camera as well and create a mask. All things that can't be added to the shader code natively. Another shadow method is to use ray casting (like the shadow shader I'm using in Unity3D).
When I say write an importer, I mean it'll be code that'll import the shader and interpret the required data correctly. For EVOLVED's water shader, I'd be using the 2 cameras. Yes, I am using the term 'importer' loosely, but I'd argue for me to import these shaders I'll need to write the code that allows me to use them in a scene. In the case of SSAO, it'd be the raycasts, for water it'd be the two cameras. But with that import code, I can just have a command, say, "ApplyWaterShader()" and it'd do everything I need to make that shader work. Yes, some of it IS hardcoded, but the point I was saying, with shaders, it's not completely hardcoded. Of course, for something like Tressfx, it may not be that simple, but it's just a shader and people will need to fit its requirements to make it work as desired.
So it is in the middle of hardcoded and not hardcoded. It's not the same as how my enemy AI is hardcoded, which I could turn into a library if I wanted to. Even then, a library will require a certain level of hardcoding.
