And now it is "tonight".
Uhm. Why are the shaders currently stored in two places? There is this new asset based shader variant and my own implementation. The new asset variant fails to compile because the shader include files are not appended or loaded correctly. But that seems to be no problem because my code still relies on my own shader programs. Uah!
Immortius - What's going on here?
At least some of the problem you are encountering is because the original shader system is reading the global includes from the shaders directory, while the new shader/material system reads it from the global includes in "org/terasology/include/" - this is simply because I forgot to go back and change the original shader system.
I was moving the includes to a separate location because they are not shader assets.
Anyhow, a while back I did some work on the Asset system (extending off of t3hk0d3's work). The goal was to have support for the assets needed for allowing the addition of custom mesh, with minimal code required. These assets were Mesh, Shader, Texture and Material.
Textures were fairly simple, although I added the ability to have a json file with the same name as the image to provide additional settings - currently just the filter mode (Linear, Bilinear and Nearest) and wrap mode (repeat and clamp). However I wanted to go a little further than just having entities with a mesh component specifying a texture and it being hardcoded in the background to use a single shader, changing its texture params for each mesh.
So a Material asset describes a combination of a shader, and the settings for the shader's parameters including texture parameters. To feed into this I added a shader asset, which loads up the shader programs, as well as a json file describing what parameters the shader has (this could probably be improved). So this is the new Shader class. The individual shader programs are compiled, but aren't linked at this stage - instead the shader asset acts as a factory, producing the final shader program for any materials using it.
A Material asset brings it all together. A simple json format is used to specify the material:
Code:
{
"shader" : "engine:genericMesh",
"params" : {
"diffuse" : "engine:mhead",
"colorOffset" : [1.0, 1.0, 1.0],
"textured" : true
}
}
Then when the material is loaded, the shader is loaded, linked, and its parameters set. Because each material has a separate shader program, the parameters don't need to be changed unless the material's parameters are changed at runtime - which can be done through the Material's methods. The material is shared between all references to it, so any change to its parameters affects all of them - I've been tossing up whether there should be a mechanism for an entity to end up with an individual material instance, which would be useful if it can change independently of other users of the material.
Upshot of all this is that new mesh, textures, shaders and materials can be added, and applied to prefabs (and hence entities) without writing any code. Downside is I forgot to clean up properly afterwards.