Material & shader management

In the upcoming changes in my editor I implemented the material system inspired on  Frostbite engine of DICE, binaries are download-able on the project page. Also I've implemented an conversion tool and file-format for future mesh formats using Assimp.
The implementation of these tools still need to mature to be considered robust, tested and frozen for production. But the rudimentary system is there and i have a good feeling about where this process is leading me.

So for the material system and how I implemented them, I have 5 aggregate classes which
in total represent the entire material system. Which are responsible this screen capture of the system in action.

• Material: maintains the information of the source data used for generation.
  
• Kernel: represents permutation of 'generation properties' and 'material' it is presumed material compiler is a deterministic function.
  
• Kernel-Source: maintains a compiled version of the executable code and the type of code.
  
• Kernel-ClassData: maintains collection of Kernel-Source and their respective class based data for example reflection meta-data.
  
• Kernel-InstanceData: maintains collection of instance data for example rasterizer states and texture states.

One interesting challenge to solve was how to use external tools supplied by the pipeline to to semi-efficiently  generate the content. Recreating the tool in native code would be ideal for multi platform targeting, but it would time consuming and severely decrease productivity for improving code generation quality.

So a we have a few options for Inter Process Communication. For my problem I choose Piped Input/Output for the simplicity involved in setting things up.

• Sockets allows us to use network capabilities to generate the content on the same target machine or a different machine all together. This could be a interesting match for console development.
  
• Named Pipes is more of a approach where you get a buffer of a certain size and these buffers can be shared across multiple processes. The applications are responsible for being aware of each-other i.e. manual synchronization.
  
• Piped Input/Output handlers this is when you change the stdout/stdin of a child process to your own handles possible handles could be sockets, interactive buffers, or complete files.