-
Notifications
You must be signed in to change notification settings - Fork 8
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
Project structure not exactly a library. #58
Comments
Just putting this out, we could split the monolithic project into two. One "library" with all the implementation, one "main" used for initializing the library code, loading the files, and actually going through the draw loop. I'm all ears on this. |
That's what I wanted to do initially (see old cmake-librarify branch), but the more this is worked on. The more I'm not sure about this. It would take not only a bit of work to split the intermangled code, but also quite a while to decide what gets split into library, and user responsibility. |
@cdgiessen just bringing you in for your insights |
This is something I can do technically but would much rather have a clear idea what the library is responsible for and what the executable is. Like, window? Do we just let the executable handle surfaces, resizing, and the like? This would be cleaner architecturally but annoying if you want to use this as a primary renderer. For a 'secondary' renderer, like a subwindow thats fine. I lean for 'clean' and make the demo executable more complex. (Would probably need to retool how the shaders get found by cmake, but I digress) |
I'd think we have all the business logic (path tracing, vk resource management, window and surface management, etc) handled by the library, and the application just be a thin layer that uploads models, textures, etc and actually has the main method. That said, this convo originally stemmed from a conversation about wanting more documentation in the repo as this gets bigger. |
Well, do we want this to be something people integrate, or build on top of? |
I started working on this yesteryday and pushed up my compiling but not running work to https://github.com/GraphicsProgramming/RVPT/tree/make_rvpt_a_proper_library Window and surface management are not done by rvpt, because its much cleaner architecturally that way. RVPT could be headless for all it cared about. The downside is just determining how to deal with the vulkan-vulkan interface between the library and the client. But once the code is working, we can refine the design. |
The current code works more as an executable which is just a model loader. What do we want to do?
I personally see two options we can do.
I would personally go for option one, as we do not have the most amount of features currently. And it would be a much better idea to make the images pretty first, and then worry about making it a library. Versus having to do both at the same time.
Just opening because this is something that needs to be discussed, but it's yet to be something serious, but something to mention.
The text was updated successfully, but these errors were encountered: