Overview In the last articles we looked at progressively building tools to move rendering code towards data.We looked on how to create a simple lexer, a simple parser and a code generator.With those we were able to create a very simple language to augment shaders.
Why that ?
There are few reasons:
Shader languages misses any way of linking multiple programs Shader languages misses any way to define render states CGFX and Microsoft FX are mostly dead Ability to use ANY shader language - and just add the infrastructure Ability to generate permutations without manually creating them Hydra FX aims to add all the missing features and becoming just an augmentation to ANY shader language.
Overview Data Driven Rendering Series:
https://jorenjoestar.github.io/post/writing_shader_effect_language_1/ https://jorenjoestar.github.io/post/writing_shader_effect_language_2/ https://jorenjoestar.github.io/post/writing_shader_effect_language_3/ https://jorenjoestar.github.io/post/data_driven_rendering_pipeline/ In Part 2 of this series we added Resource Layouts and Properties to the HFX language, trying to arrive at a point in which we can describe the rendering of a Shader Effect almost entirely.In this article I would like to explore further adds to HFX, especially a proper Material System to be used in conjunction with the HFX language.
Overview Data Driven Rendering Series:
https://jorenjoestar.github.io/post/writing_shader_effect_language_1/ https://jorenjoestar.github.io/post/writing_shader_effect_language_2/ https://jorenjoestar.github.io/post/writing_shader_effect_language_3/ https://jorenjoestar.github.io/post/data_driven_rendering_pipeline/ In Part 1 of this series we created a simple language to work as ‘shader effect’ - a shader language superset to make our life easier, by adding missing features.The fact that there is not an industry standard for a shader effect language leads to either hand-crafted (and secret) languages, or to hardcoded permutations, or to other gray-area solutions.
Overview Data Driven Rendering Series:
https://jorenjoestar.github.io/post/writing_shader_effect_language_1/ https://jorenjoestar.github.io/post/writing_shader_effect_language_2/ https://jorenjoestar.github.io/post/writing_shader_effect_language_3/ https://jorenjoestar.github.io/post/data_driven_rendering_pipeline/ In this article we will create a simple language that can encapsulate shader code (called code fragments) and output different files for each fragment.This is the initial step to switch from an engine that loads single files for each shader stage (vertex, fragment, compute, …) to one that uses an effect file that contains more than one shader.
We will start by motivation, then will define the language itself (very simple), then we will look at the Parser and last the Code Generator.