[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