[Development] OpenGL in Qt 5.1 and onwards

Sean Harmer sean.harmer at kdab.com
Tue Jan 8 09:46:09 CET 2013


On Tuesday 08 January 2013 08:31:10 Sletta Gunnar wrote:
> On Jan 7, 2013, at 11:16 AM, Sean Harmer <sean.harmer at kdab.com> wrote:
> > Given the current contents of QtGui and the state of Qt3D I would suggest
> > the following:
> > 
> > QtGui continues to be the home for low-level OpenGL convenience classes.
> > That is classes that have a pretty much 1:1 mapping to OpenGL objects. So
> > things like:
> > 
> > * Shaders
> > * Query objects
> > * Texture and Sampler
> > * Vertex Array Objects
> > * Buffer objects
> > * Framebuffer objects
> 
> I agree.
> 
> > Some of these are already used by QQ2, some are not but could be in the
> > future.
> > 
> > For higher-level abstractions I would suggest that we refactor and split
> > Qt3D into a number of more fine-grained and targeted libraries. Right now
> > it is quite monolithic consisting of the C++ threed library and the QML
> > integration.
> > 
> > Some ideas for these:
> > 
> > * 3D maths (float and double versions) (or could extend QtGui 3D maths)
> 
> I would really like us to consider Eigen here. I have not used it
> personally, but it looks pretty solid and there has been quite a lot of
> pushing for the use of this already on this list and others. Since this is
> in the scope of a 3D add-on library, then the additional dependency is not
> a problem.

OK cool. I have no problem with Eigen. I used it at my previous job and it's 
nice. We just need to make sure we can use it with a nice API in conjunction 
with QOpenGLShaderProgram etc. but that should not be difficult.

> > * OpenGL Enablers: Material; Texture unit configuration/management etc
> > * Geometry building/manipulation
> > * Encapsulation: bounding volumes, intersection testing, ray casting etc
> > * Animation
> > * Scene Management
> > * QML integration
> > 
> > * OGRE/OpenSceneGraph integrations
> 
> This is perhaps another candidate to sit higher up in the stack, at least
> one that should not depend on too much other than QtGui and QOpenGLContext
> and/or Qt Quick 2.0. Integrating OGRE and OSG with QtQuick 2 in a "give me
> a surface and GL context" kind of manner is something I consider a very
> likely scenario.

For the basic integration yes, but we can also refactor Qt3D so that some of 
its contained libs only depends upon QtCore and/or QtGui.

Discussing this with James Turner, one thing we would like to look at adding 
in time is a set of QML bindings for OSG in addition to the basic integration.

Cheers,

Sean



More information about the Development mailing list