QtCS2018 Graphics Vision 2020

From Qt Wiki
Revision as of 12:26, 11 June 2018 by Pasikeranen (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Laszlo presented the current 5.11 graphics diagram and vision diagram as discussion starting point.

See attached picture.

Qt graphics present and future

Qt 5.11

  • Qt 3D Studio 2.0 runtime is now built on Qt 3D.
    • This means we have a 3D scene graph that is mainted by the runtime.
    • Qt 3D is still available for use.
  • On Qt Quick 2 side we have Qt Quick Scenegraph.
    • One mistake we did in Qt 5 was to depend on OpenGL and exposing shader coding directly as GLSL.
  • You can use OpenGL texture streaming to render from Qt 3D Studio to Qt Quick or vice versa.
    • Allows embedding of 2D to 3D and 3D to 2D.
    • But has limitations and not highly efficient as we run two independent rendering pipelines with synch points etc.
  • These two silos should be integrated in the future.
    • To get there the underlying things should be fixed.

Qt Graphics 2020

  • One possible destination.
  • We start with Designer Tool (one tool).
  • Underneath this tooling we have an architecture that:
    • Qt Quick Scenegraph
      • Still has the Qt Quick and Qt Quick Scenegraph with Software renderer path
      • Can have still Qt Quick and Qt Quick Scenegraph with OpenGL backend
      • Remove all others (OpenVG as it's limited, D3D12 that is not quite complete even today).
    • Qt 3D Studio Scenegraph
      • 2D scene graph merged at runtime in to the 3D scenegraph.
      • Resulting in a combined Qt 3D Scene Graph with 2D branches and no texture composition (unless needed for optimisation reasons).
        • There are two ideas how this could look like in this diagram.
          • Scenegraph could have a backend which is not exactly rendering backend, but streams commands in to Qt 3D Studio runtime.
          • More tempting is the combining the scenegraphs. What we have in Qt 3D Studio runtime is modeled based on experiences with QSGNode. You could write one parent class for both and create one big tree where certain branhces where you then have 2D branches in 3D scenegraph tree.
          • --> Need to prototype these to see where to go and how.
      • This results in a Qt 3D scene and framegraph.
      • Beneath Qt 3D is a rendering hardware interface that allows us to have multiple backends in future for Vulcan, OpenGL and Metal.
    • Shared Parts between QQ and Q3DS
      • Visual shader graph node editing for:
        • QQ shader effects
        • Q3DS materials
        • Postprocessing FX
      • This gets us to describing the logical presentation of a material or effect. Allows then having different backends for Vulcan, Metal, DX12, OpenGL ES etc.

Discussions

  • Comments raised on the shader graph around still allowing programmers some access to that system.
    • Simplest is that programmers can code complex stuff, but they then are responsible for writing that for each target API the want to support (Vulcan ,DX12 etc.)
    • Another is the intermediate format between shader graph editor and runtime. We don't know what this will end up yet, so maybe?
  • Question around Qt 3D use with Qt 3D Studio
    • Qt 3D is very general, Qt 3D Studio runtime will fix certain things and this means that e.g. you can't go in and change the framegraph randomly.
    • You can still get our source code and modify.
    • If you can figure out a plugin API for modifying Qt 3D Studio framegraph at Qt 3D level, please contribute.
  • Question about QWidget integration.
    • Definitely will be able to have 3D scene in QWidget based UI (Qt 3D Studio itself depends on this).
    • Most likely we'll not support injecting QWidget UI in to scene graph. As we've done that with QGraphicsView and it was horrible to maintain.