Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

how to change rendering topology #26

Closed
underdoeg opened this issue Jun 9, 2020 · 8 comments · Fixed by #28
Closed

how to change rendering topology #26

underdoeg opened this issue Jun 9, 2020 · 8 comments · Fixed by #28
Labels
enhancement New feature or request

Comments

@underdoeg
Copy link
Contributor

I am trying to render a list of vertices as points. So I have changed input_assembly_state.topology = VK_PRIMITIVE_TOPOLOGY_POINT_LIST To do so, I just made everything in the pipeline public. What would be the desired way to acomplish this?

@pezcode
Copy link
Contributor

pezcode commented Jun 9, 2020

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.

@underdoeg
Copy link
Contributor Author

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.

@TheLavaBlock TheLavaBlock added the enhancement New feature or request label Jun 9, 2020
@TheLavaBlock
Copy link
Member

TheLavaBlock commented Jun 9, 2020

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.

@underdoeg
Copy link
Contributor Author

underdoeg commented Jun 9, 2020

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

@pezcode
Copy link
Contributor

pezcode commented Jun 9, 2020

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 👌

@TheLavaBlock
Copy link
Member

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.

@underdoeg
Copy link
Contributor Author

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.

@TheLavaBlock
Copy link
Member

Yeah! This is the lava_underscore_flow 🖖

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants