how to change rendering topology about liblava HOT 8 CLOSED

not that I am against it, but what is the advantage on changing parameters from an inherited pipeline over just creating one and changing from the outside?

one possible approach could also be to offer a simple interface as is but then have the ability to fine tune the generated pipeline config for advanced use cases. similar to the way the app is initialized.

auto pipeline = make_graphics_pipeline(app.device);
pipeline.on_create = [](some_struct_with_all_vulkan_pipeline_params& params){
      params.input_assembly_state.topology = VK_PRIMITIVE_TOPOLOGY_POINT_LIST;
}

[EDIT] on_create is probably not quite right. its more something like pre_create

from liblava.

Ideally there'd be a function for setting that, but exposing every possible pipeline state without any sort of abstraction really blows up the interface. Maybe a more general way of allowing this is to make graphics_pipeline (and any other object with non-exposed Vulkan creation state) not have private, but protected attributes so you can easily inherit from it and then add your desired changes.

from liblava.

Yes. I also don't think it makes sense to wrap every feature into a function. But having access to all settings at the lowest level makes sense for a prototyping library IMO.

from liblava.

I find both ideas quite interesting. Maybe we should first switch private to protected to allow inheritance, but also offer to change these attributes from outside in the next step.

from liblava.

one possible approach could also be to offer a simple interface as is but then have the ability to fine tune the generated pipeline config for advanced use cases. similar to the way the app is initialized.

auto pipeline = make_graphics_pipeline(app.device);
pipeline.on_create = [](some_struct_with_all_vulkan_pipeline_params& params){
      params.input_assembly_state.topology = VK_PRIMITIVE_TOPOLOGY_POINT_LIST;
}

I actually really like that approach 👌

from liblava.

Sounds like an elegant solution to the problem. 🚀

If you have time and want to submit a proposal, just do a PR (link it to #26) and we can discuss the approach.

from liblava.

This PR would solve my problems. I did struggle a bit with consistent naming. Most projects use capital letters for structs and classes. (I dont really care either way) But with lower case I was forced to create the struct create_info and then call the member info.

from liblava.

Yeah! This is the lava_underscore_flow 🖖

from liblava.