[Development] Qt 5.1 feature set and freeze date

[Sean Harmer]

On Wednesday 13 February 2013 08:59:39 Knoll Lars wrote:
> On 2/13/13 9:54 AM, "Mülner, Helmut" <helmut.muelner at joanneum.at> wrote:
> >> [...]
> >> Quite a bit of new functionality has made it into the dev branch, but
> >>
> >>I'd also
> >>
> >> like to add a few of the modules left out in 5.0 to the release. The
> >>
> >>candidates
> >>
> >> I can see so far are:
> >> 
> >> * Qt X11 Extras
> >> * Qt Mac Extras
> >> * Qt Sensors
> >> * Qt Serial Port
> >> * Qt Quick Controls (formerly known as desktop components)
> >
> >No Qt3D?  :-(
> 
> No, unfortunately not.
> 
> We've gone through it, and it will require some more work to make it
> suitable for inclusion. Sean can give details on it. But you can continue
> to use the module as is (knowing the APIs will still change slightly).

I will expand upon this to give some more details about where Qt3D is and 
where we wish to take it.

James Turner and I have been through the Qt3D source code to review it with an 
eye for flexibility, performance, ability to deal with the plethora of modern 
rendering techniques, and potential integrations with 3rd party systems (OSG, 
OGRE, Bullet, Havok etc.).

Although the current Qt3D gives a great way to produce 3D scenes quickly and 
easily we have identified a few deep-rooted design decisions that need to be 
addressed before we can make a release. This is because some aspects of the 
API will need to change to allow us to make these changes. Rather than rushing 
things and risk getting it wrong for Qt 5.1, we are instead laying the ground 
work within QtGui for 5.1 and will work hard to make a Qt3D release for Qt 5.2 
later this year.

We realise that this is not what most of you wish to hear but we would rather 
get a solid foundation in place rather than be trapped within the confines of 
a limiting API for the duration of the 5.x series.

With that in mind, what are we actually planning? The main thing we wish to 
tackle is to make the renderer more generic. Right now it is modelled very 
closely on the OpenGL fixed function pipeline. Yes, it does support more than 
this with shader-based effects but the core is written in such a way that it 
assumes the render is using a single pass forward rendering technique.

Many modern approaches to rendering need much more flexibility than the 
existing framework offers. To this end we are in the process of designing a 
data-driven renderer that offers the ability to specify rendering techniques 
that involve:

* single or multiple passes
* multiple configurable render targets including floating point, depth 
component, as well as more traditional targets
* forward or deferred approaches
* multiple cameras
* totally shader-based
* allows use of new OpenGL features where available
* configurable batch sorter per-pass
* technique selection based upon system, hardware capabilities, property 
bindings etc.
* render state (e.g. depth enabled/disabled, texture unit configuration, 
uniform variables) collected from objects via properties with fallback 
mechanism to allow for rapid development

As you can see this is quite an undertaking and will be difficult to get all 
of this in and working in a performant way. The "OpenGL in Qt 5.1 and onwards" 
thread to this list detailed much of the foundation work that we need to make 
this happen.

The design we are prototyping at present is one of very generic objects in the 
scene graph that aggregate together instances of components that provide 
integration to other subsystems. For example, some components will be tied to 
the rendering system of Qt3D (transformation, material properties etc) whereas 
others will allow integration to other systems. For example: 

* a rigid body component that ties into a physics simulation engine
* a collision volume which uses a custom collision detection system
* a sound emitter/receiver for 3D positional audio
* skeletal animation controller
* ...

This approach gives us a great deal of flexibility without locking us into a 
very deep and broad class hierarchy of objects that can go into the scene 
graph. It will also allow good support for future tooling (e.g. asset 
conditioning, world editors etc) which is another very important aspect.

I hope this helps to explain things. Feel free to come back with questions but 
please understand that at this stage we may not have concrete answers for all 
aspects yet.

Kind regards,

Sean
--
Dr Sean Harmer | sean.harmer at kdab.com | Senior Software Engineer
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