Overview
Model used in the demo.
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/ We finally arrived in the Rendering Pipeline realm.Some can write that it is useless, some can hate it.Many have some sort of abstraction for it since ages, and others have to now that new APIs like Vulkan and DX12 have it as an explicit part of their design (finally!).
After we built a basic Material System in the previous article (https://jorenjoestar.
UI using ImGUI, SDL and the code generated with this article.
Motivation Following my previous article about Flatbuffers and data reflection the quest for Data-Driven Rendering continues!In this article I want to show how to write a very simple code-generator to help you automate writing of code in any language.The code is here:
https://github.com/JorenJoestar/DataDrivenRendering
There is a balance that constantly needs to be found between code and data, and having a code-generator in my opinion helps tremendously in focus on the code that is necessary to be written.
Auto generated UI from Flatbuffers files.
Motivation Finding a good balance between code and data in Rendering.What is the necessary code that should be written ?Why ?In rendering many areas can be described in a fast and robust way using data.A pipeline (in D3D12/Vulkan lingo) for example is a collection of different states: depth stencil, alpha blend, rasterizer, shaders, etc.All those state can be hard-coded or defined in data.