Find a way to create several pipelines from shader files

[SiebenCorgie]

Currently there is no nice way in Vulkano to create a pipeline from a shader file. That's why I am currently creating only one "master" shader which is used by every material. However, I want this to be changeable.

[SiebenCorgie]

This might be changed to static shader types per lighting model and blending types like

• pbr opaque
• pbr masked
• pbr blend
• phong opaque
• ...

[SiebenCorgie]

To implement this I need to move the engine modules back to a shader agnostic storing system. The uniform manager should not store an pbr_fragment::ty::data struct but an custom data which can be transferred to an pbr_fragment::ty::data when creating the descriptor sets.

When this is done:

Don't reference the pipeline by name, but by Arc<pipeline> in the materials. When creating the descriptor set, read the needed inputs from an custum PipelineInputs struct and create the descriptor set based on it.

also: Don't read the the descriptor sets one by one in the renderer, but at once from the material and return an tubel filled with the right amount. (I need to test how to do this though).

[SiebenCorgie]

• [x] Move to independent data sets
• [x] Store pipeline reference
• [ ] Store CpuBufferPools as well as the getter functions in the pipeline
• [ ] Create descriptor sets based on PipelineInputs
• [ ] Create high level get_descriptorsets() function

[SiebenCorgie]

I just decided that the UniformBufferPools should also be moved to the pipeline because they are pipeline depended.

[SiebenCorgie]

currently adding new shader files to define some struct globally (to be copied by the shader writer).

In the future I might write a small string analyser who searches for a key word in a shader string and replaces it with a module. But I have to find out how to do this at compile time. Ref: https://github.com/SiebenCorgie/jakar-engine/issues/15

[SiebenCorgie]

I decided that it is best to leave the descriptor set generation to the materials. However, it would still be nice to decide the amount of generated descriptor sets based on the currently used pipeline inputs.

I'll add a small check function to each of the getter function to check if we really need the descriptor set. If not, they won't do anything and just return a (). The get_descriptor_sets() function then can return some kind of tubel storing a descriptor set or a ().

[SiebenCorgie]

The get descriptorsets function won't make it because I cant find a way to return variable tubel length without some Option nightmares.