On Jan 7, 2013, at 11:16 AM, Sean Harmer <sean.har...@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. > * 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. > > I was hoping to get some refactoring of Qt3D done over the vacations but then > came down with child-induced illness, bah! > > For the OpenGL version and extension classes, I think I would prefer to see > these in QtGui as it makes sense to obtain objects of these types directly > from the context. However, if it bloats QtGui too much then we can make use > of > a simple factory class and put them into a library inside of Qt3D. If they are anyway behind an OPENGL_ES define, then I don't see a big problem in terms of bloat. On desktop we can afford the extra symbols and on embedded they will not exist. Unless we are talking about 1-2Mb extra of course... cheers, Gunnar > > We could redress the balance with Qt6 of course ;) > > Cheers, > > Sean > > _______________________________________________ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development