Automatic Generation of material

It is too troublesome for ogre to manually write material scripts and shader. In addition, the number of lights that his built-in material can handle is hard to write. The ogre processing method is as follows: for example, a shader supports four light
If less than four light rays are sent to an object, the rest will be 0. If there are more than four, only four are processed. Another way is to add a light and a pass together ....
Of course, you can use moveobjectlistener to control which light you want to use .. Not professional enough.
In addition, even if n shader has been written for different light and shade states of a model, it is difficult to choose shader during operation.
(Oh, by the way, all of the above is about using shader. I will not discuss it again when using a fixed pipeline)
After thinking about it, let's make a material auto-generated item. Who makes me so lazy.
I wanted to re-write the material system. I looked at the Ogre Material Interface and provided enough things. It should be okay to write this set directly on the Ogre material. I feel that although ogre is not functional
Is the strongest, but the interface is definitely the most convenient. Easy to expand. Easy to use any of its features.
The first thing that comes to mind is to generate a shader.
The first thought was like this: Write an N-long shader. Use # define to separate each scenario and select different # define compilation during running. Think about this and write countless
There is no difference between shader and not flexible enough. For example, it is troublesome for users to use the result of adding two textures as diffuse.
Later I thought of something I saw a few years ago. shaderworks does not know who else remembers it .. It sets each function as the most node. Concatenates the output of a function with the input of another function.
A shader connects the logical relationship to a graph, converts it to the shader code, and builds it. In this way, the art editor connects to the desired effect, and then adds the lighting section to the engine.
Point, several shader are generated in several cases. Haha, all possible situations have been solved. Finally, my material system is built on this idea.
Of course, I encountered a lot of details during writing, such as how to cache the shader category, and directly retrieve the same shader without generating any more.
In addition, the shader cannot exceed the number of registers, and how to split the shader into two shader if it exceeds the limit.
In addition, whether to generate HL or ASM, I chose HL, of course, because HL will do a lot of optimization in the API during build, because the automatically generated items will inevitably be Spam in it.
The following figure shows the running effect of the Material System.

There are no parameters by default, and there are two illumination scenarios.

Use a texture as diffuse

Add a normal

Add a texture as self-shining

Another texture is used as the reflection strength.