Project structure not exactly a library.
caiowakamatsu opened this issue · comments
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.
- Not make this a rendering library, but just a path tracer. (Which can make pretty things), and maybe turn it into some type of SDK in the far future...
- Focus on making this a library.
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.
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.
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
The funny thing is that the scene is getting rendered and imgui is being drawn, but they aren't drawing to the same image. Whats left to do is to make the example demo take the VkImage provided by RVPT and copy/paste that into the swapchain frame buffer.
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.