[Development] Stand alone scene graph module

Alan Alpert 416365416c at gmail.com
Thu Apr 4 00:18:07 CEST 2013


On Wed, Apr 3, 2013 at 3:19 AM, Rutledge Shawn <Shawn.Rutledge at digia.com> wrote:
>
> On 3 Apr 2013, at 11:25 AM, Sletta Gunnar wrote:
>
>>
>> On Apr 3, 2013, at 10:51 AM, Dmitrii Volosnykh <dmitrii.volosnykh at gmail.com>
>> wrote:
>>
>>> Hi, Gunnar.
>>>
>>> At first glance scenegraph module and Qt3D have similar feature sets.
>>
>> Not at all :)
>>
>> The scene graph in Qt Quick is a very tiny api, meant to formally structure OpenGL graphics calls so that we can optimally render a 2D interface with bling (it supports 3D transformations and geometry, but it doesn't manage 3D geometry per se). The primary purpose is to allow sorting, reordering of the GL calls and
>>
>> It is meant to be tiny and fast when supporting the usecase of highly dynamic, lots of small things chaning all the time, with bling and some light-weight 3D. It will do worse when trying to render something like google-earth :)
>>
>> Qt3D in its current state is more like QGraphicsView. It puts items into a scene and renders them without any logic to try to improve on the performance. It does contain a scene graph, but it is purely procedural in its execution. Sean Harmer posted a mail a while back outlining how he envisions Qt3D evolving into a proper 3D engine, something which will be suitable for larger 3D apps. This solves a different usecase from what the scene graph and will not be suitable for UI rendering, for instance.
>
> What happens when you try to combine the two, are they just in layers?

My guess is that the best way to combine the two is the way that's
already implemented. See quick3d in the qt3d repo, like
examples/quick3d/monkeygod. They've already integrated Qt3D QML items
into a QtQuick scene, and that would not be affected by making the
scenegraph module more stand alone.

--
Alan Alpert



More information about the Development mailing list