[Development] Access to depth and stencil buffers in QOpenGLFramebufferObject
Sean Harmer
sean.harmer at kdab.com
Fri May 16 10:44:33 CEST 2014
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.harmer at 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
More information about the Development
mailing list