| Are we looking at the same code? I'm not an OpenGL or Vulkan expert, but: > ...rather than packing them into a PSO struct. Why? * You can clearly read on the front page of the repository that this supports OpenGL 2 through 4.6. I think you're just not looking hard enough. He has Vulkan support in here with a clearly marked file named Pipeline.cpp. The guy knows what a pipeline is... > ...rather than being provided as a UBO interface. * Is this not a UBO interface? > layout(std140) uniform material {
vec4 diffuse;
vec4 specular;
}; It's in his documentation for AbstractShaderProgram. He has explicit binding for stuff pre OpenGL 3.3 or whenever OpenGL added UBOs. > ...appears like limited support for multiple framebuffers. * I don't see why you think there's limited support for multiple framebuffers...? From his docs: > @section GL-Framebuffer-usage-multiple-outputs Multiple fragment shader outputs And then it goes on to explain how to use multiple framebuffer outputs for something like deferred rendering. Moreover, his docs have snippets like this: > @deprecated_gl Prefer to use @ref AbstractFramebuffer::clearDepth() @ref AbstractFramebuffer::clearDepthStencil() instead of @ref setClearDepth() and @ref AbstractFramebuffer::clear() as it leads to less state changes Which clearly shows this guy knows what global state is and why it's bad. I think you're making very broad assumptions based on a very cursory glance at this project. I've only looked at it for about 30 minutes and it looks like a well developed library by somebody who knows what they're doing. I'm sure I could find code that counters the rest of your argument, but I don't feel like looking anymore. None of your criticism seem well intentioned. It might behoove you to give people the benefit of the doubt and realize that you may be able to learn something from them, even if they're so clearly inferior to you. P.S. Don't start off a criticism by saying "how many sins do I count". I don't know your experience, but that's just such an incredibly pretentious statement that's begging to be countered by somebody way more knowledgeable than you about this stuff. |
There is a Vulkan API wrapper. However, there is no "Vk Renderer" -- no code seems to use the Vulkan parts of the code system, and the two projects seem unrelated.
> * Is this not a UBO interface?
There are ways of making a uniform buffer, however the examples don't cover them and the API doesn't adapt automatically. See how all of the setters assert if UBOs are enabled.
https://github.com/mosra/magnum/blob/cfc02599e54e02337dd56bb...
> * I don't see why you think there's limited support for multiple framebuffers...?
The code I do see is about binding/unbinding framebuffers in a stateful manner, e.g. AbstractFramebuffer::bind(), rather than supporting passes.
> None of your criticism seem well intentioned. It might behoove you to give people the benefit of the doubt and realize that you may be able to learn something from them, even if they're so clearly inferior to you.
To put it simply, I've taught enough graphics to know first-hand the kinds of misconceptions that OpenGL-styled APIs can cause, and I'm just a bit tired to see it continue. Admittedly I was a bit harsh, I don't mean any harm towards the author. There are just graphics APIs with interfaces I consider to be much better designed.