On Friday 16 May 2014 08:33:45 Agocs Laszlo wrote: > Hello, > > What is the use case for accessing the renderbuffers? It is probably left > out since access to them was not seen important. (given that it is the > texture that matters for the 2D UI development scenarios Qt has > traditionally been targeting)
Visualising depth complexity, using stencil buffer or depth buffer in shaders for various techniques (highlighting, SSAO etc). > The getters should probably be added nonetheless. In the meantime you can > use glGetFramebufferAttachmentParameteriv. > > As for the "missing" support for MRT and such, keep in mind that this does > not exist in GLES2, which is the baseline for Qt, and that Qt is not a 3D > engine wrapping every single bit of OpenGL. Improvements are welcome of > course. The approach agreed with Gunnar was that the QOpenGL* classes are meant to be convenience wrappers for OpenGL functionality. Higher-level classes will go into other modules e.g. Qt3D or some other new modules as needed. Nobody is suggesting creating QtGui into a 3D engine. Limiting ourselves to OpenGL ES2 functionality is very short-sighted and severely limits both feature set and performance. ES 3 already provides support for MRTs. Fair enough that ES2 is our baseline but that's no reason not to support additional features where present. People do want and do use these features as I can personally attest to. And at the end of the day, it doesn't really hurt ES2-based users as long as those functions are documented as not being supported on that implementation. Kind regards, Sean -- Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
