Qt Scene Graph – Round 2

Published Friday October 8th, 2010 | by

Earlier this year, I wrote a post introducing the qt scene graph project. That project has since then gone dormant, but we’ve been playing around with a fork internally for a while now. The idea is to take the basic structure we had in the scene graph and place QML on top of it.

The repository is available here:
http://qt.gitorious.org/qt-labs/scene-graph

To compile it you need a non-make-installed source build of Qt Master, then download the repository and simply do:
qmake -r
make

And you should have a QtSceneGraph library in lib and a qmlscene binary in bin. Most plain .qml files run out of the box with qmlscene. I say “most” because we forked QML back in July and are missing a lot of bug-fixes in QML since then and some aspects of focus handling and mouse/keyboard handling is simply missing. The native plugin API is also something that is still being worked on.

As you understand its far from complete yet, but it gives you an idea of what we are researching to see how Qt and QML can better take advantage of graphics hardware. We hope you find it interesting, enjoy!

(update 2010-10-11: URL of project on Gitorious changed.)

Did you like this? Share it:

Posted in Graphics, OpenGL, Performance, Qt Quick

13 comments to Qt Scene Graph – Round 2

Bert says:

Cool stuff looking forward to it.

BTW have you checked out what the clutter guys are doing? They seem to be a few stable releases down that path.

Hugo says:

Clutter is not well done, has memory leaks, cogl the library used as the drawing abstraction layer allocates unreasonable amounts of memory just for drawing one rectangle …

Marco Martin says:

I’m quite excited by this project, looks like what was needed performance wise.
I’m trying to build it, in addition to those instructions it seems a checkout of Qt3d is also needed, right?

However it still doesn’t seem to build, since it fils on an unknown class called “QGlyph”
is it in some other project on gitorious? or will it arrive in Qt master shortly?

Gunnar Sletta says:

Marco Martin: It does not depend on Qt3D anymore. The classes we needed from Qt3D are now copied into this sourcetree to simplify the buildprocess. QGlyphs was added to Qt/Master back in August, are you sure you are not compiling against 4.7?

aportale says:

I am missing qglfunctions.h. Is that why Marco asked for Qt3d? (I am assuming that that header is Qt3d related)
Edit: Oops, I did not use Qt master, but 4.7. Will retry with master.

Marco Martin says:

yep, you were right, i now managed to build it :)

however i had to export some of the symbols of the private QtDeclarative classes to make it link properly

Andreas says:

What is the plan for QWidgets?
AFAIU QPainter can’t be accelerated by the scenegraph backend, so (for QWidgets in a scenegraph) you have to paint with the raster engine and then blit a texture. Now, the main advantages of QWidgets are basically endless customizability (changing, not reimplementing!) of behavior and looks, and resizability / layouts. It would be nice to keep that *and* get hardware-accelerated painting by reducing the number of OpenGL/GPU state changes while painting, like scenegraph does.
The traditional QWidget layout code looks tricky, and it is sometimes hard to understand why it behaves the way it does even for users of the API.
So what’s my point? QWidgets and QML both have advantages and disadvantages; maybe we can have “the best of both worlds”. I don’t think anyone is very attached to procedural painting, as long as no significant (weasel word!) functionality is lost.

muenalan says:

Will there be a point where I will be laughed at.. because all my QGraphicsView/-Item code became legacy ?

Please deeply consider a plugin replacement for QGraphicsItem (SceneGraph-based). Even if its just 60% compatible – at least ppl can go back in their code and port things step by step. Yeah, I usually tend to have 1000++ items per GraphicsItem and welcome the SceneGraph effort.

Gunnar says:

Andreas: We did a project internally some time ago to try to get the benefits that I talked about in the original post out of normal QWidgets and QPainter, but the fact that there is no “complete scene” knowledge makes it hard to get any benefit out of it. Its because QML is mostly declarative and the full scene is known across multiple frames that we can do these optimizations. As for widgets for QML, are you aware of the components project? http://qt.gitorious.org/qt-components

muenalan: We are working on plugin API’s to make the switch between QGraphicsView-based QML and scenegraph-based QML easy. Spesifically a “visual plugin” class that closely resembles QDeclarativeItem and secondly the ability to embed scenegraph-based QML into QGraphicsView. The scenegraph API will probably not be public API, its only a backend for QML. I don’t see us porting QGraphicsView to it, currently.

Bob says:

Gunnar,

I think muenalan’s question was more in the direction of whether there will be an easy migration path from pure QGraphicsView/QGraphicsScene/QGraphicsItem applications to this new scene graph. QGraphicsView-based QML to SceneGraph-based QML is not all that relevant because that should, as far as I understand, just magically work unless one has specialized declarative items, and in that case the “visual plugin” becomes handy.

MNaydenov says:

I am also with muenalan and Bob and am concerned about migration.

- Should I use QML (instead of straight QGraphicsView) to be more future-proof (because it higher abstraction)?

- Considering “don’t see us porting QGraphicsView”, does it mean it (QGraphicsView) will be deprecated in foreseeable future and replaced by SG?

Thanks

Gunnar Sletta says:

First let me clarify a bit. In the repository, as it stands right now, the scene graph is not public API. The main reason for this is that we want to be free to do major restructuring down the line to continue to improve performance without breaking compatibility. Only the QML APIs and the plugin interfaces are public.

What I’m trying to say is that the scene graph will not replace QGraphicsView as a C++ API. It might replace QGraphicsView as a backend for QML though, and we will have a good migration path for that.

Mnaydenov, you ask if you should use QML instead of QGraphicsView. For somewhat fancy UI, I would definitely use QML because I feel it is far more productive and generally has very good performance.

Lorenzo says:

hello.

i’m really inetrested in this project, but
building my copy of scene-graph, i get this error:

cd src/ && make -f Makefile
make[1]: Entering directory `/usr/src/scenegraph/scene-graph/src’
g++ -c -pipe -g -Wall -W -D_REENTRANT -fPIC -DQT_NO_EGL -DQML_RUNTIME_TESTING -DQT_BUILD_SCENEGRAPH_LIBRARY -DQT_DECLARATIVE_LIB -DQT_PHONON_LIB -DQT_SCRIPT_LIB -DQT_OPENGL_LIB -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -DQT_SHARED -I../../qt-qt/mkspecs/linux-g++ -I. -I../../qt-qt/include/QtCore -I../../qt-qt/include/QtNetwork -I../../qt-qt/include/QtGui -I../../qt-qt/include/QtOpenGL -I../../qt-qt/include/QtScript -I../../qt-qt/include/phonon -I../../qt-qt/include/QtDeclarative -I../../qt-qt/include -I. -Icanvas -Igraphicsitems -Iscenegraph/coreapi -Iscenegraph/convenience -Iscenegraph/3d -I/src/3rdparty/harfbuzz/src -Iadaptationlayers -Iscenegraphitem -I../../qt-qt/include/phonon_compat -I/usr/X11R6/include -I.moc -o .obj/renderer.o scenegraph/coreapi/renderer.cpp
scenegraph/coreapi/renderer.cpp: In function ‘void arraycpy(QArray&, const QArray&) [with T = long long unsigned int]’:
scenegraph/coreapi/renderer.cpp:101: instantiated from here
scenegraph/coreapi/renderer.cpp:71: error: lvalue required as left operand of assignment
scenegraph/coreapi/renderer.cpp: In function ‘void arraycpy(QArray&, const QArray&) [with T = unsigned int]’:
scenegraph/coreapi/renderer.cpp:113: instantiated from here
scenegraph/coreapi/renderer.cpp:71: error: lvalue required as left operand of assignment
make[1]: *** [.obj/renderer.o] Error 1
make[1]: Leaving directory `/usr/src/scenegraph/scene-graph/src’
make: *** [sub-src-make_default-ordered] Error 2

any idea?

it doesn’t seem something about missing libraries of wrong qt branch..

Commenting closed.